the location has to be preserved when lowering them to scratch using
nir_lower_vars_to_explicit_types and nir_lower_explicit_io.
cc: mesa-stable
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28187>
We add a units generic parameter to Extent4D and Offset4D and then make
every helper take and return the right type. The mul and div_* helpers
only half-enforce types but it's better than nothing. We leave them
non-public so no one outside extent.rs uses them.
Reviewed-by: Lina Versace <linyaa@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28639>
We're about to add a PhantomData to Extent/Offset4D and that'll make it
harder to construct. Adding a helper lets us more easily construct them
elsewhere in the code.
Reviewed-by: Lina Versace <linyaa@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28639>
This "tear" is similar to the original concept of loads/stores tearing,
but across invocations in a wave instead of bytes. Qualcomm seems to
have this problem, at least for some GPUs. This fixes
spec@arb_shader_storage_buffer_object@execution@ssbo-atomiccompswap-int
on a630 once we start relying on divergence analysis for computing
reconvergence properties. For backends that have readFirstInvocation(),
it should be possible to fix the problem by inserting
readFirstInvocation() instead, but a5xx doesn't have it so we can't rely
on it in freedreno.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28573>
The BSpec page "Flush Types" (46213) says the following about the Tex
Invalidate bit:
"Requires stall bit ([20] of DW) set for all GPGPU Workloads."
For newer platforms, this is documented in the description of the
texture invalidation bit in the PIPE_CONTROL page (56551):
"CS Stall bit in PIPE_CONTROL command must be always set for GPGPU
workloads when Texture Cache Invalidation Enable bit is set"
Iris had it only for GFX_VER 9 and 11, while Anv had it missing for
everything.
Please notice that this patch includes a revert of 397e728ef4.
Fixes: 397e728ef4 ("iris: Drop GPGPU Tex Invalidate restriction for TGL+")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28608>
The new GTK+ GL renderer is extensively using instanced rendering. SVGA
driver was incorrectly detecting the instanced draws by only checking
whether the instance count was greater than 1. Base instance has to
be also checked to make sure that the draw correctly offsets the vertex
buffer.
Fix instanced draw detection by checking both the instance count and
the base instance. Fixes the new GTK+ 4 GL renderer.
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Fixes: ccb4ea5a43 ("svga: Add GL4.1(compatibility profile) support in svga driver")
Reviewed-by: Neha Bhende <neha.bhende@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28616>
Otherwise we can end with invalid curson in some cases, specifically,
if we encounter an identity vector and thus neither register
declaration nor swizzle is inserted, it can lead to invalid cursor and a
crash later.
Suggested by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10905
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28581>
This just shuffles around the meson to make it so that the Rust library
is the final build target, not a C library. We're still building
fundamentally the same amount of stuff because nil_format_table.c is
still C (C is really good at tables that go in the .data section) and we
still need a wrapper rlib for bindgen. Howver, the Rust library is now
the main thing. When the time comes to start using NIL from other Rust
code, this will mean that we can just build an rlib and it will have
everything.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27397>
This adds the infrastructure for the nvidia_headers crate. It currently
only has declarations for the texture headers but QMDs should be trivial
to add as well. The plan is to organize it as follows:
crate nvidia_headers {
mod cl9097 {
// Methods
mod tex {
// Texture defines
}
}
mod clc5c0 {
// Methods
mod qmd {
// QMD defines
}
}
}
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27397>
Having NIR-based instruction selection tests instead of GLSL lets us be
more precise with the input NIR.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28301>
These don't really do anything. They're just a source and user of SSA
defs.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28301>
For
if (uniform) {
if (divergent)
continue
} else {
break
}
we don't need to consider the continue to be divergent.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28301>
This simplifies instruction selection and fixes the case where the loop
ends with a continue instruction.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28301>
STACK_ARRAY() is used in a lot of places. When games are running we
see STACK_ARRAY() arrays being used all the time: each queue
submission uses 6, WaitSemaphores and syncobj waiting also uses them:
they're constantly present in Vulkan runtime.
There's no need for STACK_ARRAY()'s stack array to be initialized,
callers cannot not depend on it. If the number of elements is greater
than STACK_ARRAY_SIZE, then STACK_ARRAY() will just malloc() the array
and return it not initialized: anybody depending of
zero-initialization is going to break when the array is big.
The reason why we're zero-intializing STACK_ARRAY()'s stack array is
to silence -Wmaybe-uninitialized warnings: see commit d7957df318
("vulkan: fix uninitialized variables"). I don't think that commit is
the ideal way to deal with the problem, so this patch proposes a
better solution.
The problem here is that zero-initializing it adds code we don't need
for every single caller. STACK_ARRAY() already has 63 callers and only
3 of them are affected by the -Wmaybe-uninitialized warining. So here
we undo what commit d7957df318 did and instead we fix the 3 cases
that actually generate the -Wmaybe-uninitialized warnings.
Gcc is only emitting those warinings because it knows that the number
of elements in the array may be zero, so the loops we have that set
elements to the array may end up do nothing, and then we pass the
array uninitialized to other functions.
For the cases related to vk_sync this is just returning VK_SUCCESS
earlier, instead of relying on the check that eventually happens at
__vk_sync_wait_many(). For the vkCmdWaitEvents() function, the Vulkan
spec says that "eventCount must be greater than 0", so the early
return doesn't hurt anybody either. In both cases we make the zero
case faster by not defining an 8-sized array, zero-initializing it,
then returning success without using it.
Reference: d7957df318 ("vulkan: fix uninitialized variables")
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28288>
Konstantin Seurer
Paul Gofman
Paul Gofman
Faith Ekstrand
Connor Abbott
Paulo Zanoni
Zack Rusin
Pavel Ondračka
Daniel Almeida
Samuel Pitoiset
Rhys Perry