This fixes a longstanding bug in the interaction between TS and a write
mapping. The write does not update TS regardless of the way the update
is done. Update via etna_copy_resource would just set the target ts_valid
to false without actually writing back any dirty TS to the resource.
Writes via the CPU would update the resource, but keep ts_valid at true
even if the tile status may now not match the actually written tiles of
the resource anymore.
Fix this by writing back a dirty TS to the target resource if needed
before updating the level with the write data. Always invalidate TS,
even when the update is done by the CPU.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19846>
(cherry picked from commit 0fb813526e)
There seems to be a problem with running firefox by using Xwayland that
results in a shared resources being not always tagged as using staging.
As a result one process tries to map the resource that was allocated as
one that uses staging without actually using the staging resource, and
hence the mapped range only accounts for the small region that we have
to allocated because a zero-allocation doesn't work, but the application
mapping the resource assumes that a properly sized range is mapped, and
consequently this results in invalid memory access.
To work around this issue disable creating staging for resources that
are created by using shared binding. It is not clear to me whether this
is the best fix, but it seems to quell the issue.
Fixes: c9d99b7eec
virgl: Fix texture transfers by using a staging resource
Related: https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/291
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19655>
(cherry picked from commit e496d24cb2)
This reverts commit 811f8a1946. As Alpine put it
-- this is causing more problems than it's fixing. Hotfix to revert the
offending commit until a more measured fix can be implemented.
Closes: #7731
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Jan Palus
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19993>
(cherry picked from commit 4b19725ee5)
This is backport of mesa 23.0 commit e74d989a69
with resolution of conflicts for mesa 22.2 branch
static constexpr const 'value' is replaced by static function
in all type_char template specializations
to avoid the following building errors happening with clang 6
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::ExportInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::ExportInstr>(std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&, std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
...
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::RatInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::RatInstr>(std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&, std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19940>
Found when 16bit vec3 varying with llvm14 (not found
when llvm15), one 32bit vec4 slot is filled like this:
vec3[0] | undef
vec3[1] | undef
vec3[2] | undef
undef | undef
LLVM error is for the elements with undef:
%287 = insertelement float %280, half %279, i64 0
After this change, we get:
%287 = insertelement <2 x half> %280, half %279, i64 0
Fixes: 279eea5bda ("amd/llvm: Transition to LLVM "opaque pointers"")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19848>
(cherry picked from commit e3b1f26a2b)
Moving entire chunks of code into a dummy if block is causing issues
in some situations. To work around the issue that we tried to fix in
35d82ecf1e ("nir/lower_shader_calls: put inserted instructions into a
dummy block") which is that we cannot cut and past a block of
instruction that ends with a jump if there are more instruction behind
where we're going to past. We can instead just wraps the jumps into
dummy if blocks.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19820>
(cherry picked from commit 3686d5a312)
This pass can insert if blocks, therefore no dominance/block_index for
you.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19818>
(cherry picked from commit 723b15fb75)
This array of structure needs to be initialized to 0 as it contains a
bitset we don't explicitly clear.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 3144bc1d33 ("intel/perf: move query_mask and location out of gen_perf_query_counter")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18893>
(cherry picked from commit e754bf6be4)
The replace_kernel_ctx() code path was not setting back the context
priority.
Fixes: 5c4c8bdc4c ("iris/batch: Add support for engines contexts")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19687>
(cherry picked from commit cd159c7d6c)
..instead of 4BYTE_ALIGNED_ONLY. This is more correct and avoids
needless repacking. Noticed in Firefox, which was hitting the vbuf
translate path.
Fixes: e03622e50f ("panfrost: Set STRIDE_4BYTE_ALIGNED_ONLY")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19761>
(cherry picked from commit c567e5528f)
Refactor accesses to batch->resources to happen through safe helpers
that update the appropriate bookkeeping. This makes it obvious that (in
particular) reference counts are updated when they should be.
The functional change is that we are now correctly unreferencing
resources during shadowing, fixing a leak of shadowed resources.
Closes: #7362
Fixes: 2d8f28df73 ("panfrost: Replace resource shadowing flush")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Mastodon, apparently
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19753>
(cherry picked from commit 42212a9bfd)
This extension was removed back in 2016, but it seems we left a mention
of it in the docs.
The entire section with this extension seems kinda pointless now, so
let's drop it entirely.
Fixes: f3e23ead53 ("egl: remove remnants of MESA_drm_display")
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19719>
(cherry picked from commit 9f2c9e4c3f)
In linear PE mode the early and late depth stage do not only disagree
about the cache layout, but they seem to fundamentally disagree about
the buffer layout. When Z was written via the late stage, early tests
always show spurious zfails, even if they are not in the same draw
call. Cache flushing and pipe stalls don't help in that case.
The only option to get reliable Z tests with linear render targets is
to move all Z handling into the PE stage. Even when early Z writes
are possible, we don't know if any other draw to the same surface
needs late Z handling, so we must never use the early stage.
Fixes: 53445284a4 ("etnaviv: add linear PE support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19686>
(cherry picked from commit 7fe91c9f66)
Add negative value is possible to wrap around. I haven't seen this
"nuw" causes any problem yet, but let's remove it for safe.
Fixes: 60ac5dda82 ("ac: Add NIR lowering for NGG GS.")
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19718>
(cherry picked from commit c21e184cc5)
We should not use "nuw" here as negative add positive may wrap
around (negative is 0xffffff??).
This problem can be observed with LLVM15 (I can't see when LLVM14):
%.neg = mul nsw i32 %31, -4
%163 = add nuw nsw i32 %.neg, 16
%164 = lshr i32 257, %.neg
%165 = lshr i32 %164, %163
LLVM just assume %.neg is possitive, so pre-shift 0x01010101 by 16.
This get wrong value because we can't get back the shifted bits with
a negative shift right.
Fixes: 75dbb40439 ("ac/nir: Remove byte permute from prefix sum of the repack sequence.")
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19718>
(cherry picked from commit 982b523769)
This fixes GALLIVM_DEBUG=asm for compute shaders, changing
the hooks after dumping causes a segfault because the
memory has already been finalised. Just add the hooks always,
and before dumping anything.
Fixes: f511d2a553 ("gallivm: rework coroutine malloc/free callouts.")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19714>
(cherry picked from commit fb7de303ba)
The code builds up the dynamic array of objects (spirv_objs) and
collect pointers to each of them into another dynamic
array (spirv_ptr_objs).
If the growth of the first array cause a reallocation, it is
possible that the previous pointers end up invalid.
Fixes: 77e929a527 ("intel/clc: allow multiple CL files to be compiled together")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19730>
(cherry picked from commit 9fd1d47aa0)
Age of Empire IV generates a shader of ~2.3Mb on DG2 which is above
the limit we currently have.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19669>
(cherry picked from commit ae76bba34a)
Seems the intention was to check that both flags were not enabled
instead we were checking that the floor flag was both set and not
set so the result would always be false.
Fixes: 3749a6ecd2 ("nir: honor lower_double options for ffloor and ffract")
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19642>
(cherry picked from commit 34c52d8cb9)
If we're in handle_collect()'s dst allocation and are part of a merge set
near the end of the file, our check for reg_elem_size(reg) would let us
use the preferred reg when that would immediately lead to
allocate_dst_fixed() creating an interval extending thruogh reg_size(reg)
that overflows the file.
Avoids a regression on gfxbench5/gl_5_high_off/17.shader_test in the next
commit. No change on shader-db.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
(cherry picked from commit a39113b616)
If an application was transitioning out of fullscreen exclusive
display mode, the wsi_display_connector->active state was not
reset in vkReleaseDisplay() from fullscreen. When the app then
later tried to go to fullscreen display mode again on the same
display output with the same video mode, this caused
_wsi_display_queue_next() to skip a required drmModeSetCrtc()
during the first vkQueuePresent() after entering direct display
mode.
While this often worked by pure luck on a single-display setup,
it goes sideways on a multi-display setup where the viewport
of the associated crtc does not have a (x,y) offset of (0,0).
E.g., XOrg/X11 RandR output leasing of an output whose viewport
starts at x = 1920:
1. X-Server has RandR outputs viewport at x = 1920, in a shared
framebuffer, shared across all crtc's on a X-Screen.
2. Application leases that output for direct display mode,
1st vkQueuePresent() triggers drmModeSetCrtc() of output
to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer
setup.
3. Application does rendering and presenting.
4. Application vkReleaseDisplay() the output, terminates the
RandR lease. X-Server takes over again.
5. X-Server modesets to reconfigure output back to viewport
with (x,y) = 1920, 0.
6. Application leases same output again later on, and tries
vkQueuePresent() again. Because of the bug fixed in this
commit, the required drmModeSetCrtc() to (x,y) = 0,0 is
erroneously skipped due to the stale cached connector state.
7. drmModePageflip() fails due to the wrong crtc viewport
(x,y) = 1920, 0, mismatched for the need of the Vulkan
framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE,
Swapchain goes into permanent VK_ERROR_SURFACE_LOST state.
Destroying and recreating the swapchain, as recommended
by the Vulkan spec for error handling won't help. Game over!
Resetting wsi_display_connector->active = false; fixes the
problem of wrong / stale connector state and Vulkan/wsi/display
clients are happy on multi-display setups again, as tested
in various single- and multi-display configurations.
This bug affects all Mesa releases with Vulkan/WSI/Display
support and should therefore be backported.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484>
(cherry picked from commit 24094ee03d)
