[Mesa-dev] [PATCH 1/7] i965: Flush around state base address

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_misc_state.c  | 32 +++++++++++++++++++++++++++++
 src/mesa/drivers/dri/i965/genX_blorp_exec.c |  2 +-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 79bdda9..97b6bbf 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -867,6 +867,31 @@ brw_upload_state_base_address(struct brw_context *brw)
     * maybe this isn't required for us in particular.
     */
 
+   if (brw->gen >= 6) {
+      const unsigned dc_flush =
+         brw->gen >= 7 ? PIPE_CONTROL_DATA_CACHE_FLUSH : 0;
+
+      /* Emit a render target cache flush.
+       *
+       * This isn't documented anywhere in the PRM.  However, it seems to be
+       * necessary prior to changing the surface state base adress.  We've
+       * seen issues in Vulkan where we get GPU hangs when using multi-level
+       * command buffers which clear depth, reset state base address, and then
+       * go render stuff.
+       *
+       * Normally, in GL, we would trust the kernel to do sufficient stalls
+       * and flushes prior to executing our batch.  However, it doesn't seem
+       * as if the kernel's flushing is always sufficient and we don't want to
+       * rely on it.
+       */
+      brw_emit_pipe_control_flush(brw,
+                                  PIPE_CONTROL_RENDER_TARGET_FLUSH |
+                                  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+                                  dc_flush |
+                                  PIPE_CONTROL_NO_WRITE |
+                                  PIPE_CONTROL_CS_STALL);
+   }
+
    if (brw->gen >= 8) {
       uint32_t mocs_wb = brw->gen >= 9 ? SKL_MOCS_WB : BDW_MOCS_WB;
       int pkt_len = brw->gen >= 9 ? 19 : 16;
@@ -970,6 +995,13 @@ brw_upload_state_base_address(struct brw_context *brw)
        ADVANCE_BATCH();
    }
 
+   if (brw->gen >= 6) {
+      brw_emit_pipe_control_flush(brw,
+                                  PIPE_CONTROL_INSTRUCTION_INVALIDATE |
+                                  PIPE_CONTROL_STATE_CACHE_INVALIDATE |
+                                  PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
+   }
+
    /* According to section 3.6.1 of VOL1 of the 965 PRM,
     * STATE_BASE_ADDRESS updates require a reissue of:
     *
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index d92dd13..8fd17fb 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -201,7 +201,7 @@ genX(blorp_exec)(struct blorp_batch *batch,
    assert(batch->blorp->driver_ctx == batch->driver_batch);
    struct brw_context *brw = batch->driver_batch;
    struct gl_context *ctx = &brw->ctx;
-   const uint32_t estimated_max_batch_usage = GEN_GEN >= 8 ? 1920 : 1500;
+   const uint32_t estimated_max_batch_usage = GEN_GEN >= 8 ? 1920 : 1700;
    bool check_aperture_failed_once = false;
 
    /* Flush the sampler and render caches.  We definitely need to flush the
-- 
2.5.0.400.gff86faf