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>
This isn’t related to the Debian update, but this is a good opportunity
to uprev ci-templates as well since we’re rebuilding all the containers
anyway.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
Bump `fire` from 0.5.0 to 0.7.0. The newer version removes the dependency
on the deprecated `pipes` module, which was removed in Python 3.13.
This fixes the LAVA tests in the `yaml-toml-shell-py-test` job when
running on Debian 13.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
These warnings were causing the arm64 build to fail:
../../vkd3d-proton-src/libs/vkd3d/command.c: In function 'd3d12_shared_fence_set_native_sync_handle_on_completion_explicit':
../../vkd3d-proton-src/libs/vkd3d/command.c:1772:27: error: assignment to 'const uint64_t *' {aka 'const long unsigned int *'} from incompatible pointer type 'UINT64 *' {aka 'long long unsigned int *'} [-Wincompatible-pointer-types]
1772 | wait_info.pValues = &value;
| ^
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35853>
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>
The following Vulkan CTS tests that emit massive shaders were
regressing after "intel/brw/xe3+: Select scheduler heuristic with best
trade-off between register pressure and latency.":
dEQP-VK.graphicsfuzz.cov-nested-loops-set-struct-data-verify-in-function
dEQP-VK.graphicsfuzz.cov-dfdx-dfdy-after-nested-loops
The reason is that they have so many nested loops that they cause the
performance analysis utilization estimates to overflow the 32-bit
floating-point variables used to calculate them, which causes our
throughput estimate to underflow and equal zero for those shaders,
which breaks the logic introduced in brw_allocate_registers() to
select the scheduling variant with highest throughput, since none of
the scheduling modes tried has better throughput than the initial
value equal to zero of "best_perf". Instead use -INFINITY as initial
value for "best_perf" so we always select a scheduling mode.
This should have been caught by CI but oddly the tests above are
showing up as "not run" on my last baseline runs, so this wasn't
flagged as a regression for me.
v2: Use -INFINITY instead of previous approach that used NaN (Ian).
Fixes: 531a34c7dd ("intel/brw/xe3+: Select scheduler heuristic with best trade-off between register pressure and latency.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13884
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13885
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37322>
frontend/mediafoundation: use texture pool for SATD map and Bitsused map
The usage of texture pool depends on the updated mfplat.dll with a fix related to D3DFMT_INDEX32.
If the mfplat.dll on the machine does not have the fix, it falls back to the original implementation without the texture pool.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37376>
