From: Jason Ekstrand <jason.ekstrand@intel.com>
Date: Thu, 12 May 2016 22:03:46 +0000 (-0700)
Subject: i965: Move brw_is_color_fast_clear_compatible to brw_meta_util
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=21034f1b08a871b5968aa1293bb64e35556d8b86;p=mesa.git

i965: Move brw_is_color_fast_clear_compatible to brw_meta_util

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
---

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 933eb870b0e..217097e8f56 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -359,65 +359,6 @@ brw_meta_get_buffer_rect(const struct gl_framebuffer *fb,
    }
 }
 
-/**
- * Determine if fast color clear supports the given clear color.
- *
- * Fast color clear can only clear to color values of 1.0 or 0.0.  At the
- * moment we only support floating point, unorm, and snorm buffers.
- */
-bool
-brw_is_color_fast_clear_compatible(struct brw_context *brw,
-                                   const struct intel_mipmap_tree *mt,
-                                   const union gl_color_union *color)
-{
-   const struct gl_context *ctx = &brw->ctx;
-
-   /* If we're mapping the render format to a different format than the
-    * format we use for texturing then it is a bit questionable whether it
-    * should be possible to use a fast clear. Although we only actually
-    * render using a renderable format, without the override workaround it
-    * wouldn't be possible to have a non-renderable surface in a fast clear
-    * state so the hardware probably legitimately doesn't need to support
-    * this case. At least on Gen9 this really does seem to cause problems.
-    */
-   if (brw->gen >= 9 &&
-       brw_format_for_mesa_format(mt->format) !=
-       brw->render_target_format[mt->format])
-      return false;
-
-   /* Gen9 doesn't support fast clear on single-sampled SRGB buffers. When
-    * GL_FRAMEBUFFER_SRGB is enabled any color renderbuffers will be
-    * resolved in intel_update_state. In that case it's pointless to do a
-    * fast clear because it's very likely to be immediately resolved.
-    */
-   if (brw->gen >= 9 &&
-       mt->num_samples <= 1 &&
-       ctx->Color.sRGBEnabled &&
-       _mesa_get_srgb_format_linear(mt->format) != mt->format)
-      return false;
-
-   const mesa_format format = _mesa_get_render_format(ctx, mt->format);
-   if (_mesa_is_format_integer_color(format)) {
-      if (brw->gen >= 8) {
-         perf_debug("Integer fast clear not enabled for (%s)",
-                    _mesa_get_format_name(format));
-      }
-      return false;
-   }
-
-   for (int i = 0; i < 4; i++) {
-      if (!_mesa_format_has_color_component(format, i)) {
-         continue;
-      }
-
-      if (brw->gen < 9 &&
-          color->f[i] != 0.0f && color->f[i] != 1.0f) {
-         return false;
-      }
-   }
-   return true;
-}
-
 /**
  * Convert the given color to a bitfield suitable for ORing into DWORD 7 of
  * SURFACE_STATE (DWORD 12-15 on SKL+).
diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c b/src/mesa/drivers/dri/i965/brw_meta_util.c
index ac4f6154dc7..432321dbbb5 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -24,6 +24,8 @@
 #include "brw_context.h"
 #include "intel_fbo.h"
 #include "brw_meta_util.h"
+#include "brw_state.h"
+#include "main/blend.h"
 #include "main/fbobject.h"
 
 /**
@@ -305,3 +307,62 @@ brw_get_rb_for_slice(struct brw_context *brw,
 
    return rb;
 }
+
+/**
+ * Determine if fast color clear supports the given clear color.
+ *
+ * Fast color clear can only clear to color values of 1.0 or 0.0.  At the
+ * moment we only support floating point, unorm, and snorm buffers.
+ */
+bool
+brw_is_color_fast_clear_compatible(struct brw_context *brw,
+                                   const struct intel_mipmap_tree *mt,
+                                   const union gl_color_union *color)
+{
+   const struct gl_context *ctx = &brw->ctx;
+
+   /* If we're mapping the render format to a different format than the
+    * format we use for texturing then it is a bit questionable whether it
+    * should be possible to use a fast clear. Although we only actually
+    * render using a renderable format, without the override workaround it
+    * wouldn't be possible to have a non-renderable surface in a fast clear
+    * state so the hardware probably legitimately doesn't need to support
+    * this case. At least on Gen9 this really does seem to cause problems.
+    */
+   if (brw->gen >= 9 &&
+       brw_format_for_mesa_format(mt->format) !=
+       brw->render_target_format[mt->format])
+      return false;
+
+   /* Gen9 doesn't support fast clear on single-sampled SRGB buffers. When
+    * GL_FRAMEBUFFER_SRGB is enabled any color renderbuffers will be
+    * resolved in intel_update_state. In that case it's pointless to do a
+    * fast clear because it's very likely to be immediately resolved.
+    */
+   if (brw->gen >= 9 &&
+       mt->num_samples <= 1 &&
+       ctx->Color.sRGBEnabled &&
+       _mesa_get_srgb_format_linear(mt->format) != mt->format)
+      return false;
+
+   const mesa_format format = _mesa_get_render_format(ctx, mt->format);
+   if (_mesa_is_format_integer_color(format)) {
+      if (brw->gen >= 8) {
+         perf_debug("Integer fast clear not enabled for (%s)",
+                    _mesa_get_format_name(format));
+      }
+      return false;
+   }
+
+   for (int i = 0; i < 4; i++) {
+      if (!_mesa_format_has_color_component(format, i)) {
+         continue;
+      }
+
+      if (brw->gen < 9 &&
+          color->f[i] != 0.0f && color->f[i] != 1.0f) {
+         return false;
+      }
+   }
+   return true;
+}