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 <robdcl...@gmail.com>
---
This avoids some mem->gmem for webgl and probably other things using
a RGB surface. This should be ok for 24b packed RGB, but not sure
about 32b RGBx. In my case, I have a WRITEMASK for the thing I use
for clears, which I think should make this work properly for RGBx
as well. (And, well, I probably don't even need the whole
clear_with_quad() path for colormask in the first place.)
src/mesa/state_tracker/st_cb_clear.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 3b51bd2c8a7..88fc12789e3 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -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;
--
2.19.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
