Empirically, TCS outputs have to be aligned to 64 bytes,
otherwise stale data may be read in rare cases. The exact
reason is not clear, but tests and proprietary driver behavior
strongly point at the need for 64 byte alignment.
Fixes tesselation issues in at least "Conan Exiles" but likely in many
more cases.
CC: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39890>
Venus uses vkImportSemaphoreFdKHR() with FD == -1 to signal a binary
semaphore and vkGetSemaphoreFdKHR() to wait on a binary semaphore.
Both KK and Dzn uses vk_sync_binary so supporting this special case for
import/export sync file will enable Venus host support.
Reviewed-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39067>
Pack/unpack should be a lot faster than duplicating the subgroup op.
No fossil-db changes, but multiple people complained about this to me.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40024>
This probably doesn't do anything because sgpr_read_by_valu are all set
already for raytracing shaders.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39825>
Wire up the existing Panfrost dithering infrastructure to the Vulkan
extension. The library already supports dithered formats via
pan_dithered_format_from_pipe_format(), so this plumbs the
VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT flag through to the blend
descriptor emission and color attachment internal conversion paths.
Dithering is only applied to color attachments, not depth or framebuffer
preloads.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39781>
If a set layout is missing the driver can't compute the dynamic buffer
start offsets correctly. The only solution is to load these offsets from
an user SGPR.
To avoid adding more complexity, these offsets are re-emitted every
time dynamic buffers are dirty. That shouldn't matter because the
combination of dynamic buffers and independent sets is just super rare.
This fixes new VKCTS coverage
dEQP-VK.pipeline.pipeline_library.graphics_library.independent_sets_random.*.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39988>
The Vulkan spec says:
"The contents of pRenderingInfo must match between suspended
render pass instances and the render pass instances that resume
them, other than the presence or absence of the0
VK_RENDERING_RESUMING_BIT, VK_RENDERING_SUSPENDING_BIT, and
VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT flags. No
action or synchronization commands, or other render pass
instances, are allowed between suspending and resuming render
pass instances. All pairs of resuming and suspending render passes
must be submitted in the same batch. "
So it should be safe to avoid re-emitting the rendering state because
nothing can blow it up.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40004>
This is possible since VK_KHR_maintenance10.
This fixes new VKCTS coverage in
dEQP-VK.pipeline.*.multisample.m10_resolve.*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39956>
In some situations we can have multiple present queued
with the same target_msc and in this case we might get
the last one signaled before the previous ones. Here's
an example with some debug logs added to the relevant
functions:
loader_dri3_swap_buffers_msc: new send_sbc=2323 - target_msc=337
dri3_handle_present_event: old recv_sbc=2322 msc=338 new_recv_sbc=2323
loader_dri3_swap_buffers_msc: new send_sbc=2324 - target_msc=338
dri3_handle_present_event: old recv_sbc=2323 msc=338 new_recv_sbc=2324
loader_dri3_swap_buffers_msc: new send_sbc=2325 - target_msc=338
dri3_handle_present_event: old recv_sbc=2324 msc=338 new_recv_sbc=2325
loader_dri3_swap_buffers_msc: new send_sbc=2326 - target_msc=338
loader_dri3_swap_buffers_msc: new send_sbc=2327 - target_msc=338
loader_dri3_swap_buffers_msc: new send_sbc=2328 - target_msc=338
dri3_handle_present_event: old recv_sbc=2325 msc=338 new_recv_sbc=2327
loader_dri3_swap_buffers_msc: new send_sbc=2329 - target_msc=338
dri3_handle_present_event: old recv_sbc=2327 msc=338 new_recv_sbc=2328
loader_dri3_swap_buffers_msc: new send_sbc=2330 - target_msc=338
dri3_handle_present_event: old recv_sbc=2328 msc=338 new_recv_sbc=2329
loader_dri3_swap_buffers_msc: new send_sbc=2331 - target_msc=338
dri3_handle_present_event: old recv_sbc=2329 msc=338 new_recv_sbc=2330
dri3_handle_present_event: old recv_sbc=2330 msc=338 new_recv_sbc=2326 # oops
dri3_handle_present_event: old recv_sbc=2326 msc=339 new_recv_sbc=2331
It's usually harmless, except if Mesa ends up using
loader_dri3_swapbuffer_barrier right after the out-of-order event.
In this example it's ok because more swaps are executed after 2330, so
waiting for read_sbc>=2330 would work anyway.
But if this wasn't the case, loader_dri3_swapbuffer_barrier would never
return, waiting for recv_sbc to become >= 2330 while it's stuck at 2326
because the later swaps were processed earlier.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39857>
This prevents re-entering the flush if during the flush
of a context X we end up in vbo_exec_FlushVertices_internal.
I had this issue on one machine, with the following simplified
call sequence:
glthread_unmarchash_batch
...
vbo_exec_FlushVertices(ctxA)
...
st_validate_state
...
dri3_get_buffer
loader_dri3_blit_context_get
...
dri_destroy_context(ctxB)
...
_mesa_make_current(ctxB)
vbo_exec_FlushVertices(ctxA)
The last vbo_exec_FlushVertices would hit the assert checking
flush_call_depth == 1.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39857>
I don't know why but these seem to fail only intermittantly now.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
As a side-effect, we're now also respecting storeOp for separate Z/S.
For interleaved, we still always store because interleaved is annoyingly
complicated.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The new framebuffer code properly handles attachments without a store
and the incremental rendering code doesn't rely on the store, either, so
we don't need to always store.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This is mostly a matter of reworking the frame shader code to pull image
views from a temp struct instead of always reaching for the pan_fb_load.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
We already have this check for the JM back-end but the CSF back-end
based the choice on whether or not the shader is writing color which
isn't quite what we want.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This makes cmd_emit_dcd() about actually emitting the DCD and moves the
bit that's operation-specific to the operation-specific function.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Also rename some stuff internally to stop using the word "preload".
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Instead of having the pan_fb code have to `max(rt_count, 1)` add then
constantly be doing the same in the driver, just make the condition an
assert and do the `max(colorAttachmentCount, 1)` up-front. This way
we're not constantly worried if everyone has the same count or not. The
pan_fb code will handle having an empty render target just fine.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The resolve sits between the render pass and the write at the end. This
adds the resolve ops themselves, support in the shader builder for
building the post-frame shaders to handle them, and an optimization pass
that attempts to fold the resolve op into the store and potentially
eliminate the post-frame shader.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
