It appears to be possible that IDLE is observed before COMPLETE.
In this case, an application may access present_id in subsequent
QueuePresentKHR and race against the fence worker reading present_id.
Solve this by adding a separate signal_present_id that is used when
completing to avoid the race.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22633>
Previously, continue preambles and postambles were added directly to
the CS array which means all BOs were correctly added to the BO list,
and this has been broken recently. IB BOs need to be added to the list.
When a BO isn't added to the list as part of a submission, it might
randomly VM faults.
This fixes VM faults and random GPU hangs on NAVI21 in Mesa CI.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8849
Fixes: 41a9bced31 ("radv: Fill continue preambles and postambles properly.")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22625>
Previously zink ignored whether multisampling was enabled and rendered
with mulisampling whenever the target buffer had multiple samples.
This change now will only render with multisampling when it is enabled
and will use a lowering pass to make sure this case is handled correcly.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22626>
when a ms fallback texture is created, it has to actually be a ms texture
in order to be consistent with driver expectations for a given sampler in
a shader
this adds sample querying to both ends of the fallback creation to ensure
that a sample count is passed to the driver
affects:
KHR-GL46.sample_variables.position.fixed.samples_0
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22492>
this is only hit when populating multisampled fallback textures, so
don't assert if it fails since some drivers are able to handle it
d3d12 can't, however, and this should be enough to work around that issue
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22492>
vkcts-navi10-valve has the nasty habit on hanging the GPU, so we
introduced an auto-retry... but for every radv job. Let's stop doing
that, and instead limit the auto-retry to vkcts-navi10-valve only.
Additionally, let's increase the number of attempts to 3 (2 retries),
as sometimes, it may still fail and we don't want to flag it as a
fail in nightly runs.
Let's hope we'll get to the bottom of this hang sooner rather than
later, so that we can remove this hack!
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22596>
So far we were only considering the number of vertices to draw to
compute the offset in a stream output buffer.
But this is not correct, as it depends on the primitive type too. For
instance, with 4 vertices, if we use a triangle strip primitive, then 2
triangles are generated from those 4 vertices, so 6 vertices will be
captured.
This fixes spec@!opengl es
3.0@gles-3.0-transform-feedback-uniform-buffer-object.
CC: 23.1
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22607>
This lets us follow the Vulkan spec requirements for MSAA line
rasterization, using a width of 1.0 instead of D3D's proscribed
width of 1.4. There's no reason to predicate this on MSAA being
enabled, since quadrilateral lines with a width of 1.0 are actually
the most desired type of line rasterization for Vulkan.
Follow-ups:
- We can probably turn on 'strict lines' when this is supported.
- We should enable the line rasterization mode extension.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22606>
For MTL (verx10 == 125), float64 is supported, but int64 is not.
Therefore we need to lower cluster broadcast using 32-bit int ops.
For gfx12.5+ platforms that support int64, the register regions
used by cluster broadcast aren't supported by the 64-bit pipeline.
On MTL, dEQP-VK.subgroups.clustered.*_double* and
dEQP-VK.subgroups.clustered.*_dvec* were failing to validate the
compiled shader in debug mode, and reportedly gpu-hanging in release
mode.
With this change dEQP-VK.subgroups.clustered.*_double* passed all 48
tests and dEQP-VK.subgroups.clustered.*_dvec* passed all 140 tests on
MTL.
Rework:
* Move from generator to brw_fs_lower_regioning.cpp. (Suggested by
Francisco)
* Apply to verx10 >= 125.. (Suggested by Francisco)
Cc: 23.1 <mesa-stable>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> (v1)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22569>
This is really noticeable for games that resolve a bunch of occlusion
queries (in this case 4096) because it seems that emitting 4096
WAIT_REG_MEM packets can stall more than expected. Fixes this by
waiting for queries in the resolve query shader.
This improves performance of an unreleased game by +~10% (71->78 FPS).
RADV should now be really close to Windows performance for that title.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22579>
This function was returning the size of a single region header as the stride
when it was supposed to be returning the total size of the region headers for a
single render target. This went unnoticed due to the fact this function had two
variables with basically identical names. To avoid any future confusion, rename
rgn_header_size to single_rgn_header_size throughout the code.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22574>
Tatsuyuki Ishi