We currently only create one queue per queue family on the device. The
device can be shared between multiple zink_screens, so having one lock
per screen can still lead to multiple locks per queue. Fix this by
allocating queue_lock along with the device.
This fixes an issue that was causing crashes with nvk+zink and
QtWebEngine with QTWEBENGINE_FORCE_USE_GBM=1 This can be reproduced by
resizing the window in either:
* anki - https://apps.ankiweb.net/ or
* Qt's simplebrowser example
https://doc.qt.io/qt-6/qtwebengine-webenginewidgets-simplebrowser-example.html
which would then cause this dmesg error:
nouveau 0000:01:00.0: anki[92007]: Failed to find syncobj (-> in): handle=40
along with a context loss.
With VK_LOADER_LAYERS_ENABLE=VK_LAYER_KHRONOS_validation we would additionally
get warnings like:
Validation Error: [ UNASSIGNED-Threading-MultipleThreads-Write ] | MessageID = 0xa05b236e
vkQueueSubmit(): THREADING ERROR : object of type VkQueue is simultaneously used in current thread 139824449189568 and thread 139823901816512
Objects: 1
[0] VkQueue 0x557a666783e0
Fixes: 015eda4a41 ("zink: deduplicate VkDevice and VkInstance")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38414>
(cherry picked from commit 9acce36652)
We were overflowing an array during bifrost disassembly. This was
only a problem if the user explicitly set an environment variable,
so unlikely to occur in casual use, and also only could be triggered
in very specific, dense code. But we still should get this right!
The specific CTS test that caused the assert is:
'dEQP-VK.graphicsfuzz.stable-quicksort-for-loop-with-injection'
with environment variable `BIFROST_MESA_DEBUG=shaders`. One of the
shaders has a clause with 6 constants (the maximum) and this overflowed
the array because we assume we always have an extra slot (used for
modifier processing).
Cc: mesa-stable
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38501>
(cherry picked from commit 65ba14519e)
GL_EXT_texture_buffer_object requires support for alpha, luminance,
luminance-alpha and intensity formats. If we can't support those, we
can't enable the extension.
Fixes: 45ca7798dc ("glsl: handle interactions between EXT_gpu_shader4 and texture extensions")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
(cherry picked from commit 6f2b8c3f61)
Most of the time, we remember to check for both extensions. But in one
case, it seems we forgot the GLES extension. Whoops.
Let's switch to a helper here, so we don't have to repeat the logic over
and over again.
Fixes: b4c0c514b1 ("mesa: add OES_texture_buffer and EXT_texture_buffer support")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
(cherry picked from commit 9d5e0c1ad2)
Some GPU hangs witnessed in the wild on RDNA4 in Control and Arc Raiders
seem to point towards closest-hit shaders reading a stale value for the
SGPR pair containing the currently-executing shader's address.
This SGPR pair was read by VALU in the preceding traversal shader,
making it susceptible to VALUReadSGPRHazard. Inserting
VALUReadSGPRHazard mitigations before accessing the s_setpc target seems
to fix the hang. We don't have conclusive proof that this is hazardous,
but given that all signs point towards it and we have a reasonably
simple workaround, let's roll with this for now to mitigate the hangs.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38290>
(cherry picked from commit 1243d575a5)
When no workgroup size is specified we try to run with the most optimal one
possible. However we didn't take into account that we shouldn't run a
workgroup of higher dimensionality than requested by the application.
Fixes: 376d1e6667 ("rusticl: implement cl_khr_suggested_local_work_size")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38375>
(cherry picked from commit d46be8fbf2)
There were two issues:
1. The global_work_offset parameter is optional but we errored on NULL
2. We didn't return the reqd_work_group_size when set on the kernel.
Fixes: 376d1e6667 ("rusticl: implement cl_khr_suggested_local_work_size")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38375>
(cherry picked from commit 810dca450c)
We set sparseImageInt64Atomics to false on these formats, so there's
no need for the software detiling. Thus, we can not set the flag,
which will make ISL pick Tile64 for these formats, and things will
work.
Thanks to Lionel for pointing the fix here.
Testcase: dEQP-VK.api.info.image_format_properties.*d.optimal.r64_*int
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit a1628aba1f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38526>
_math_matrix_is_dirty() should only be used to decide if we need to
run _math_matrix_analyse(). We already decided that we had a new
texture matrix when we called _mesa_update_texture_matrices() so
we need to set _TexMatEnabled correctly otherwise we might
incorrectly return _NEW_FF_VERT_PROGRAM | _NEW_FF_FRAG_PROGRAM in
the following if-statement.
Fixes: ec978e002f ("mesa: only update fixed-func programs on texture matrix enablement changes")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14286
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38473>
(cherry picked from commit b0047be0c2)
The VMA of VkDeviceMemory has to accomodate all the resources that can
be bound to it. For sparse images it's 64KiB alignment, for other
tiled images it's 4KiB. But we also have a workaround that requires a
64KiB alignment for Tile4 images.
The initial version of the slab allocator missed the 4KiB alignment.
This fix adds the workaround handling too.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: dabb012423 ("anv: Implement anv_slab_bo and enable memory pool")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38480>
(cherry picked from commit 401b2066b0)
We need to make sure the data part returned by sampler messages is
always aligned to a physical register. Just like the residency data
lives in a single physical register after the data.
Lowering a vec3 16bits per components led to a half a physical
register allocation which then confused the descriptor lowering
(expecting physical register units).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 295734bf88 ("intel/fs: fix residency handling on Xe2")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12794
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34008>
(cherry picked from commit 61d6aea401)
SB_ID(LS) is currently equal to zero, so this is not a behavior change,
but worth setting it explicitly for clarity and in case the sb
assignments change.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 885805560f ("panvk/csf: fix case where vk_meta is used before PROVOKING_VERTEX_MODE_LAST")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38458>
(cherry picked from commit ebbf05f9d2)
We check fn_set_fbds_provoking_vertex_stride == 0 to determine whether a
previous function variant has already been allocated, so this value must
be initialized to zero before we start the loop. We could fix this by
explicitly initializing just that field, but I figure it's simpler and
safer to just zero-initialize the whole struct.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 885805560f ("panvk/csf: fix case where vk_meta is used before PROVOKING_VERTEX_MODE_LAST")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38458>
(cherry picked from commit e899bc8be8)
send.ugm (1|M0) r125 r0 null:0 0x0 0x0200651F {$9} // wr:1+0, rd:0; fence invalid flush type scoped to tile
When destination of Send(s) is not null, the response length must not be 0.
Should only affect DG2 products.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38478>
(cherry picked from commit 4816318887)
The flag mega_fetch should be set on rv770 for a
read scratch operation (as written in the r700
documentation p357). Without this flag, read scratch
does not work and a gpu hang could be triggered.
Here are the tests fixed:
shaders/glsl-predication-on-large-array: fail pass
spec/glsl-1.10/execution/temp-array-indexing/glsl-fs-giant-temp-array: fail pass
spec/glsl-1.10/execution/temp-array-indexing/glsl-vs-giant-temp-array: fail pass
spec/glsl-1.30/execution/fs-large-local-array: fail pass
spec/glsl-1.30/execution/fs-large-local-array-vec2: fail pass
spec/glsl-1.30/execution/fs-large-local-array-vec3: fail pass
spec/glsl-1.30/execution/fs-large-local-array-vec4: fail pass
spec/glsl-1.30/execution/fs-multiple-large-local-arrays: fail pass
Fixes: 9c48a139b0 ("r600g: Support emitting scratch ops")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38353>
(cherry picked from commit f8de09a811)
This was copied from radeonsi which expected seq_force_screen_content_tools = 2
and seq_force_integer_mv = 2.
Fixes: 37e71a5cb2 ("radv/video: add support for AV1 encoding")
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38371>
(cherry picked from commit 3858a6a696)
Disable sparse mappings on GFX7-8 due to GPU hangs in the VK CTS,
except Polaris where it happens to work "well enough" to pass
the VK CTS and run some games already.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38304>
(cherry picked from commit 567e1b56ef)
Also disable the sparse binding queue and other related features.
Using sparse on GFX6-8 can cause GPU hangs at the moment.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38304>
(cherry picked from commit 1c8881fc60)
To avoid incompatibility between the compiler implementations used by
the driver and the renderer, seq_cst ordering is picked here, which has
required a full mfence instruction. Then the renderer side acquire is
ensured to be ordered after the cache flush of ring cs updates.
Perf wise, there's no regression in headless vkmark runs. In theory,
the overhead introduced here weighs trivially as compared to the ring
cs encode/decode part. So we should go for better robustness.
Test: venus on windows guest works with renderer on Linux
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14277
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38435>
(cherry picked from commit 07d059f3e2)
VCN requires the luma/chroma VAs to be 256 aligned. On VCN5, the
collocated buffer was not 256 aligned which can cause these VAs to be
unaligned.
This fixes VVL PositiveVideoEncodeH264.Basic on VCN5.
Fixes: 37e71a5cb2 ("radv/video: add support for AV1 encoding")
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38408>
(cherry picked from commit 8848495875)
CTA-861-G section 6.9.1 Static Metadata Type 1 declares that zero values
for different groups of HDR Metadata properties are allowed, including
zero nits values for max display mastering luminance, max content light
level, max frame-average light level and min display mastering luminance.
A zero value is meant to be treated by the video sink as "undefined" /
"unknown", and handled accordingly. This is common for dynamically
generated visual content.
The is_hdr_metadata_legal() function in the Vulkan/WSI/Wayland HDR backend
currently declares HDR light level metadata as invalid if the mastering
display min_luminance and max_luminance light levels are set to the legal
level of zero nits. This causes valid HDR metadata as set by the client
via vkSetHdrMetadata() to be not sent to the compositor.
Fix this by skipping checks that don't apply if min_luminance or
max_luminance are zero. If max_luminance is zero then we skip sending
of mastering display min/max luminance to Wayland, as sending a a
max_luminance <= min_luminance would trigger a protocol error. All
other valid data is still send, ie. color primaries, white-point,
content light levels.
Fixes: cb7726bb2c ("vulkan/wsi: validate HDR metadata to not cause protocol errors")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Co-authored-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Xaver Hugl <xaver.hugl@kde.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38326>
(cherry picked from commit 490f05f82c)
Previously the type info for nested values was copied from the source
operand, rather than propagating the new type from the destination
operand.
Fixes: 4c363acf94 ("vtn: Allow for OpCopyLogical with different but compatible types")
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38248>
(cherry picked from commit 7ac1f7777d)
For GS streamout, we need the following LDS scratch space:
- Repacking streamout vertices takes 1 dword per 4 waves per stream
(max 16 bytes for Wave64, max 32 bytes for Wave32)
- 1 dword per stream for buffer info
(16 bytes)
- 1 dword per buffer for buffer info
(16 bytes)
Previously, the space used for buffer info aliased with the
space for repacking the output vertices in ngg_gs_finale(),
and there was no barrier in between, which caused a race
condition, resulting in random failure.
Fix this by allocating a few more LDS dwords so that aliasing
is not required, which also allows us to remove an extra
workgroup barrier.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12705
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38364>
(cherry picked from commit 8f99d736d0)
LAVA jobs already have a global 1h timeout in GitLab. This exists because
GitLab jobs must start before we can determine whether a device is
available for testing.
Jobs themselves do not normally run that long, most of the delay comes
from waiting in the LAVA queue.
Dropping these overrides for pre-merge jobs fixes cases where the LAVA
job isn't picked up in time.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38395>
(cherry picked from commit 13a20f6571)
Backporting 96db490318 ("radv/video: Don't require encode FW version >= interface version")
to 25.2 wasn't correct. There isn't a check for write_memory support to
enable video encode, like there is in 25.3. The FW interface version check
was the only condition to enable video encode and it was removed.
Bring back the FW version check to enable video encode.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14285
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38417>
1. The prolog needs to have a null check. Libraries don't have prologs.
2. We only need to print the shaders actually included in this pipeline.
Libraries were already printed separately.
3. The traversal shader was wrongly omitted from the output.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38355>
(cherry picked from commit 73a31dafbc)
Per ARB_vertex_program spec result registers are 4-component and initially
undefined, and the FF fragment program expects its intputs to be
4-component too. So, if the client's vertex program does not write the
whole vector it will cause misrenderings unless the same client also
supplies fragment program that expects less than 4 componens.
This commit adds a workaround that initializes results to vec4(0, 0, 0, 1)
which seems to be an expected behavior for such clients.
Cc: mesa-stable
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38295>
(cherry picked from commit f03432c81a)
