iris: Don't skip fast depth clears if the color changed
authorJason Ekstrand <jason@jlekstrand.net>
Thu, 5 Mar 2020 23:17:40 +0000 (17:17 -0600)
committerMarge Bot <eric+marge@anholt.net>
Fri, 6 Mar 2020 01:40:02 +0000 (01:40 +0000)
We depend on BLORP to convert the clear color and write it into the
clear color buffer for us.  However, we weren't bothering to call blorp
in the case where the state is ISL_AUX_STATE_CLEAR.  This leads to the
clear color not getting properly updated if we have back-to-back clears
with different clear colors.  Technically, we could go out of our way to
set the clear color directly from iris in this case but this is a case
we're unlikely to see in the wild so let's not bother.  This matches
what we already do for color surfaces.

Cc: mesa-stable@lists.freedesktop.org
Reported-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4073>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4073>

src/gallium/drivers/iris/iris_clear.c

index 5f7914a5ba0bd3a976cc7afc2a7a3bc645d83c0b..087b32f7180ea00fdbaae9608fdd3c87d26ac105 100644 (file)
@@ -521,7 +521,11 @@ fast_clear_depth(struct iris_context *ice,
    for (unsigned l = 0; l < box->depth; l++) {
       enum isl_aux_state aux_state =
          iris_resource_get_aux_state(res, level, box->z + l);
-      if (aux_state != ISL_AUX_STATE_CLEAR) {
+      if (update_clear_depth || aux_state != ISL_AUX_STATE_CLEAR) {
+         if (aux_state == ISL_AUX_STATE_CLEAR) {
+            perf_debug(&ice->dbg, "Performing HiZ clear just to update the "
+                                  "depth clear value\n");
+         }
          iris_hiz_exec(ice, batch, res, level,
                        box->z + l, 1, ISL_AUX_OP_FAST_CLEAR,
                        update_clear_depth);