Once decl_reg is handled, src[0].ssa->divergent will be properly set, so
load_reg and load_reg_indirect do not need special treatment.
shader-db can run to completion on HSW, IVB, and SNB now. No other
testing was done.
v2: Refactor nir_intrinsic_load_reg and nir_intrinsic_load_reg_indirect
handling. Suggested by Daniel Schürmann.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 4fd257d20f ("nir: Properly handle divergence for load_reg")
Fixes: 6dbb5f1e07 ("intel/fs: rerun divergence analysis prior to convert_from_ssa")
Closes: #10233
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26436>
(cherry picked from commit 7fce0a5598)
The SET_STREAM_OUT_BUFFER_LOAD_WRITE_POINTER registers have an
8 dword stride, but the code is only adding one dword between them
then the MME is calling an illegal method.
This is the simple fix, otherwise I think we'd have to multiply
somehow in the MME which seems pointless.
Fixes KHR-GL45.transform_feedback* on zink on nvk.
Fixes: 5fd7df4aa2 ("nvk: Support for vertex shader transform feedback")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26558>
(cherry picked from commit 1b27a6be20)
When calculating the system memory heap size, we report only 3/4 of
the total RAM size (or 1/2 for systems with less than 4GB of RAM).
In the memory budget extension query, we were reporting 90% of the
available system memory. If most of the memory in the system is free,
this could result in the total heap size being 3/4 of RAM, but the
memory available being 9/10 of RAM. But if the application tried to
allocate the memory reported as "available", it would exceed the heap
size. This can confuse some applications.
This patch makes the memory budget query clamp the available RAM to
the heap size, so it will never report more available than the heap
can provide. Unfortunately, this means that we'll report only 67.5%
of system memory as available (3/4 * 9/10). We may want to adjust
this estimate in the future.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26553>
(cherry picked from commit a7b054c974)
This was mainly useful for older Gen7.x GPUs with 32-bit PPGTT, which
are now supported by hasvk rather than anv. The remaining platforms
which anv supports have 36, 47, or 48-bit PPGTT, which imposes a 3/4
limit of 48GB, 96TB, and 192TB of memory.
The GPUs with 36-bit PPGTT are Elkhart Lake and Jasper Lake, which
appear to be Atom CPUs that have a maximum supported memory
configuration of 32GB or less, so this limit should not matter there.
Nor is a multi-TB limit likely to matter on our other parts.
Drop this check to simplify the heap and memory budget calculations.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26553>
(cherry picked from commit 029b1d3f26)
Replacement in try_eval_const_alu() doesn't work because the replacements
are always scalar. The callers also always give a scalar dest.
This is encountered when compiling a Redout shader under ASan.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Fixes: bc170e895f ("nir/loop_analyze: Use try_eval_const_alu and induction variable basis info")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26225>
(cherry picked from commit 7960588413)
RADV compacts all descriptors for multi-planar images into one
combined image sampler, so it should be 96, and not eg. 192 for a two
planes format.
Fixes new CTS
dEQP-VK.binding_model.descriptor_buffer.ycbcr_sampler.*array.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26498>
(cherry picked from commit 3678482f1e)
We never steal the NIR program or free it explicitly, and the state
tracker expects drivers to take ownership of the program object. Since
panfrost doesn't need to keep the original NIR shader around for
compute, let's just free it before returning.
Fixes: 40372bd720 ("panfrost: Implement a disk cache")
Cc: stable
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26424>
(cherry picked from commit 692a4b1804)
Enables 10 bpc / color depth 30 bit support under XOrg
with X11/GLX/OpenGL.
Successfully tested with RaspberryPi OS 11,
running X-Server 1.20, and also with Weston,
on a RaspberryPi 400 on top of current Mesa 24.0-devel.
Alejandro Piñeiro also performed a GLES CTS run
with successful result, citing him:
"Full GLES 31 CTS finished with 0 failres. So all ok"
Note that this commit was originally developed and
successfully tested by myself against Mesa 23.1-devel
from February 2023, and therefore should apply and work
cleanly against recent Mesa stable branches. One could
see this commit as a trivial compatibility fix against
X-Server 1.20 / modesetting-ddx 1.20, which is why I'm
also nominating this commit for the current 23.3 stable
branch, and also the 23.2 stable branch, so it may make
it into RaspberryPi OS 12. Thanks for the consideration.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Backport-to: 23.2
Backport-to: 23.3
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26472>
(cherry picked from commit 1700c6af6f)
According to PRMs, to use self-modifying code correctly we have to
disable preparser before jumping to the generated commands, and re-enable
it with a first command in that buffer.
Old implementation did it wrong: for both inplace and inring generation
it disabled preparser before running the generation shader, had it
disabled during generation, and re-enabled it just before jumping to
the generated commands.
This usually didn't cause any trouble, because the generation shader and
generated draws are in different BOs, and the jump distance is greater than
the command FIFO depth. But we allocate them from the same pool,
so there are rare cases where the end of the BO with generation commands,
and the beginning of the BO with generated draws are adjacent. In such
cases, the wrong commands might be fetched.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10162
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26427>
(cherry picked from commit 5cb20b5edc)
pipeline_is_dirty was never TRUE because it's emitted in the before
helper. This might fix bad interactions between DGC and RT because
they both use compute shaders and descriptor bindings need to be
re-emitted.
Found by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26417>
(cherry picked from commit ab6cf1592f)
This solves a problem when you have a big memory chunk of which some
regions are bound to images. If the image is destroyed, currently the
aux-tt mapping stays and prevent any new image aux-tt mapping within
that region, until the memory is freed.
This maps & unmaps the aux-tt region at respectively bind & destroy
time, so that the memory chunks can be map through aux-tt.
If there is aliasing of memory to 2 different images, then the first
one "wins" the aux mapping and gets compression support. The second
one doesn´t.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ee6e2bc4a3 ("anv: Place images into the aux-map when safe to do so")
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26335>
(cherry picked from commit 7b87e1afbc)
