This is what callers actually want, and it simplifies nir_opt_remove_phis
because we can assume dominance meta data is valid.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31031>
When allocating a buffer normally, this flag gets to the allocator from
the memory requirements, but when sparse bindings are created we were
checking for them but never setting them.
Fixes sparse descriptor buffers on Xe2.
Makes the failure on TRTT more obvious.
Fixes: c6a91f1695 ("anv: add new heap/pool for descriptor buffers")
Fixes: 692e1ab2c1 ("anv: get rid of the second dynamic state heap")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31372>
Valgrind doesn't seem to know that drmSyncobjQuery() writes to the
variable that we pass as 'last_value'. This gets rid of:
==6275== Conditional jump or move depends on uninitialised value(s)
==6275== at 0x5308370: anv_sparse_trtt_garbage_collect_batches (anv_sparse.c:540)
==6275== by 0x53091E2: anv_sparse_bind_trtt (anv_sparse.c:825)
==6275== by 0x5309771: anv_sparse_bind (anv_sparse.c:953)
==6275== by 0x5309A3B: anv_free_sparse_bindings (anv_sparse.c:1041)
==6275== by 0x529FF21: anv_DestroyBuffer (anv_buffer.c:248)
==6275== by 0x932ADBD: ??? (in /usr/lib/x86_64-linux-gnu/libVkLayer_khronos_validation.so)
==6275== by 0x127AA2: MyVkBuffer::~MyVkBuffer() (sparse.cpp:364)
==6275== by 0x12B2D4: MyApp::test1_trivial_sparse() (sparse.cpp:1421)
==6275== by 0x13E01A: MyApp::run_test(int) (sparse.cpp:6594)
==6275== by 0x13E3B0: main (sparse.cpp:6656)
==6275== Uninitialised value was created by a stack allocation
==6275== at 0x53082D3: anv_sparse_trtt_garbage_collect_batches (anv_sparse.c:525)
An alternative to these Valgrind macros would simply have been to
zero-intialize last_value.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31332>
I just noticed that my custom sparse program was not working correctly
when I used ANV_QUEUE_OVERRIDE (instead of enabling the compute queue
by default or using INTEL_ENGINE_CLASS_COMPUTE, which was removed by
commit 600d88ab3c ("intel: Remove INTEL_ENGINE_CLASS_COMPUTE and
INTEL_ENGINE_CLASS_COPY parameters").
It turns out we were not setting the same engine class type when using
ANV_QUEUE_OVERRIDE vs the other cases. Move the code around so the
behavior can stay the same.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31332>
This avoids massively long shader compile times when there is lots of
spilling, at a minor cost of a few more spills/fills. Choose 15 as it is
already the default used by the Cyberpunk 2077 driconf workaround.
Surprisingly the number of additional spills/fills are miniscule in
fossil-db:
Instructions in all programs: 152680595 -> 152681525 (+0.0%)
SENDs in all programs: 7672789 -> 7672789 (+0.0%)
Loops in all programs: 48469 -> 48469 (+0.0%)
Cycles in all programs: 11981743456 -> 11984228708 (+0.0%)
Spills in all programs: 42989 -> 42779 (-0.5%)
Fills in all programs: 76380 -> 76776 (+0.5%)
partly because of the chaotic unpredictability that the choice of
registe to spill has on a shader. For example, this patch massively
helps some shaders in terms of spills/fills:
Spills helped fossils/fossil-db/steam-native/red_dead_redemption2.vk-g6.foz/4101ff9c9b83bf22/SIMD8 fragment: 3208 -> 2894 (-9.8%)
Fills helped fossils/fossil-db/steam-native/red_dead_redemption2.vk-g6.foz/4101ff9c9b83bf22/SIMD8 fragment: 7258 -> 6795 (-6.4%)
Spills helped fossils/q2rtx/q2rtx-rt-pipeline.976f4ab1c0fee975.1.foz/c496e8a549f6b4bf/compute: 109 -> 92 (-15.6%)
Related: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31133
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9241
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11709
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11844
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31269>
Having the actual generated assembly is helpful when trying to figure
out if the code emission and disassembly are implemented correctly.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31305>
This tests is asserting on LNL like :
dEQP-VK.pipeline.monolithic.sampler.border_swizzle.r8_srgb.gbar.custom.gather_1.no_swizzle_hint
dEQP-VK.api.image_clearing.core.clear_color_image.2d.optimal.single_layer.e5b9g9r9_ufloat_pack32
Because blorp tries, for example, to setup a render target with
L8_UNORM_SRGB (which is mapped to the R8_UNORM_SRGB of Vulkan) but is
not supported for rendering.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 1c7fe9ad1b ("anv: Support fast clears in anv_CmdClearColorImage")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31357>
premerge have a time limit of 15 min, those jobs takes between 20 to 33
min with a fraction of 8 right now.
Additionally, we only have 7 VIM3 and could be trying to queue 8 jobs.
Let's fraction to 32 for now and revert back to 2 runners.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 2f54228da5 ("panvk/ci: Update to run full CTS on G52")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31404>
It's not a requirement to support this for implementations. Also
doesn't make much sense...
Fixes
KHR-GL46.sparse_texture_clamp_tests.SparseTextureClampLookupResidency
on Anv with VK_EXT_host_image_copy enabled.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: f24891269d ("zink: check/use suboptimal HIC during ici init")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31391>
s_bfe uses 7 bits for the size, so when we extract from -1,
we can get all possible lane masks in one instruction.
Foz-DB Navi31:
Totals from 38601 (48.62% of 79395) affected shaders:
Instrs: 13670163 -> 13509738 (-1.17%)
CodeSize: 68011644 -> 67368308 (-0.95%)
Latency: 61203404 -> 61065419 (-0.23%); split: -0.23%, +0.00%
InvThroughput: 6897028 -> 6894634 (-0.03%); split: -0.05%, +0.01%
SALU: 1491291 -> 1342553 (-9.97%)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31184>
