[Mesa-dev] [PATCH 1/2] blorp: Emit a dummy 3DSTATE_WM prior to 3DSTATE_WM_HZ_OP

[Kenneth Graunke]

On Tuesday, October 16, 2018 1:12:18 PM PDT Jason Ekstrand wrote:
> Suggested-by: Francisco Jerez <currojerez at riseup.net>
> ---
>  src/intel/blorp/blorp_genX_exec.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/intel/blorp/blorp_genX_exec.h b/src/intel/blorp/blorp_genX_exec.h
> index 50341ab0ecf..30025cf4deb 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -1628,6 +1628,15 @@ blorp_emit_gen8_hiz_op(struct blorp_batch *batch,
>      */
>     blorp_emit_3dstate_multisample(batch, params);
>  
> +   /* 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 normal

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
>      * new config is emitted for each additional layer.

Series is:
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181026/7de88649/attachment.sig>