tu: Read some input attachments directly
authorConnor Abbott <cwabbott0@gmail.com>
Thu, 5 Aug 2021 12:52:00 +0000 (14:52 +0200)
committerConnor Abbott <cwabbott0@gmail.com>
Tue, 10 Aug 2021 14:45:53 +0000 (16:45 +0200)
commit380d4904ea6402f2829f9c0cf801c9d0996e61b8
tree875c04473e1557fb67ea1d5027491dd28f7f6373
parent11ac7d9e0254d7b6cf564df89867d6973830b6ff
tu: Read some input attachments directly

It can happen that the user reads an input attachment as the first use
of that attachment. In that case there are no subpass dependencies
required at all, because there could be a pipeline barrier before the
renderpass instead, and in any case we assume that dependencies with the
first subpass as a destination can be executed only once outside the
renderpass. The result is that we only do a CACHE_INVALIDATE once
before the entire renderpass, but it's actually required after each GMEM
load, because input attachments read GMEM through UCHE and those writes
to GMEM invalidate UCHE.

While we could add the missing CACHE_INVALIDATE "by hand" somehow, it
turns out it's actually just as easy to do an optimization the blob
does, where it simply doesn't patch those input attachments and reads
them directly instead. This means we can skip allocating memory in GMEM
for them entirely in some circumstances.

This fixes e.g.
dEQP-VK.api.copy_and_blit.core.resolve_image.whole_array_image.4_bit
with TU_DEBUG=forcebin.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12213>
src/freedreno/ci/deqp-freedreno-a630-fails.txt
src/freedreno/vulkan/tu_cmd_buffer.c
src/freedreno/vulkan/tu_pass.c
src/freedreno/vulkan/tu_private.h