this catches the case where an app resolves both color and depth buffers
previously the inlining would only catch the first color buffer, then the depth
resolve which followed would cause the whole of rp tracking to desync and
explode, as seen in Transport Fever 2
Fixes: 8933b3ed39 ("tc: add resolve resource to rp info")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36521>
even with a 256x256 map, it is over 1 GiB of texture memory
allocated. Also, individually, it was disabled in most of
the tests as it is either too slow or results in an OOM
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36493>
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Downgrade to Linux 6.14 for venus-lavapipe jobs
In Linux 6.16 (and possibly 6.15 as well), the virtio gfx device
initialization seems to have regressed, resulting in device initialization
failure.
```
deqp-runner 0.20.3
+ deqp-runner suite --suite /builds/RickXy/mesa/install/deqp-venus.toml --output /builds/RickXy/mesa/results --skips /builds/RickXy/mesa/install/all-skips.txt /builds/RickXy/mesa/install/venus-skips.txt --flakes /builds/RickXy/mesa/install/venus-flakes.txt --testlog-to-xml /deqp-tools/testlog-to-xml --fraction-start 1 --fraction 60 --jobs 16 --baseline /builds/RickXy/mesa/install/venus-fails.txt
Error: Failed to invoke dEQP for dEQP-VK.info.device:
stdout:
Writing test log into /builds/RickXy/mesa/results/dEQP-VK.info.device
dEQP Core 3299a07b86cf0b15f86d1a441e323e515b15f255 (0x3299a07b) starting..
target implementation = 'Default'
stderr:
MESA-VIRTIO: debug: one of required kernel params (4 or 9) is missing
FATAL ERROR: vk.enumeratePhysicalDevices(instance, &numDevices, nullptr): VK_ERROR_INITIALIZATION_FAILED at vkQueryUtil.cpp:83
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Drop the test from the fail list
It is reported to pass with Linux 6.16
```
Unexpected results:
07:33:07.167: KHR-GL46.sparse_texture2_tests.UncommittedRegionsAccess_texture_cube_map_r32i,Crash
07:33:07.167: spec@!opengl 1.1@streaming-texture-leak,UnexpectedImprovement(Pass)
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Update zink-avn-adl flakes list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add flake to zink-anv-adl skip list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add api@clgetdeviceinfo to Intel fails list
This api call is failing for Intel as well, like many of the other
types.
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36493>
SPIR-V->NIR now inserts this barrier itself.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36513>
Backends probably already deal with this, but these would be needed to
prevent NIR passes from moving accesses outside the critical section.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36513>
Compiling my shader-db with the gallium noop driver produces too noisy
time results to make a conclusion about the improvement. Theoretical
stat-based results are below, which don't always reflect real results.
When compiling Heaven shaders with the gallium noop driver,
213438 calloc calls are removed.
213438 / ralloc count = 9.6%, so it's roughly the equivalent of 9.6% of
the cost of all ralloc calls that's removed. The shift from calloc to
linear_alloc increases ralloc calls by 0.3%, so the approximate reduction
is 9.6% -> 0.3% overhead change.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
Compiling my shader-db with the gallium noop driver is 6.8% faster now.
Theoretical stat-based results are below, which don't always reflect real
results.
When compiling Heaven shaders with the gallium noop driver,
134610 calloc calls are removed.
134610 / ralloc count = 6%, so it's roughly the equivalent of 6% of
the cost of all ralloc calls that's removed. The shift from calloc to
linear_alloc increases ralloc calls by 0.4%, so the approximate reduction
is 6% -> 0.4% overhead change.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
Compiling my shader-db with the gallium noop driver is 3.6% faster now.
malloc calls from ralloc+linear_alloc are reduced by 34% when compiling
Heaven shaders with the gallium noop driver. That's due to a shift of
malloc calls from ralloc to linear_alloc.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
The type of the "new operator" parameter determines whether ir_instruction
is allocated with linear_ctx or ralloc. The ralloc operators will be
removed in the next commit.
GCC expects classes with virtual functions to have a virtual destructor,
but linear_ctx has static assertions that expects that no destructor is
present. Remove the assertions, as that's our only option. The destructor
is empty including in all derived classes, so it doesn't have to execute.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36539>
also mark those functions as pub while at it, because they are meant to be
exported anyway. It's already done with a linker script correctly, but
better to do it correctly on the rust side as well.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33688>
Some hardware (AGX, Imagination, Arm) really want to know the interpolation
qualifiers when compiling the vertex shader. Even though we need to handle this
dynamic for separate shaders, we can improve performance by linking.
nir_opt_varyings already has all the information to do this, so just do so.
Note this has to be done in common code for Gallium, which links varyings within
the GLSL linker but then presents the linked programs as separate shader
objects. This models that nicely, allowing Gallium drivers to optimize without
weird sidebands.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36501>
we'll want this to be able to link interpolation qualifiers in a simple way with
nir_opt_varyings. add the metadata for it and the FS gathering pass.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36501>
the info is all messed up so we need to do this right after. merge this
code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36501>
no other users now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36516>
it's kind of silly now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36516>
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36516>
a bunch of drivers have versions of this, might as well make a common one.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36516>
When I went to use opt_reassociate for tu, I was advised that you want to
do this loop to get the best results. If everyone needs it, let's make it
common code and explain what's going on.
In the process, also make it skip work appropriately when there's no
progress.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36342>
