Mesa (master): iris: Support clears in more GPU-based copies

[GitLab Mirror]

Module: Mesa
Branch: master
Commit: 38529675ef50e6cdcfe7d481872996053c409b10
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=38529675ef50e6cdcfe7d481872996053c409b10

Author: Nanley Chery <nanley.g.chery at intel.com>
Date:   Mon Dec 28 09:31:33 2020 -0800

iris: Support clears in more GPU-based copies

Commit 7779b1d71bf053f0c73a1b717e6d2ed91f948378, disabled clear support
when copying to/from color buffers. According to the performance CI, it
falls within a range of commits that introduced a performance regression
on Bioshock Infinite with Tigerlake. Icelake isn't noticeably affected.

By analyzing a trace of the game, I found a couple cases where that
commit added new partial resolves. Update get_copy_region_aux_settings
to avoid them:

- The trace uploads to R8_UNORM textures. On TGL, these enter the
  COMPRESSED_CLEAR state on the upload and are partially resolved before
  every subsequent upload. Thankfully, they keep their initial clear
  color of all zeroes. Since zeros can survive format reinterpretation,
  allow clear support for it.

- The trace copies between RGBA16_FLOAT textures. The ones with zero
  clear color are helped by the optimization above. The ones with
  non-zero clear color are used as source textures. Thankfully on ICL+,
  the clear color used for sampling is in pixel form and can thus be
  sampled from with format reinterpretation. Allow clear support for
  this case.

I haven't tested the actual performance impact of this change, but it
should be beneficial regardless.

Reported-by: Clayton Craft <clayton.a.craft at intel.com>
Reported-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8262>

---

 src/gallium/drivers/iris/iris_blit.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/iris/iris_blit.c b/src/gallium/drivers/iris/iris_blit.c
index 0d6a35827ca..a527d2d5820 100644
--- a/src/gallium/drivers/iris/iris_blit.c
+++ b/src/gallium/drivers/iris/iris_blit.c
@@ -599,6 +599,9 @@ get_copy_region_aux_settings(struct iris_context *ice,
                              bool *out_clear_supported,
                              bool is_render_target)
 {
+   struct iris_screen *screen = (void *) ice->ctx.screen;
+   struct gen_device_info *devinfo = &screen->devinfo;
+
    switch (res->aux.usage) {
    case ISL_AUX_USAGE_HIZ:
    case ISL_AUX_USAGE_HIZ_CCS:
@@ -617,7 +620,27 @@ get_copy_region_aux_settings(struct iris_context *ice,
    case ISL_AUX_USAGE_CCS_E:
    case ISL_AUX_USAGE_GEN12_CCS_E:
       *out_aux_usage = res->aux.usage;
-      *out_clear_supported = false;
+
+      /* blorp_copy may reinterpret the surface format and has limited support
+       * for adjusting the clear color, so clear support may only be enabled
+       * in some cases:
+       *
+       * - On gen11+, the clear color is indirect and comes in two forms: a
+       *   32bpc representation used for rendering and a pixel representation
+       *   used for sampling. blorp_copy doesn't change indirect clear colors,
+       *   so clears are only supported in the sampling case.
+       *
+       * - A clear color of zeroes holds the same meaning regardless of the
+       *   format. Although it could avoid more resolves, we don't use
+       *   isl_color_value_is_zero because the surface format used by
+       *   blorp_copy isn't guaranteed to access the same components as the
+       *   original format (e.g. A8_UNORM/R8_UINT).
+       */
+      *out_clear_supported = (devinfo->gen >= 11 && !is_render_target) ||
+                             (res->aux.clear_color.u32[0] == 0 &&
+                              res->aux.clear_color.u32[1] == 0 &&
+                              res->aux.clear_color.u32[2] == 0 &&
+                              res->aux.clear_color.u32[3] == 0);
       break;
    default:
       *out_aux_usage = ISL_AUX_USAGE_NONE;