tu: Align GMEM resolve blit scissor
authorConnor Abbott <cwabbott0@gmail.com>
Thu, 16 Apr 2020 09:39:11 +0000 (11:39 +0200)
committerMarge Bot <eric+marge@anholt.net>
Thu, 16 Apr 2020 12:00:22 +0000 (12:00 +0000)
commit0c05d46237db3095ef92d61452d886286806a827
tree2d104aea9547efe6d8066b902d9b338cc0fa632d
parentd2e172c03f7170382e8d93b2ad04f3ca92b2020f
tu: Align GMEM resolve blit scissor

Even though we normally use the CP_BLIT path with resolves that aren't
aligned, there's a special case when we're resolving the entire image
and there's enough padding so that we can still use CP_EVENT_WRITE::BLIT
when the render area isn't aligned. The hardware seems to not like
unaligned scissors when not clearing, and sometimes hangs rather than
silently round the scissor. This causes hangs in e.g.
dEQP-VK.glsl.derivate.dfdx.texture.msaa4.float_highp.

There was some concern that the CP_BLIT path might use this scissor
also, but I confirmed that this isn't the case by setting it to 0 before
resolving and then noting that CP_BLIT still works (but CP_EVENT_WRITE
doesn't). Furthermore, this is actually impossible because of how the 2D
engine is set up: it gets its own pair of register banks, which can be
switched independently of the 3D register banks, so that 2D events
(CP_BLIT) normally aren't synchronized relative to 3D events
(CP_EVENT_WRITE, CP_DRAW_*, and CP_EXEC_CS) and therefore they can't
share any registers except for non-pipelined registers like RB_CCU_CNTL
that don't use the register bank mechanism at all.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4585>
src/freedreno/vulkan/tu_cmd_buffer.c