intel/blorp: Implement GEN:BUG:1605967699.

v2:
 - Update comments and refactor code (Lionel).
 - Only apply workaround to stencil resolves.

Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3909>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3909>

diff --git a/src/intel/blorp/blorp_genX_exec.h b/src/intel/blorp/blorp_genX_exec.h
index 0b5ce029f4cb0feb9cecde0968a3996ee60b94f5..50ac4489a52bdcdb60ee528988e8169f2d6a6405 100644 (file)
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -1743,14 +1743,38 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
       blorp_emit_cc_viewport(batch);
    }
 
-   /* According to the SKL PRM formula for WM_INT::ThreadDispatchEnable, the
-    * 3DSTATE_WM::ForceThreadDispatchEnable field can force WM thread dispatch
-    * even when WM_HZ_OP is active.  However, WM thread dispatch is normally
-    * disabled for HiZ ops and it appears that force-enabling it can lead to
-    * GPU hangs on at least Skylake.  Since we don't know the current state of
-    * the 3DSTATE_WM packet, just emit a dummy one prior to 3DSTATE_WM_HZ_OP.
-    */
-   blorp_emit(batch, GENX(3DSTATE_WM), wm);
+   if (GEN_GEN >= 12 && params->stencil.enabled &&
+       params->hiz_op == ISL_AUX_OP_FULL_RESOLVE) {
+      /* GEN:BUG:1605967699
+       *
+       * This workaround requires that the Force Thread Dispatch Enable flag
+       * needs to be set to ForceOFF on the first WM_HZ_OP state cycle
+       * (followed by a CS Stall):
+       *
+       *    "Workaround: There is a potential software workaround for the
+       *    issue by doing these 2 steps 1) setting the force thread dispatch
+       *    enable(bits 20:19) in the 3dstate_WM_body state to be set to
+       *    Force_OFF (value of 1) along with the first WM_HZ_OP state cycle.
+       *    The second WM_HZ_OP state which is required by programming
+       *    sequencing to complete the HZ_OP operation can reprogram the
+       *    3dstate_WM_body to set to NORMAL(value of 0)."
+       */
+      blorp_emit(batch, GENX(3DSTATE_WM), wm) {
+         wm.ForceThreadDispatchEnable = ForceOff;
+      }
+      blorp_emit(batch, GENX(PIPE_CONTROL), pipe) {
+         pipe.CommandStreamerStallEnable = true;
+      }
+   } else {
+      /* According to the SKL PRM formula for WM_INT::ThreadDispatchEnable, the
+       * 3DSTATE_WM::ForceThreadDispatchEnable field can force WM thread dispatch
+       * even when WM_HZ_OP is active.  However, WM thread dispatch is normally
+       * disabled for HiZ ops and it appears that force-enabling it can lead to
+       * GPU hangs on at least Skylake.  Since we don't know the current state of
+       * the 3DSTATE_WM packet, just emit a dummy one prior to 3DSTATE_WM_HZ_OP.
+       */
+      blorp_emit(batch, GENX(3DSTATE_WM), wm);
+   }
 
    /* If we can't alter the depth stencil config and multiple layers are
     * involved, the HiZ op will fail. This is because the op requires that a
@@ -1812,6 +1836,18 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
       pc.Address = blorp_get_workaround_page(batch);
    }
 
+
+   if (GEN_GEN >= 12 && params->stencil.enabled &&
+       params->hiz_op == ISL_AUX_OP_FULL_RESOLVE) {
+      /* GEN:BUG:1605967699
+       *
+       *    The second WM_HZ_OP state which is required by programming
+       *    sequencing to complete the HZ_OP operation can reprogram the
+       *    3dstate_WM_body to set to NORMAL(value of 0)."
+       */
+      blorp_emit(batch, GENX(3DSTATE_WM), wm);
+   }
+
    blorp_emit(batch, GENX(3DSTATE_WM_HZ_OP), hzp);
 }
 #endif