Instead of hardcoding a fixed version for all devices, compute the
highest version supported by a device based on the different constraints
mandated by each new version.
For example, besides new functionalities, OpenCL 1.1 also increases the
minimum limits regarding the amount of local memory and the amount of
bytes taken by all arguments to a kernel. Some hardware (such as all
GPUs from NVIDIA’s Tesla micro-architecture) can support the additional
features but do not pass those new minimums.
v3:
* Change `get_highest_supported_version()` to return the version instead
of modifying the version components passed as arguments. (Francisco
Jerez)
* Tweak the line wrapping for `has_extension()`. (Francisco Jerez)
v2:
* Invert the ordering of OpenCL and OpenCL C version, to restrict OpenCL
version based on supported OpenCL C version.
* Rename `get_supported_version()` to `get_highest_supported_version()`;
* Use device methods to query parameters instead of manually executing
them;
* Clarify that the limit checking is only for non-custom devices
supporting the full profile.
* Check for mandatory extensions as well;
* Validate CL_DEVICE_MEM_BASE_ADDR_ALIGN;
* Fix the OpenCL>=1.1 minimum limit for CL_DEVICE_LOCAL_MEM_SIZE, from
32 * 1000 to 32 * 1024;
* Restrict to OpenCL 1.0 if OpenCL C 1.1 is not supported.
* Compute the highest supported version based on constraints (ignoring
2.x versions).
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Pierre Moreau <dev@pmoreau.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10256>
SRV descriptors can require state-transitions before it's legal to set
them on the command-list. We used to just set them right away, and get
away with is, because the validator didn't verify this because we used
to flag the parameters as volatile.
Now that we don't, we trigger validation errors when setting a root
parameter that needs a transition first.
So let's split up the logic a bit, so we can prepare the tables, then do
the transision, and finally set the tables. We do this for all tables
instead of just the SRVs, just because it makes the logic a bit easier to
follow. We leave root constants alone, because they will never require
this, and doing them late would just compilcate things.
Fixes: 1208290558 ("d3d12: Sets all SRV descriptors as data-static")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12187>
Allows to use virtio-gpu to actually test the virgl driver.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11320>
Most of the drivers don't set up the maximum value in the query info. So
when later hud_pane_set_max_value() is invoked, we are using a rather
"random" number.
Turns out that in some 32bit cases, this random number is big enough
that `leftmost_digit` is 0 because DIV_ROUND_UP() overflows, aborting
with an assertion.
Fixes: c91cf7d7d2 ("gallium: implement a heads-up display module")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12181>
Now that we've disabled brilinear and have per-pixel cube derivatives, we
can use the same rendering paths that end users will see.
In a few cases, we switch to the no_quad_lod option instead, because
otherwise we get a piglit failure.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12125>
This is where it should be rather than having to pass it into the
optimisation pass every time.
It also allows us to call the loop analysis pass without having to
duplicate these options which we will do later in this series.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12064>
These queries are used to retrieve the different hardware counters
values, useful to detect performance issues.
v2 (Iago):
- Fix copyright
- Assert hwperfmon exists
- Print message on error
- Rename hwperfmon structure to make it clear
v4 (Juan):
- Save last_job_fence when perfmon is stopped
v5 (Juan):
- No need to ask for counter values if no job was submitted
v6 (Juan):
- Ensure to flush all jobs before capturing last job fence
v7 (Iago)
- No braces for single-line body conditionals
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
All the current queries are pipe-related queries; move them to a
different file to add later performance counter queries.
v3 (Iago):
- Fix copyright.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
When a performance monitor is enabled in the context, all the jobs
submitted to the kernel will have attached this monitor ID, so the
kernel will measuring the performance counters selected in the monitor
when these jobs are executed by the GPU (accumulating the results).
v2 (Iago):
- Update comment
- Assert fence is not NULL
- Assert has_perfmon when using perfmon
- Rewrite conditional
- Implement performance counters in CSD
v4 (Juan):
- Track previous perfmon and sync BCL if required (Juan).
- Track if a job with perfmon was submitted (Juan)
v7 (Iago)
- No braces for single-line body conditionals
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10666>
Opt out of implicit synchronization for the workaround bo: we already
never mark it as writable and we only write to it as part of
PIPE_CONTROL synchronization requirements. Setting it as ASYNC should
be enough for i915.ko to pin it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12151>
Add support for driconf overrides on a per-device level, for cases
where we don't want to override behavior for all devices supported
by a particular driver.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
This will give the driver a chance to set a device name separate from the
driver name, using info probed during screen creation. All drivers
querying driconf in screen creation now have to call parsing on their own,
but other drivers get fallback parsing after screen creation.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
Fixes
In file included from ../src/gallium/drivers/iris/iris_query.c:49:
../src/gallium/drivers/iris/iris_genx_macros.h:81:10: fatal error: genxml/genX_bits.h: No such file or directory
and
In file included from ../src/gallium/drivers/crocus/crocus_query.c:50:
../src/gallium/drivers/crocus/crocus_genx_macros.h:86:10: fatal error: genxml/genX_bits.h: No such file or directory
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12149>
This lower each 64-bit vertex element into 1 or 2 32-bit vertex elements.
The motivation is to simplify st/mesa, which uses a lot more complicated
code to do the same thing, and do the lowering only on a cso_cache miss.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
This just adds the new field. It will be used to lower 64-bit attribs
in drivers (via a helper).
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
This is the distinction between formats:
- PIPE_FORMAT_R64_FLOAT is the legacy "convert-to-float" vertex format.
- PIPE_FORMAT_R64_UINT is the raw double format.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
This removes the bitfield packing/unpacking.
pipe_format entries are reordered to have vertex formats first because
vertex formats must be <= 255.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11370>
There are two problems with the current architecture.
In OpenGL, the id is supposed to be a unique identifier for a particular
log source. This is done so that applications can (theoretically)
filter particular log messages. The debug callback infrastructure in
Mesa assigns a uniqe value when a value of 0 is passed in. This causes
the id to get set once to a unique value for each message.
By passing a stack variable that is initialized to 0 on every call,
every time the same message is logged, it will have a different id.
This isn't great, but it's also not catastrophic.
When threaded shader compiles are used, the id *pointer* is saved and
dereferenced at a possibly much later time on a possibly different
thread. This causes one thread to access the stack from a different
thread... and that stack frame might not be valid any more. :(
I have not observed any crashes related to this particular issue.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12136>
There are two problems with the current architecture.
In OpenGL, the id is supposed to be a unique identifier for a particular
log source. This is done so that applications can (theoretically)
filter particular log messages. The debug callback infrastructure in
Mesa assigns a uniqe value when a value of 0 is passed in. This causes
the id to get set once to a unique value for each message.
By passing a stack variable that is initialized to 0 on every call,
every time the same message is logged, it will have a different id.
This isn't great, but it's also not catastrophic.
When threaded shader compiles are used, the id *pointer* is saved and
dereferenced at a possibly much later time on a possibly different
thread. This causes one thread to access the stack from a different
thread... and that stack frame might not be valid any more. :(
This fixes shader-db crashes of various kinds on Iris with threaded
shader compiles enabled.
Fixes: 42c34e1ac8 ("iris: Enable threaded shader compilation")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12136>
Similar to the fix in 6bf8e960fa ("pan/bi: Do helper termination
analysis on clauses")
Though apparently a "theoretical issue only", fixes artefacts in
DarkPlaces with both D3D9 and GL renderers.
Fixes: 9a7f0e268b ("pan/mdg: Use the helper invo analyze passes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12156>
v2:
- Read mustpass files from vk-default.txt (Matt)
- Remove freedreno atomic geom tests from fail list (Emma)
- Move freedreno flake to separated line (Emma)
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12069>
There's no need for us to do this lowering ourselves while emitting
code, when there's already a helper that can do this for us that we're
even using. Let's just set the right flag, and not worry about
projectors any more.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12126>
The existing code handled the case where the new definition of the
same field was larger than the old one.
This commit adds a check to handle the reverse case: the new def
is smaller than the old one (= so writing using the merged macro
would affect the next fields).
The affected fields are:
* LGKM_CNT (in SQ_WAVE_IB_STS)
* DONUT_SPLIT (in VGT_TESS_DISTRIBUTION)
* HEAD_QUEUE (in GDS_GWS_RESOURCE)
DONUT_SPLIT is the only one used by radeonsi/radv.
Fixes: e6184b0892 ("amd/registers: scripts for processing register descriptions in JSON")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12063>
Add 1 to the key index otherwise we hit the following assert
in hash_table_insert:
assert(!key_pointer_is_reserved(ht, key));
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12105>
Failure to create a buffer for scanout should not be fatal when
importing a buffer. Buffers allocated from a render-only device may not
be able to scanned out directly but can still be used for other
rendering purposes (e.g. as a texture).
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12081>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
The previous logic was returning a handle valid for the render-only
device if rsc->scanout was NULL. However the caller doesn't expect
this: the caller will use the handle with the KMS device.
Instead of returning a handle for the wrong device, fail if we don't
have one.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
When the driver hasn't been initialized via renderonly, screen->ro
will be NULL. This fixes a crash when passing USE_SCANOUT to etnaviv
when it's missing renderonly.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12074>
A previous commit cleaned up the asserts but the last part of
this assert looks like it got mixed up. It should have allowed
param->rel for D3DSPR_INPUT if version is 3.0. Instead it does
&& on the enum value D3DSPR_ADDR which is of course always true,
with the version check. The result is that we miss input
validation with version 3.0.
Spotted by a compile warning
Fixes: 5974401a4a ("st/nine: Regroup param->rel tests")
Reviewed-by: Axel Davy davyaxel0@gmail.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11880>
This doesn't perfectly emit all the TXPs we might be able to (if you get
any non-TXP-able projectors, that whole sampler dim gets lowered), but it
should be a big boost to i915g.
softpipe shader-db:
total instructions in shared programs: 2953625 -> 2951201 (-0.08%)
instructions in affected programs: 108901 -> 106477 (-2.23%)
total temps in shared programs: 565869 -> 566632 (0.13%)
temps in affected programs: 8922 -> 9685 (8.55%)
i915g shader-db:
total instructions in shared programs: 372570 -> 370254 (-0.62%)
instructions in affected programs: 39825 -> 37509 (-5.82%)
total tex_indirect in shared programs: 11420 -> 11074 (-3.03%)
tex_indirect in affected programs: 913 -> 567 (-37.90%)
LOST: 0
GAINED: 12
Closes: #4984
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11912>
