mesa/st: better colormask check for clear fallback
authorRob Clark <robdclark@gmail.com>
Tue, 13 Nov 2018 19:19:38 +0000 (14:19 -0500)
committerRob Clark <robdclark@gmail.com>
Tue, 27 Nov 2018 20:44:02 +0000 (15:44 -0500)
For RGB surfaces (for example) we don't really care that the colormask
is 0x7 instead of 0xf.  This should not trigger clear_with_quad()
slowpath.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
src/mesa/state_tracker/st_cb_clear.c

index 3b51bd2c8a7217a131f6487c4410ed95376637ac..88fc12789e386d011f3b5708486bdd9f8dac7b2f 100644 (file)
@@ -392,12 +392,18 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
             if (!strb || !strb->surface)
                continue;
 
-            if (!GET_COLORMASK(ctx->Color.ColorMask, colormask_index))
+            unsigned colormask =
+               GET_COLORMASK(ctx->Color.ColorMask, colormask_index);
+
+            if (!colormask)
                continue;
 
+            unsigned surf_colormask =
+               util_format_colormask(util_format_description(strb->surface->format));
+
             if (is_scissor_enabled(ctx, rb) ||
                 is_window_rectangle_enabled(ctx) ||
-                GET_COLORMASK(ctx->Color.ColorMask, colormask_index) != 0xf)
+                ((colormask & surf_colormask) != surf_colormask))
                quad_buffers |= PIPE_CLEAR_COLOR0 << i;
             else
                clear_buffers |= PIPE_CLEAR_COLOR0 << i;