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>
These two structs are allowed to be in pNext and they should match
the primary command buffer info.
Found while implementing a new extension.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37278>
When sparse binding functions submit batches, they may modify the
exec_obj_index field of anv_bo structs. This field is used to ensure a
unique list of buffers is sent to the kernel (i915). Add a lock in these
functions to prevent multiple threads from modifying this field during
the batch submission process. To avoid creating a deadlock, also rework
the locking done in anv_queue_submit().
When playing the Monster Hunter Wilds Benchmark on a mesa build which
enables slab allocation of batch buffers (6f7a32ec92), this avoids a
sporadic assert failure:
nsterHunterWilds.exe:
../../src/intel/vulkan/i915/anv_batch_chain.c:489:
setup_execbuf_for_cmd_buffers:
Assertion `execbuf->bos[idx] == first_batch_bo_real' failed.
This issue was seemingly first introduced in 04bfe828db
("anv/sparse: allow sparse resouces to use TR-TT as its backend")
Backport-to: 25.2
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12582
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37307>
The Vulkan spec requires that access to the queue parameter be
externally synchronized for vkQueueSubmit(). So, each submit call to a
specific queue will have a unique ID.
Backport-to: 25.2
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37307>
Indicates various properties about calls: Whether a program is an
indirect callee, whether a program or block contains function calls, and
whether registers used by a caller need to be preserved.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34531>
Since b3133e250e ("gallium: add pipe_context::resource_release to
eliminate buffer refcounting") we need to take a reference for every bound
buffer object.
As we create image views on buffers, and kinda take partly reference
already just do it properly for now so we don't end up with
use-after-frees in drivers.
Fixes: dee9600a ("zink: eliminate buffer refcounting to improve performance")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37350>
