Extracting from an SGPR could cause a wrong RegClass on
the operand which could later lead to selecting VOPD
instructions which falsely operate on the corresponding
VGPR.
Cc: mesa-stable
(cherry picked from commit d8481fd7cc)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Fix compiler error:
../src/util/blob.c:344:8: error: assigning to 'uint8_t *' from
'const void *' discards qualifiers
[-Werror,-Wincompatible-pointer-types-discards-qualifiers]
glibc now provides C23-style type-generic string functions. memchr
returns const void * when passed a const void * argument. Update nul
declaration to const since it's only used to find the null terminator
position and calculate a size.
Fixes: 1c9877327e ("glsl: Add blob.c---a simple interface for serializing data")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
(cherry picked from commit b40850b24a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Only allow holes between the first and last used component.
Do not load unused components before the first used component.
This fixes test failures with a bunch of VK CTS tests
with allow_holes enabled on RADV:
dEQP-VK.tessellation.tess_io.max_in_out.with_f16.*
Fixes: 6286c1c66f
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 1981b9836b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Calling finalize_nir twice causes si_nir_lower_color_inputs_to_sysvals
to be called twice. The pass always sets color interpolation to FLAT
at the beginning, and then lowers color input loads and sets the correct
interpolation mode. However, when the pass is called for the second time,
it just sets color interpolation to flat and does nothing, which overrides
the original interpolation mode.
This fixes color interpolation for those cases. This only happens with
ATI_fragment_shader AFAIK.
Fixes: deda05e2b7 - nir: move nir_lower_color_inputs into radeonsi
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
(cherry picked from commit e5b1c568b9)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
no, I don't know how this worked before.
fixes
KHR-GL45.conditional_render_inverted.functional
KHR-GL46.transform_feedback_overflow_query_ARB.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Cc: mesa-stable
Reviewed-by: Mary Guillemard <mary@mary.zone>
(cherry picked from commit 56b90a70b3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Per current OpenGL spec: When a cube map texture is sampled, the (s t r)
texture coordinates are treated as a direction vector (rx ry rz)
emanating from the center of a cube. The q coordinate is ignored.
Older spec had slightly different wording that allowed projecting the
coordinates, but to be consistent with GLSL/SPIRV and the expectations
of the real-world applications it's better to ignore the projector.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14235
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
(cherry picked from commit d8e524cd6b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Applying the projector after the normalization breaks the coordinates, so
apply it early. Usually it's not even necessary for the cubemaps anyway,
but ARB_fragment_program and TGSI allow it.
Fixes: 52e71809 ("nir: Add a cubemap normalizing pass")
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
(cherry picked from commit f3eb98ec57)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Subgroup ops make divergence information useless for our purpose,
we would need workgroup divergence.
The game affected here has control flow dependent on vote_any,
so it's possible that a wave only executes the code after culling/reordering
invocations.
That means we can't reuse the maybe undefined value from before culling.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14459
Cc: mesa-stable
(cherry picked from commit cbedced5e8)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
This broke a number of dEQP tests, for reasons that are unclear -- in
looking at cffdumps, the const setup looks appropriate, just changing from
e.g:
VS_CTRL_REG1(CONSTLEN=2)
FS_CTRL_REG1(CONSTLEN=1)
LOAD_STATE6(VERT, DIRECT, DST_OFF=2, NUM_UNIT=2)
LOAD_STATE6(FRAG, DIRECT, DST_OFF=0, NUM_UNIT=2)
to:
VS_CTRL_REG1(CONSTLEN=2)
FS_CTRL_REG1(CONSTLEN=1)
LOAD_STATE6(VERT, DIRECT, DST_OFF=2, NUM_UNIT=2)
LOAD_STATE6(FRAG, INDIRECT, DST_OFF=0, NUM_UNIT=2)
Fixes: 203ac73374 ("gallium: set prefer_real_buffer_in_constbuf0 for all drivers using tc")
(cherry picked from commit 974ca32643)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
The entire range of the allocated bo up to bo->size will be used, even if
alloc_size was way less, so to track the growth precisely for load factoring,
the allocated_batch_size should increase by bo->size.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
(cherry picked from commit 7b74321640)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Although a specific size is requested, the entire range of the returned bo up
to bo->size may end up being used by anv_batch_chain, spamming memcheck errors.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
(cherry picked from commit 4de00e01dd)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Since we use atomic mode setting now, the wsi->fd we use needs to have
the atomic client cap.
There are several different code paths where wsi can acquire a file
descriptor. For drm masters, the atomic client cap is set in
wsi_display_init_wsi. For leased drm fds, there are AcquireDrmDisplayEXT
and AcquireXlibDisplayEXT.
According to a comment we previously assumed wsi_display_get_connector
is common among all code paths, and that's why the atomic client cap was
set there. But that assumption can be broken based on the particular
order which the application invokes vulkan APIs in.
This commit simply push the drmSetClientCap to all entrypoints where a
drm fd comes through.
Fixes: 513ffea1d3 ("wsi/display: use atomic mode setting")
Signed-off-by: Yuxuan Shui <yshui@codeweavers.com>
(cherry picked from commit e0fbf9a908)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Commit e626636e90 ("bin/symbols-check: fix fields length condition
before accessing fields") changed the condition from `or` to `and`
to prevent potential IndexError when accessing fields[1].
However, this broke macOS because `nm -gP` outputs different field
counts for undefined symbols:
- Linux: `_symbol U` (2 fields)
- macOS: `_symbol U 0 0` (4 fields)
The condition `len(fields) == 2 and fields[1] == 'U'` only matched
the Linux format, causing undefined symbols like
_mesa_glapi_tls_Dispatch to be incorrectly reported as
"unknown symbol exported" on macOS.
Fix by using `len(fields) >= 2` to handle both platforms while still
guarding against IndexError.
Fixes: e626636e90 ("bin/symbols-check: fix fields length condition before accessing fields")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13451
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
(cherry picked from commit 191e4b8fe0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Image size queries for buffer images were incorrectly using the
underlying buffer's width instead of the image view's size.
This affected `get_image_width` in OpenCL C for 1Dbuffer images, in
cases where the buffer is larger than the image to account for
padding, breaking the conformance test `test_kernel_image_methods
1Dbuffer`.
Fixes: 0efe7a6eb9 ("panfrost: implement image_size sysval")
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
(cherry picked from commit 95ed8d6638)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
We were previously reporting a larger maxStorageBufferRange than our
maxBufferSize, which is weird. Lower maxStorageBufferRange to match
maxBufferSize.
Fixes crucible stress.limits.buffer-update.range.storage.q0
Fixes: 65f12fde44 ("nvk: Improve address space and buffer size limits")
Reviewed-by: Mary Guillemard <mary@mary.zone>
(cherry picked from commit c9ae59dec5)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
The group implicity selects which flags the instruction can write. This
was discovered while working on another set of changes that could change
some logical operations into predicated MOV instructions.
Prevents regressions later in the series in
dEQP-VK.graphicsfuzz.cov-loop-fragcoord-identical-condition.
No shader-db or fossil-db changes on any Intel platform.
v2: Update the comment in the test case. Suggested by Caio.
Fixes: 95ac3b1dae ("i965/fs: don't propagate cmod when the exec sizes differ")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
(cherry picked from commit ba30794847)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
An example when the memory leak happens: requested_size = 4 and alignment = 65536 in anv_slab_bo_alloc:
The alloc_size = 65536 and requested = 4 in this case.
The group to allocate the entry is the group of size 65536 based on the entry size,
while the group to reclaim the entry is the group of size 4 due to the bo->size is
registered as the requested_size=4 and used in anv_slab_bo_free.
That means, the entry is allocated in group[order of size 65535]->free,
moved from group[order of size 65535]->free to the user, and then moved
to group[order of size 4]->reclaim, so the entries is accumulated in
group[order of size 4]->reclaim and group[order of size 65535] keeps
allocating new entries and leading to OOM.
The solution is to use `bo->actual_size` to get the group in pb_slab_bo_free using the allocation size.
Fixes: dabb012423 ("anv: Implement anv_slab_bo and enable memory pool")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14396
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: hwandy <hwandy@google.com>
(cherry picked from commit ffbe6470a2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
This fixes a page fault when nr_samples=4 but nr_storage_samples=2.
Based on si_is_format_supported this is only supported for color
formats and when has_eqaa_surface_allocator is true (< GFX11).
The referenced commit below didn't introduce the issue but it
exposed it by forcing the gfx blit path to be used.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13255
Fixes: 3424e16ece ("radeonsi: add decision code to select when to use CB_RESOLVE for performance")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 645fff5dae)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
A in-place resolve via the BLT engine is only supposed to fill the
tiles of a single layer of a resource, so the size to calculate the
number of tiles is the layer stride, same as done for the in-place
resolve via the RS engine in
8df11f3fad ("etnaviv: fix in-place resolve tile count.")
CC: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
(cherry picked from commit 075eefc422)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
When swapping buffer with damage regions, to be strictly correct we
need to swap the entire back buffer to the front buffer. This needs to
be done in case the compositor does not support damage regions. This
means we need to ignore the input damage region and tell drisw to swap
the entire buffer.
Cc: mesa-stable
(cherry picked from commit 17ab0f2ece)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
