The loader extension provides upcalls to get surface state (native
resource and size) into the driver. The driver extension is called by a
kopper-aware loader in preference to __DRI_SWRAST's createNewDrawable.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14541>
This has one negative side-effect; we're no longer able to print
validation errors without dxcompiler.dll. I doubt that's a real problem,
but if it is, we should add this ability to dxil_validator instead of
having a second implementation here.
The reasons I didn't try adding this in the first place is:
1. This code seems a bit janky; it doesn't consult the "known"-variable
to figure out if the encoding is OK, and it's lacking a fallback path
in that case.
2. It seems unlikely that the compiler varies the encoding of the output
in the first place; one of the two code-paths in here is probably
untested.
3. Since dxil_validator leaves reporting to the call-site, we'd need to
either add and output-encoding to the API (yuck), or re-encode the
string to UTF-8 using WinAPI.
Right now, it seems questionable if fixing all of the above is worth it.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15751>
This API is only available on Windows, which is the only OS where DXIL
validation is a requirement, and where DXIL.dll (and dxcompiler.dll) are
available.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15751>
by utilizing a separate slot map for patch variables, the entire i/o
assignment mechanism can be simplified to accurately manage i/o for all
types of variables and avoid location conflicts
affects:
KHR-Single-GL46.enhanced_layouts*
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15770>
the previous methodology triggered warnings any time a rasterizer state
was created with unsupported features without determining whether those
features would actually be used
a more optimal process is to check for missing features at pipeline creation,
as all the necessary info is now available, and spurious warnings can be avoided
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15778>
deqp-runner uprevved to reduce memory usage on HW runners, let us
experiment with shader cache on tmpfs, and hopefully provide a tool for
virgl to be able to plausibly run piglit under crosvm instead of vtest.
piglit uprevved to avoid a flake in softpipe in glx-multithread-texture,
and improve performance of the test, too. This also brings in the
fbo-blending-format-quirks fix to properly initialize the buffers, fixing
some fails/flakes.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15419>
Unaligned gmem store is a mostly untested path since most
of the times faster path is chosen. We have to force unaligned
store to really test it.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15773>
Otherwise the driver setting interacts with it.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 939ddccb7a ("anv: Add support for depth bounds testing.")
Fixes: 1df871f8ff ("iris: Add support for depth bounds testing.")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15763>
When porting lavapipe to the common sync framework, I stole the dummy
sync signal_for_memory idea from RADV but didn't actually do it
correctly. Unless you set wsi_device::signal_semaphore_with_memory and
wsi_device::signal_fence_with_memory, it doesn't actually signal
anything. If you do set those, it works but also results in dummy
syncs being created for present fences which we see as signals. We
could choose to just skip those like RADV does but that's too magic.
Instead, have our own AcquireNextImage2() again which sets dummy syncs.
Fixes: 3b547a9b58 ("lavapipe: Switch to the common sync framework")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15774>
Cube descriptors require a different sampling instruction in shader,
however we don't know whether image is a cube or not until the start
of a renderpass. We have to patch the descriptor to make it compatible
with how it is sampled in shader.
For the reference subpassLoad is currently translated into isaml.a
Blob v615 also doesn't handle this case correctly.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15734>
When we don't have a good dxcompiler.dll that we can load IDxcLibrary
from to help with diagnostics, we currently return true for validation
even if the validation actually failed.
Let's fix that, and also add a debug-message explaining what went wrong
for those who are debugging and wondering what's up.
Fixes: 2ea15cd661 ("d3d12: introduce d3d12 gallium driver")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15744>
In order to ensure consistent results when running performance tests,
lock the frequency for Intel GPUs to ~70% of the maximum allowed by
hardware.
This seems to offer a good balance between execution speed and results
consistency.
An increase of the frequency will also increase the rate of throttling
events, with a negative impact on consistency. Such events are logged,
as in the following example:
GPU throttling detected: act=200 min=850 cur=850 RPn=100
This shows the actual GPU frequency (200 MHz) dropped below the minimum
requested (850 MHz).
For more details about the various frequency information sources, please
see the script header comments in ".gitlab-ci/common/intel-gpu-freq.sh".
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15662>
The script will be used for tuning Intel GPU frequency to maximize
performance tests execution, while also trying to reduce throttling,
which has a negative impact on results consistency.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15662>
Add script to manage Intel GPU frequencies.
It can be used for debugging performance problems or to lock a stable
frequency while executing benchmark tests.
Typical use cases:
- Get all available GPU frequency information
$ ./intel-gpu-freq.sh -g all
* Hardware capabilities
RP0: 1350 MHz
RPn: 100 MHz
RP1: 400 MHz
* Enforcements
max: 1350 MHz
min: 100 MHz
boost: 1350 MHz
* Actual
act: 100 MHz
cur: 400 MHz
- Lock frequency to 80% of the maximum allowed by hardware and enable
throttling detection
$ ./intel-gpu-freq.sh -s 80% -d
GPU throttling detected: act=1050 min=1350 cur=1350 RPn=100
GPU throttling detected: act=1100 min=1350 cur=1350 RPn=100
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15662>