VK_IMAGE_LAYOUT_PREINITIALIZED is only well defined for linear images
in Vulkan, and linear images can't have DCC. So, this was dead code.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40070>
Cache flushes should be skipped on SDMA. In practice,
radv_emit_cache_flush() should only be called on GFX/ACE.
SDMA NOP packets are emitted in barriers directly.
This fixes recent VKCTS coverage
dEQP-VK.api.command_buffers.secondary_on_transfer_queue.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39964>
There's no reason to have these checks be smeared between
radv_image_need_retile and radv_retile_transition.
Make radv_image_need_retile verify that the image might ever
need to have its displayable DCC updated.
Also, radv_image_need_retile should not care about the command
buffer. We should never try to do retile transition on a
command buffer that can't do compute to begin with.
Make radv_retile_transition only check whether the layout
we're transitioning to might involve reading the displayable
DCC, and perform retiling if so.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39990>
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>
The current approach of explicitly saving/restoring some states is
unnecessarily complicated and inefficient. For example, some meta OPs
that use memory fills/copies will have nested save/restores. This patch
is the first step towards avoiding unnecessary state re-emits around
meta OPs.
The changes are:
- Move radv_meta_saved_state to radv_cmd_buffer::state
- Add radv_meta_begin/end helpers that initialize radv_meta_saved_state
and restore states used by the meta OP
- Remove all explicit saves/restores, use the new helpers
radv_meta_begin/end is called inside the entrypoint and not some nested
helper function which means that state is only restored once per meta
OP.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39774>
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39720>
The Vulkan spec says:
"Store and resolve operations are only performed at the end of a
render pass instance that does not specify the
VK_RENDERING_SUSPENDING_BIT_KHR flag."
VK_RENDERING_SUSPENDING_BIT is also illegal with custom resolves.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39782>
This is mostly for not calling CmdBeginRendering() while rendering
is already active in order to catch potential driver issues. This
requires a small refactoring of how the rendering info is passed for
resolves though.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39782>
Right after "normal" layout transitions and just before the rendering
state is set, mostly because it doesn't need to be saved/restored
either.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39729>
This was an oversight of VK_KHR_dynamic_rendering_local_read which has
been addressed by VK_KHR_maintenance10 which introduced new flags to
give more information to implementations.
The Vulkan spec says:
"VK_RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR is
intended to give implementations similar information as a subpass
where an attachment could be used as both a color attachment and
input attachment. Some implementations require extra work to make
this scenario work beyond just considering the image layouts.
Implementations which have no such considerations may treat this
flag as a noop. The primary use case for this flag is to enable
feedback loops inside a single shader."
"Applications are encouraged to use
VK_RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR if
maintenance10 is available and they use feedback loops with
VK_KHR_dynamic_rendering_local_read. Feedback loops are still
allowed when not using the rendering flag, but the performance
implication was an oversight in the original definition of
VK_KHR_dynamic_rendering_local_read."
Because it's clearly defined by the Vulkan spec, let's just pessimize
always to avoid relying on some shaders state which require to do very
late decompression passes. This will allow us to do more cleanups and
optimizations related to the framebuffer. Also note that DRLR is still
a niche feature.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39538>
If the rendering state is inherited in the secondary, otherwise nothing
wait for the pending flushes after a decompression pass. One more
argument to stop delaying this.
Fixes
dEQP-VK.renderpasses.dynamic_rendering.partial_secondary_cmd_buff.local_read.*
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39678>
This is just wrong if the secondary uses ESO because the emitted
pipelines would be NULL in the secondary, but if the app re-binds
the same pipeline in the primary it would consider it as already
emitted. A sequence like this would break:
CmdBindPipeline(compute)
CmdDispatch()
CmdExecuteCommands() --> with ESO compute
CmdBindPipeline(compute)
CmdDispatch()
This tracking is probably useless anyways because it's unlikely that
apps will rebind the same pipeline right after CmdExecuteCommands() but
let's keep it because this is a bugfix.
Fixes
dEQP-VK.api.command_buffers.pipeline_shader_object_mix_with_secondaries.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39587>
PAL always set WD_SWITCH_ON_EOP for pre gfx10 when primitive
restart is enabled to prevent gpu hang.
It only happens when specific index stream with primitive
restart. Since we don't know what's the exact problem,
just follow PAL to disable 4x primitive rate when primitive
restart is enabled.
GFX10+ does not use this function.
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39292>
If the main CS is SDMA and the gang CS is ACE, this would emit a
SDMA_FENCE packet on ACE which just hangs.
Fixes: b1938901d0 ("radv: Use SDMA fence packet when flushing gang semaphores")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39211>
