[Mesa-stable] [PATCH 08/11] i965/blorp: Do a depth flush/stall prior to HiZ operations

[Jason Ekstrand]

Without this stall, the test group ES3-CTS.functional.fbo.msaa.\* hangs
about 1 out of every 2 or 3 times on my Sky Lake GT3 laptop.  With the
flush and stall, I can run it 6 times in a row without a hang.

Cc: "17.1" <mesa-stable at lists.freedesktop.org>
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c
index 763ce05..38925d9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1021,6 +1021,23 @@ intel_hiz_exec(struct brw_context *brw, struct intel_mipmap_tree *mt,
 {
    const char *opname = NULL;
 
+   /* From the Ivy Bridge PRM, Vol. 2, pt. 1, section 11.5.3.1 "Depth
+    * Buffer Clear":
+    *
+    *    "If other rendering operations have preceded this clear, a
+    *    PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled
+    *    must be issued before the rectangle primitive used for the depth
+    *    buffer clear operation."
+    *
+    * In the Sky Lake and Broadwell docs, this text only appears in the
+    * section on legacy HiZ ops.  However, adding it seems to solve some hangs
+    * on Sky Lake so it appears it's needed regardless of which kind of HiZ
+    * operation is performed.
+    */
+   brw_emit_pipe_control_flush(brw,
+                               PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+                               PIPE_CONTROL_DEPTH_STALL);
+
    switch (op) {
    case BLORP_HIZ_OP_DEPTH_RESOLVE:
       opname = "depth resolve";
-- 
2.5.0.400.gff86faf