Now that we have a solid logic for caching meta objects, trying to
reduce the number of format variants isn't super useful. In practice,
the shaders would be cached on disk, so this would only allocate few
more bytes for the meta objects.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39786>
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>
On GFX10+, the hardware can write decompressed DWORDS to HTILE when
COMPRESSION_EN=1, which means some HTILE decompression/initialization
operations can be avoided because it automatically mark the tiles that
are touched as uncompressed.
Though according to PAL, there are issues with that on GFX10-10.3, so
it's only enabled on GFX11-11.5.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39656>
Only for partial copies because image stores don't decompress on writes
(ie. HTILE isn't updated by image stores).
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39656>
The driver either does a fast-clear using compute or a slow clear
using graphics, so the "fast" clear using graphics isn't used at all.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39731>
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>
In glibc 2.43 the strstr function now propagate const to the output, triggering -Wincompatible-pointer-types-discards-qualifiers
under clang/gcc with -Werror.
Fix two of these cases by adding the const qualifier.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39767>
This could return the graphics DCC pipeline if it was created before,
and crash or potentially hang the GPU.
Found this while working on in-progress VKCTS coverage.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39689>
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>
Avoiding NaNs should have the same effect but it's good practice to not
rely on float OPs for correctness.
Fixes: 95a89f7 ("radv: Report smaller bvh sizes when possible")
Reviewed-by: Natalie Vock <natalie.vock@gmx.de>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39640>
