[Mesa-dev] [PATCH 10/14] i965/brw_clear: Don't resolve to change the depth clear value

[Nanley Chery]

Choose to compress the new depth value, instead of doing both a resolve
and fast-clear. This should reduce bandwidth consumption.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c b/src/mesa/drivers/dri/i965/brw_clear.c
index 3b5f6122439..fedd31a4317 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -172,8 +172,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
 
    const uint32_t num_layers = depth_att->Layered ? depth_irb->layer_count : 1;
 
-   /* If we're clearing to a new clear value, then we need to resolve any clear
-    * flags out of the HiZ buffer into the real depth buffer.
+   /* If we're clearing to a new clear value, then we need to ensure that the
+    * old clear blocks will be overwritten.
     */
    if (mt->fast_clear_color.f32[0] != clear_value) {
       for (uint32_t level = mt->first_level; level <= mt->last_level; level++) {
@@ -186,7 +186,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
             if (level == depth_irb->mt_level &&
                 layer >= depth_irb->mt_layer &&
                 layer < depth_irb->mt_layer + num_layers) {
-               /* We're going to clear this layer anyway.  Leave it alone. */
+               /* We're going to clear this layer anyway. */
                continue;
             }
 
@@ -199,16 +199,14 @@ brw_fast_clear_depth(struct gl_context *ctx)
                continue;
             }
 
-            /* If we got here, then the level may have fast-clear bits that
-             * use the old clear value.  We need to do a depth resolve to get
-             * rid of their use of the clear value before we can change it.
-             * Fortunately, few applications ever change their depth clear
-             * value so this shouldn't happen often.
+            /* If we got here, then the level may have fast-clear bits that use
+             * the old clear value. Since a slow cleared block is the same size
+             * a fast-cleared block, the bandwidth savings likely aren't enough
+             * to justify a full resolve. Fall back to slow clear. Fortunately,
+             * few applications ever change their depth clear value so this
+             * shouldn't happen often.
              */
-            intel_hiz_exec(brw, mt, level, layer, 1,
-                           ISL_AUX_OP_FULL_RESOLVE);
-            intel_miptree_set_aux_state(brw, mt, level, layer, 1,
-                                        ISL_AUX_STATE_RESOLVED);
+            return false;
          }
       }
 
-- 
2.16.2