i965/miptree: Zero-initialize CCS_D buffers

Before this patch, the aux_state was actually AUX_INVALID because the BO
was never defined. This was fine on single slice miptrees because we
would fast-clear the resource right after creation. For multi-slice
miptrees on SKL+ however, this results in undefined behavior when
accessing a non-base slice. Here's a specific example:

1) Fast clear level 0
   * Undefined CCS_D buffer allocated in "PASS_THROUGH" state.
   * Level 0 transitions to the CLEAR state.
2) Render to level 1
   * Level 1 may have a 2-bit pattern of 2's.
   * Rendering with a 2 in the CCS is undefined.

Cc: <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>

1 files changed, 4 insertions, 6 deletions

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index dd851ff9b5c..c01a71d4453 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1801,13 +1801,11 @@ intel_miptree_alloc_ccs(struct brw_context *brw,
     * A CCS value of 0 indicates that the corresponding block is in the
     * pass-through state which is what we want.
     *
-    * For CCS_D, on the other hand, we don't care as we're about to perform a
-    * fast-clear operation.  In that case, being hot in caches more useful.
+    * For CCS_D, do the same thing. On gen9+, this avoids having any undefined
+    * bits in the aux buffer.
     */
-   const uint32_t alloc_flags = mt->aux_usage == ISL_AUX_USAGE_CCS_E ?
-                                BO_ALLOC_ZEROED : BO_ALLOC_BUSY;
-   mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
-                                        &temp_ccs_surf, alloc_flags, mt);
+   mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree", &temp_ccs_surf,
+                                        BO_ALLOC_ZEROED, mt);
    if (!mt->aux_buf) {
       free(aux_state);
       return false;