Makes the code more concise, and makes helgrind/drd happy at the same
time!
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7644>
A fairly common pattern for debug envvars is something like:
static int should_print = -1;
if (should_print < 0)
should_print = env_var_as_unsigned("NIR_PRINT", 0);
Unfortunately helgrind doesn't realize that we expect to always get the
same return value, so we don't actually care about the race condition
here.
Add a helper get_once() and do_once macros, with extra locking to make
helgrind/drd happy. Note that other than the nir usages (which are
limited to debug builds), other usages are not in hot-paths.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7644>
In the final version of SPV_KHR_ray_tracing, these are now block
terminators like OpKill or OpReturn. This means that they need special
handling in vtn_cfg.c.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7734>
The old NV version (and the provisional KHR version) specified the data
payload via an integer location. This was quite annoying for the parser
and potentially error-prone. The final KHR version of the SPIR-V
ray-tracing spec replaces these integers with actual pointers. We don't
really need to implement the NV versions but we have the code and
someone might want to parse some NV ray-tracing shaders.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7734>
For these intrinsics, the NV version and the provisional KHR version
have the same enum value and semantics but the final KHR version is
different on both counts. Re-name them to NV before we update the
header so the header update isn't a functional change.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7734>
This brings in the following new extensions:
- VK_KHR_deferred_host_operations
- VK_KHR_pipeline_library
- VK_KHR_acceleration_structure
- VK_KHR_ray_tracing_pipeline
- VK_KHR_ray_query
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7734>
Vulkan can't scale while resolving using vkCmdResolveImage. For this we
need to use util_blitter.
The reason this wasn't a problem in the past, was that glBlitFramebuffer
always set pipe_blit_info::render_condition_enable, and we always used
that to bail out to util_blitter. When the latter changed, this broke.
Fixes: 19906022e2 ("zink: more accurately track supported blits")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7745>
We were allocating twice the size we need for this array. This was
probably caused by a copy and paste error from the GL driver which
grows this dynamically as BOs are added to the job.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7733>
These pass CTS, but I think are missing some stuff CTS doesn't test.
This is one of the base Vulkan 1.0 features and I'd like to support
it for conformance.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
8 seems more correct, however it fixes a bunch of explict lod
tests but breaks some lod query tests.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
This also needs another lines fix, but at least align the code
with tri and points
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
Fixes one case in
dEQP-VK.rasterization.primitives_multisample_4_bit.no_stipple.points
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
You have to count the stats pre-culling here.
Just like dc261cdd42 did for lines.
VK-GL-CTS dEQP-VK.query_pool.statistics_query.clipping_primitives*point_list
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
Fixes:
dEQP-VK.wsi.xcb.swapchain.acquire.too_many
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
I'd only half ported private memory support, finish the job.
Cc: "20.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7705>
Until recently, we ended up using u_blitter here, because
info->render_condition_enable was always true here. But when we recently
fixed that overly broad check, this broke.
So let's fix layered-resolves, by actually checking if the resource has
layers respect them in that case, similar to what we do in blit_native.
Fixes: 19906022e2 ("zink: more accurately track supported blits")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3843
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7737>
This optimizes v_add(c, v_lshlrev(a, b)) to v_mad_u32_u24(b, 1<<a, c)
if 'a' is a constant (less than or equal to 6 to avoid creating
literals) and 'b' known to be a 16-bit or a 24-bit value.
On GFX9+, this is already optimized to v_lshl_add_u32.
No fossils-db changes.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7673>
It will allow to combine v_add+s_lshl or v_add+v_lshlrev to
v_mad_u32_u24 on GFX6-8 if operands are known to be 16-bit or 24-bit.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7673>
To indicate that the upper 8-bits are always 0 to optimize more MADs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7673>
It's less code and makes the configuration easier to fine tune.
Fixes: ff05da7f8d
("microsoft: Add CLC frontend and kernel/compute support to DXIL converter")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7699>
The warning is a bit misleading about where it shows up.. it complains
about the shader key, due to shader key being calculated from (among
other things) stream_output state that had some uninitialized garbage
in the padding.
==84572== Uninitialised byte(s) found during client check request
==84572== at 0x60548E8: blob_write_bytes (blob.c:163)
==84572== by 0x6534EF7: compute_variant_key (ir3_disk_cache.c:111)
==84572== by 0x6535143: ir3_disk_cache_retrieve (ir3_disk_cache.c:171)
==84572== by 0x654D82F: create_variant (ir3_shader.c:251)
==84572== by 0x654DA2B: ir3_shader_get_variant (ir3_shader.c:301)
==84572== by 0x645B2CB: ir3_shader_variant (ir3_gallium.c:113)
==84572== by 0x645B7EB: ir3_shader_create (ir3_gallium.c:219)
==84572== by 0x645BAA7: ir3_shader_state_create (ir3_gallium.c:285)
==84572== by 0x6506003: fd6_shader_state_create (fd6_program.c:1136)
==84572== by 0x64676C7: assemble_tgsi (freedreno_program.c:105)
==84572== by 0x64679DF: fd_prog_init (freedreno_program.c:188)
==84572== by 0x6506157: fd6_prog_init (fd6_program.c:1172)
==84572== Address 0xeff1588 is 424 bytes inside a block of size 480 alloc'd
==84572== at 0x4866FA4: malloc (vg_replace_malloc.c:307)
==84572== by 0x605D46F: ralloc_size (ralloc.c:133)
==84572== by 0x605D52F: rzalloc_size (ralloc.c:166)
==84572== by 0x654DFF7: ir3_shader_from_nir (ir3_shader.c:473)
==84572== by 0x645B6C7: ir3_shader_create (ir3_gallium.c:182)
==84572== by 0x645BAA7: ir3_shader_state_create (ir3_gallium.c:285)
==84572== by 0x6506003: fd6_shader_state_create (fd6_program.c:1136)
==84572== by 0x64676C7: assemble_tgsi (freedreno_program.c:105)
==84572== by 0x64679DF: fd_prog_init (freedreno_program.c:188)
==84572== by 0x6506157: fd6_prog_init (fd6_program.c:1172)
==84572== by 0x64CB36F: fd6_context_create (fd6_context.c:154)
==84572== by 0x59D93BB: st_api_create_context (st_manager.c:917)
Somehow this was showing up with dEQP-GLES31.info.vendor but not other
things.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7717>
1) Propagate the change to only emit markers in debug builds (and add
the WFI that ensures they are synchronized with GPU. We could
consider dropping them entirely, since the GPU devcoredump support
in newer kernels is more useful. But it is still an occasionally
useful fallback.
2) Use p_atomic_inc_return() to placate helgrind
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7717>
v2: Verify that PIPE_CAP_FRONTEND_NOOP is available before calling vfunc (Icecream95)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7640>
Assigning an array reg removes IR3_REG_ARRAY, which means that
definitions and uses can't be tracked back to the array register's name
and liveness for the components of the array aren't correctly
calculated. To fix this we delay assigning array registers until the
scalar pass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7711>
