These allow avoiding dead-locks in non-compliant applications that
execute barriers under non-uniform control flow. They're not expected
to have any major disadvantage so let's enable them unconditionally.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29562>
See also HSDES#14015504893 regarding the region-based tessellation
redistribution feature which allows fine-tuning the number of regions
per patch. This sets it to the recommended value, since region-based
redistribution is enabled by default.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29562>
This was caused when enabling VK_KHR_maintenance5 extension, but the
problem is fixed using a new Vulkan Loader.
Fixes: a589901328 ("v3dv: expose VK_KHR_maintenance5")
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29756>
This came up while reviewing
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29398 ... Possibly
this intrinsic should be renamed to load_smem_constant_amd for consistency with
load_global_constant. But if we're not going to convey constantness in the
intrinsic name, let's at least document the restriction, because NIR's optimizer
relies on it.
(I didn't inspect every call site, but it looks like load_smem_amd is just used
for descriptor loads so there's no bug to fix.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29743>
Most passes want to preserve this specific combination of metadata, so let's add
an alias for the combination. The alias communicates that the control flow graph
is preserved, rather than a particular statement about e.g. dominance
preservation.
You don't need to understand dominance to write a simple
nir_shader_instructions_pass. And since you were going to cargo cult the
metadata anyway, this way you'll cargo cult a version you're more likely to
understand.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29745>
This flag is mostly redundant with uses_discard and was only
introduced to implement demote with LLVM when it didn't have
that intrinsic.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
The semantics of discard differ between GLSL and HLSL and
their various implementations. Subsequently, numerous application
bugs occurred and SPV_EXT_demote_to_helper_invocation was written
in order to clarify the behavior. In NIR, we now have 3 different
intrinsics for 2 things, and while demote and terminate have clear
semantics, discard still doesn't and can mean either of the two.
This patch entirely removes nir_intrinsic_discard and
nir_intrinsic_discard_if and replaces all occurences either with
nir_intrinsic_terminate{_if} or nir_intrinsic_demote{_if} in the
case that the NIR option 'discard_is_demote' is being set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
Previously, we left it NULL until later in the compile. However, some
builder helpers are starting to check the options and they blow up when
options == NULL.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
Non-volatile gl_HelperInvocation after demote is undefined.
In order to avoid application bugs, make it volatile if we use demote.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
This define is used in panvk_physical_device.c as well, so it needs to
be visible there.
Fixes: ac34183ec3 ("panvk: Move the VkPhysicalDevice logic to panvk_physical_device.{c,h}")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29751>
Vectorization can make the constant layout worse and increase
the constant register usage. The worst scenario is vectorization
lowered indirect register access, where we access i-th element
and later we access i-1 or i+1 (most notably glamor and gsk shaders).
In this case we already added constants 1..n where n is the array
size, however we can reuse them unless the lowered ladder gets
vectorized later.
Thus prevent vectorization of the specific patterns from lowered
indirect access.
This is quite a heavy hammer, we could in theory estimate how many
slots will the current ubos and constants need and only disable
vectorization when we are close to the limit. However, this would
likely need a global shader analysis each time r300_should_vectorize_inst
is called, which we want to avoid.
So for now just don't vectorize anything that loads constants if we
already have lot of uniforms.
This is the final missing piece to make glamor work on R400.
shader-db R420:
total instructions in shared programs: 107288 -> 107290 (<.01%)
instructions in affected programs: 236 -> 238 (0.85%)
helped: 2
HURT: 3
total temps in shared programs: 17730 -> 17726 (-0.02%)
temps in affected programs: 41 -> 37 (-9.76%)
helped: 4
HURT: 0
total cycles in shared programs: 163251 -> 163251 (0.00%)
cycles in affected programs: 478 -> 478 (0.00%)
helped: 2
HURT: 3
GAINED: 7 (2 glamor and 5 GSK shaders)
RV370 is quite similar instruction/temp-wise, but we don't gain any
shader there, because they are all over the 64 instructions limit...
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10787
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29734>
The commit 973e6f3b implemented compaction of the stream-number space. The
functions `update_vertex_elements(_sw)` began using the post-compacted
stream-numbers/indices when maintaining the `stream_usage_mask` and
when reading from the arrays `vtxstride` and `stream_freq`.
But, the `stream_instancedata_mask`, with which the `stream_usage_mask`
is compared/bitwise-anded, maintains bits for the pre-compacted indices.
Additionally, the information within the arrays is stored using the
pre-compacted indices.
The functions have a disagreement, regarding the type (pre- vs post-
compacted) of indices, with the rest of the relevant source. This change
removes the disagreement by having them use pre-compacted indices when
maintaining the `stream_usage_mask` and when reading from the arrays.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11283
Fixes: 973e6f3b ("gallium: remove start_slot parameter from pipe_context::set_vertex_buffers")
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29704>
We need to check the sample too. fixes on Honeykrisp with MSAA storage images:
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.storage_image.fmt_qual.img.samples_4.2d_array.comp
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29741>
If the application binds graphics shaders and that RADV performs an
internal operation with a compute pipeline, no shader objects would be
restored because binding the internal compute pipeline resets the ESO
state.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29678>
`src/asahi/lib/agx_device.c` includes `git_sha1.h` since
0be124b77e ("asahi: Deserialize libagx when opening device"),
although it only started making use of it once ece3896d5b
("asahi: add broken bits of unstable Linux UAPI") was merged.
Regardless, without this meson change, this leads to a race condition in
builds, where `git_sha1.h` might be built (if ever) after `agx_device.c`.
Fixes: 0be124b77e ("asahi: Deserialize libagx when opening device")
Fixes: ece3896d5b ("asahi: add broken bits of unstable Linux UAPI")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29750>
DGC was disabled for LLVM due to 5/8 components SSBO stores but they
were not expected to work and this has been changed since a977a51a21
("radv: stop using 5/8 component SSBO stores"). No strong reason to
not enable it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29714>
The update_stencil_mask function was removed when moving to the common
Vulkan dynamic state handling.
Fixes: 97da0a7734 ("tu: Rewrite to use common Vulkan dynamic state")
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29658>
We already support everything needed for maintenace3.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29410>
VK_KHR_buffer_device_address was enabled but actually depends on
VK_KHR_device_group.
This trivialy implement device group extensions like other drivers.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29410>
Let's rely on nir_lower_mem_access_bit_sizes doing all the heavy work, so
v3d_nir_lower_scratch can be cleaned up quite a lot.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29711>
It does everything we need and allows us to remove a lot of code. It also
helps with supporting vec8/16 and unaligned load/stores for OpenCL.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29711>
