vc4: Add a workaround for HW-2905, and additional failure I saw with MSAA.

I only stumbled on this while experimenting due to reading about HW-2905.
I don't know if the EZ disable in the Z-clear is actually necessary, but
go with it for now.

1 files changed, 16 insertions, 2 deletions

diff --git a/src/gallium/drivers/vc4/vc4_emit.c b/src/gallium/drivers/vc4/vc4_emit.c
index 864263866f4..5d647977755 100644
--- a/src/gallium/drivers/vc4/vc4_emit.c
+++ b/src/gallium/drivers/vc4/vc4_emit.c
@@ -72,6 +72,20 @@ vc4_emit_state(struct pipe_context *pctx)
         }
 
         if (vc4->dirty & (VC4_DIRTY_RASTERIZER | VC4_DIRTY_ZSA)) {
+                uint8_t ez_enable_mask_out = ~0;
+
+                /* HW-2905: If the RCL ends up doing a full-res load when
+                 * multisampling, then early Z tracking may end up with values
+                 * from the previous tile due to a HW bug.  Disable it to
+                 * avoid that.
+                 *
+                 * We should be able to skip this when the Z is cleared, but I
+                 * was seeing bad rendering on glxgears -samples 4 even in
+                 * that case.
+                 */
+                if (vc4->msaa)
+                        ez_enable_mask_out &= ~VC4_CONFIG_BITS_EARLY_Z;
+
                 cl_u8(&bcl, VC4_PACKET_CONFIGURATION_BITS);
                 cl_u8(&bcl,
                       vc4->rasterizer->config_bits[0] |
@@ -80,8 +94,8 @@ vc4_emit_state(struct pipe_context *pctx)
                       vc4->rasterizer->config_bits[1] |
                       vc4->zsa->config_bits[1]);
                 cl_u8(&bcl,
-                      vc4->rasterizer->config_bits[2] |
-                      vc4->zsa->config_bits[2]);
+                      (vc4->rasterizer->config_bits[2] |
+                       vc4->zsa->config_bits[2]) & ez_enable_mask_out);
         }
 
         if (vc4->dirty & VC4_DIRTY_RASTERIZER) {