We are going to wire VK_QUERY_POOL_CREATE_RESET_BIT_KHR next, let's move
things after host_zero_queries.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37380>
Explicit token pasting is handled specially, but the token
printing code can accidentally paste identifiers. Check for
this accidental pasting and prevent it by inserting a space
if necessary.
Supersedes a similar but much more limited test to prevent pasting
`+` and `-` to make `++` and `--`.
A test is provided in glcpp/tests/150-token-accidental-concatenation.
The accidental pasting test in 068-accidental-pasting is also updated
to cover some of the other cases.
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37214>
VK_DEPENDENCY_ASYMMETRIC_EVENT_BIT_KHR makes vkCmdSetEvent2 behaves like
vkCmdSetEvent, let's handle that appropriately.
This fixes failures on VKCTS main with
"dEQP-VK.synchronization2.op.single_queue.event.*_maintenance9".
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: b8ccbc414a ("panvk: enable KHR_maintenance9")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37396>
Those are new tests present on current VKCTS main and that are also part
of waivers.xml.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37396>
Dumb-buffers or imported dmabufs are always linear - otherwise they
couldn't be used by llvmpipe/lavapipe. So far, however, they have been
implicitly reported as DRM_FORMAT_MOD_INVALID when queried through e.g.
`gbm_bo_get_modifier()`.
That is a problem for lavapipe, which requires explicit modifiers. Thus
report modifiers as linear, fixing clients like Westons Vulkan backend
on CI (vkms+lavapipe).
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37374>
Instead of hardcoding 4096-byte page size in bo mapping/unmapping logic,
use os_get_page_size() to determine the correct alignment for munmap()
offset adjustments and address assertions.
Signed-off-by: Zhou Qiankang <wszqkzqk@qq.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37389>
This might be a bit overly careful, but it seems like a good idea to use
both mechanisms to avoid accidental symbol leakage. I also don't think
it matters much in practice, because all sane applications use the the
Vulkan loader, and that shouldn't forward these symbols anyway.
While we're at it, let's wire up a test so we notice if this stops
working.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37371>
Disable detection to match Debian 12 ASan behaviour and prevent a large
number of newly crashing tests on Debian 13.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
Avoid treating any warnings as errors in the third-party imgui code, and
use Wno-error=stringop-overflow for code in Mesa.
Suggested-by: @eric
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
Fixes a -Wmaybe-uninitialized warning:
../src/gallium/drivers/llvmpipe/lp_state_fs.c: In function 'generate_fs_twiddle':
../src/gallium/drivers/llvmpipe/lp_state_fs.c:1555:7: error: 'src' may be used uninitialized [-Werror=maybe-uninitialized]
1555 | lp_bld_quad_twiddle(gallivm, type, src, src_count, dst);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/gallium/drivers/llvmpipe/lp_state_fs.c:89:
../src/gallium/auxiliary/gallivm/lp_bld_quad.h:95:1: note: by argument 3 of type 'struct LLVMOpaqueValue * const*' to 'lp_bld_quad_twiddle' declared here
95 | lp_bld_quad_twiddle(struct gallivm_state *gallivm,
| ^~~~~~~~~~~~~~~~~~~
../src/gallium/drivers/llvmpipe/lp_state_fs.c:1474:17: note: 'src' declared here
1474 | LLVMValueRef src[16];
|
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
Currently we have 3 paths for ALU serialization/deserialization in NIR:
1. If the ALU is qualified as packed_src_ssa_16bit (identity swizzle)
- The write will store an object index only.
- The read will only load the swizzles actually used, the rest are 0.
2. If the ALU is not qualified as packed_src_ssa_16bit, we have two cases:
2.1 Up to vec4:
- The write stores all 4 swizzle components.
- The read loads all 4 swizzle components.
2.2 vec8/16
- The write stores only swizzle components used, the rest are 0.
- The read loads only swizzle components used, the rest are 0.
This inconsistency in how these paths encode/decode unsused swizzle components
can cause issues in some scenarios where a backend compiler may receive
functionally equivalent NIR shaders from Mesa that won't produce the same sha1,
leading to unnecessary cache misses.
This patch makes path 2.1 always encode and decode unused swizzle components
as 0, making it consistent with the other paths.
This fixes issues where sometimes backends need to compile a shader twice
before it is effectively retrieved from the disk cache. This has been
observed at least with V3d and Panfrost.
The problem occurs when an ALU src with unused swizzle components is serialized
in the Mesa frontend using path 1, but when it later hits the backend it is
serialized using path 2.1. The backend uses the sha1 of the serialized NIR for
the cache key. On the second execution the Mesa frontend has a cache hit and
when it deserializes the alu src, it sets its unused components to 0 but that
will cause the backend to have a cache miss since that NIR doesn't match the one
it cached on the first execution.
By always making unused swizzle components decode and encode consistently to 0
in all paths we ensure the issue never happens and that NIR variants that only
differ in swizzle components that are not used lead to cache hits.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37218>
Was trying to test a patch on my Intel box, seems asahi drm-shim bitrotted in
that time. Update the parameters to better match what I dumped off my m1
personal laptop and stub another ioctl. This gets shader-db ./run working on x86
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37382>
