This is our compromise to make NVK and nouveau GL play nice when it
comes to modifiers. The old GL driver depends heavily on the PTE kind
and tile mode, even for images with modifiers. While it correctly
encodes the PTE kind and tile mode in the modifiers it advertises, it
may ignore the modifier and just trust what's set on the BO when it
imports a dma-buf image. This is partly because it doesn't support
VM_BIND and partly because of preexisting bugs in the modifiers
implementation. In either case, we can't fix it retroactively.
To work around this, NVK also sets the PTE kind and tile mode on the BO
when it's a dedicated allocation created for a DRM format modifiers
image. If DRM format modifiers are used without dedicated allocations,
things may still break but that's getting into vanishingly unlikely
scenarios.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795>
(cherry picked from commit 4ad79bfef4)
Taken from drm-misc-next-fixes:
commit 959314c438caf1b62d787f02d54a193efda38880
Author: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Date: Thu May 9 23:43:52 2024 +0300
drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795>
(cherry picked from commit 03c4a46fe5)
If p_start_linear_vgpr allocates a VGPR that is already blocked, RA
will try moving the blocking VGPR somewhere else. If
p_start_linear_vgpr is inserted right before the branch, that move will
be inserted after exec has been overwritten, which might cause the move
to be skipped for some threads.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28041>
(cherry picked from commit 590ea76104)
so that users don't have to shift it at every use. It was supposed to be
like this from the beginning.
Fixes: fb994f44d9 - util: make BITSET_TEST_RANGE_INSIDE_WORD take a value to compare with
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29187>
(cherry picked from commit 5502ecd771)
For dma-buf, if the import and finish occur back-2-back for the same
dma-buf, zombie vma cleanup will unexpectedly close the re-imported
dma-buf gem handle. This change fixes it by trying to resurrect from
zombie vmas on the dma-buf import path.
Fixes: 63904240f2 ("tu: Re-enable bufferDeviceAddressCaptureReplay")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29173>
(cherry picked from commit a1392394ba)
Indeed, the object returned by LLVMCreatePassBuilderOptions()
was not freed.
For instance, this issue is triggered with "piglit/bin/cl-api-build-program":
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f6b15abdf57 in operator new(unsigned long) (/usr/lib64/libasan.so.6+0xb2f57)
#1 0x7f6afff6529e in LLVMCreatePassBuilderOptions llvm-18.1.5/lib/Passes/PassBuilderBindings.cpp:83
#2 0x7f6b1186ee41 in optimize ../src/gallium/frontends/clover/llvm/invocation.cpp:521
#3 0x7f6b1186ee41 in clover::llvm::link_program(std::vector<clover::binary, std::allocator<clover::binary> > const&, clover::device const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ../src/gallium/frontends/clover/llvm/invocation.cpp:554
#4 0x7f6b1150ce67 in link_program ../src/gallium/frontends/clover/core/compiler.hpp:78
#5 0x7f6b1150ce67 in clover::program::link(clover::ref_vector<clover::device> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, clover::ref_vector<clover::program> const&) ../src/gallium/frontends/clover/core/program.cpp:78
#6 0x7f6b11401a2b in clBuildProgram ../src/gallium/frontends/clover/api/program.cpp:283
Fixes: 2d4fe5f229 ("clover/llvm: move to modern pass manager.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29164>
(cherry picked from commit df39994d51)
Commit 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
added an automatic zink fallback even when the zink gallium is not
enabled at build time.
It leads to unexpected error log while loading drisw driver and
zink is not installed on the rootfs:
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so
Fixes: 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Antoine Coutant <antoine.coutant@smile.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478>
(cherry picked from commit 02ab51a61e)
commit 1887368df4 ("glx/sw: check for modifier support in the kopper path")
added dri3_priv.h header and dri3_check_multibuffer() function in drisw that
can be build without dri3.
Commit 4477139ec2 added a guard around dri3_check_multibuffer()
function but not around dri3_priv.h header.
Add HAVE_DRI3 guard around dri3_priv.h header.
Fixes: 1887368df4 ("glx/sw: check for modifier support in the kopper path")
v2: Remove the guard around dri3_check_multibuffer() function.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478>
(cherry picked from commit 3163b65ba7)
radv_serialized_shader_arena_block is not tightly packed and using an
initializer list leaves the gaps uninitialized.
cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28961>
(cherry picked from commit 406dda70e7)
We need them for the case where explicit sample locations are not
enabled. While we're at it, fix the case where rasterization_samples=0.
This can happen when rasterizer discard is enabled. This fixes MSAA
resolves with NVK+Zink. In particular, it fixes MSAA for the Unigine
Heaven and Valley benchmark.
This also fixes all of the spec@arb_texture_float@multisample-formats
piglit tests.
Fixes: 41d094c2cc ("nvk: Support dynamic state for enabling sample locations")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10786
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29147>
(cherry picked from commit a160c2a14e)
this otherwise leads to a mismatch where some types of screen may have
the mutex initialized while others don't, in which case dri_release_screen()
will attempt to destroy an uninitialized mutex
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29021>
(cherry picked from commit bc15c95c7a)
the caller (driCreateNewScreen3) will always call dri_destroy_screen()
when these functions return failure, so releasing the screen
is always wrong
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29021>
(cherry picked from commit a1225e81c9)
Running
KHR-GL46.sparse_texture_clamp_tests.SparseTextureClampLookupColor test
with Zink on Anv we run into an assert :
assert(inst->mlen <= MAX_SAMPLER_MESSAGE_SIZE * reg_unit(devinfo));
Turns out we've not covered all the cases in the SIMD lowering.
It's a bit of a shame to have both files reproduce the same logic.
Will try to think of a better way to extract the layout of the a send
message but that'll be a much bigger rework.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29118>
(cherry picked from commit d1c01e256d)
