Mesa (master): intel/blorp: Implement GEN:BUG:1605967699.
GitLab Mirror
gitlab-mirror at kemper.freedesktop.org
Tue Feb 25 00:38:29 UTC 2020
Module: Mesa
Branch: master
Commit: 9ab0e92cff8bb8336cebd9dc68d02d7451ad78e1
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9ab0e92cff8bb8336cebd9dc68d02d7451ad78e1
Author: Rafael Antognolli <rafael.antognolli at intel.com>
Date: Wed Feb 19 09:15:49 2020 -0800
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 at 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>
---
src/intel/blorp/blorp_genX_exec.h | 52 +++++++++++++++++++++++++++++++++------
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/src/intel/blorp/blorp_genX_exec.h b/src/intel/blorp/blorp_genX_exec.h
index 0b5ce029f4c..50ac4489a52 100644
--- 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
More information about the mesa-commit
mailing list