From: Rafael Antognolli Date: Wed, 19 Feb 2020 17:15:49 +0000 (-0800) Subject: intel/blorp: Implement GEN:BUG:1605967699. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9ab0e92cff8bb8336cebd9dc68d02d7451ad78e1;p=mesa.git intel/blorp: Implement GEN:BUG:1605967699. v2: - Update comments and refactor code (Lionel). - Only apply workaround to stencil resolves. Acked-by: Lionel Landwerlin Tested-by: Marge Bot Part-of: --- 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