anv: track if images can be fast clear with non-zero color

Because clear colors are stored as 4 32bit component values, there is
an issue if you try to format instance :

   - clearing in R16G16_UNORM
   - draw in R32_UINT

Clear will use 2 components of the clear color in dword0 & dword1.

While draw will use only one component of dword0.

This change uses the mutable format information to track whether clear
colors can be non-zero for fast clears.

With :

   - non mutable formats, we can fast clear with any color on Gfx > 8
   - mutable formats with incompatible component sizes, we can only
     fast clear with 0 color

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5930
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17329>

src/intel/vulkan/anv_private.h

@@ -3820,6 +3820,22 @@ struct anv_image {
 
       /** Location of the fast clear state.  */
       struct anv_image_memory_range fast_clear_memory_range;
+
+      /**
+       * Whether this image can be fast cleared with non-zero clear colors.
+       * This can happen with mutable images when formats of different bit
+       * sizes per components are used.
+       *
+       * On Gfx9+, because the clear colors are stored as a 4 components 32bit
+       * values, we can clear in R16G16_UNORM (store 2 16bit values in the
+       * components 0 & 1 of the clear color) and then draw in R32_UINT which
+       * would interpret the clear color as a single component value, using
+       * only the first 16bit component of the previous written clear color.
+       *
+       * On Gfx7/7.5/8, only CC_ZERO/CC_ONE clear colors are supported, this
+       * boolean will prevent the usage of CC_ONE.
+       */
+      bool can_non_zero_fast_clear;
    } planes[3];
 };