vc4: Add a workaround for HW-2905, and additional failure I saw with MSAA.
authorEric Anholt <eric@anholt.net>
Sat, 21 Nov 2015 04:25:46 +0000 (20:25 -0800)
committerEric Anholt <eric@anholt.net>
Tue, 8 Dec 2015 17:49:54 +0000 (09:49 -0800)
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.

src/gallium/drivers/vc4/vc4_emit.c

index 864263866f438165447ff3a8eff4471dc7206790..5d6479777551fc5b8c97e63cd2e3b53806379ad0 100644 (file)
@@ -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) {