<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 23, 2016 at 1:16 AM, Topi Pohjolainen <<a href="mailto:topi.pohjolainen@gmail.com" target="_blank">topi.pohjolainen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Originally re-clears where skipped but when lossless compression was introduced the re-clears where errorneously enabled also for non-compressed fast clears. Signed-off-by: Topi Pohjolainen <<a href="mailto:topi.pohjolainen@intel.com">topi.pohjolainen@intel.com</a>> CC: Ben Widawsky <<a href="mailto:benjamin.widawsky@intel.com">benjamin.widawsky@intel.com</a>> CC: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> CC: Harri Syrja <<a href="mailto:harri.syrja@intel.com">harri.syrja@intel.com</a>> Cc: Chad Versace <<a href="mailto:chad@kiwitree.net">chad@kiwitree.net</a>> --- src/mesa/drivers/dri/i965/brw_blorp.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c index 556f2c0..9a849f5 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp.c +++ b/src/mesa/drivers/dri/i965/brw_blorp.c @@ -825,10 +825,23 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb, brw, &irb->mt->gen9_fast_clear_color, &override_color); - /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear - * is redundant and can be skipped. + /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, and the + * buffer isn't compressed, the clear is redundant and can be skipped. + * + * Without compression fast clear only operates on the mcs buffer + * recording if color values are cleared. The hardware, however, + * doesn't write the actual color value into the mcs or color + * buffer. Only by the time of render (inclucing color resolve) does the + * hardware read the _current_ color value in the surface state and + * write the actual pixel values in the color buffer accordingly. + * + * This seems to be the reason why sampler engine cannot handle + * non-compressed fast clear - it doesn't know how to read the color + * value from the surface state. With compression the color value is + * recorded in the color buffer (only not for every pixel) and therefore + * it is available without consulting the surface state. </blockquote><div> </div><div>This doesn't jive with my understanding of fast clears on gen9. Everything I've seen so far indicates that the clear color in the surface state *does* matter. Otherwise, why would it be there? In particular, my understanding of the 2-bit CCS values is that 0 means resolved, 1 means compressed and 3 means clear where "clear" means "go look at the clear color". Have you done experiments that lead you to some other conclusion? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> */ - if (!color_updated && + if ((!color_updated || !is_lossless_compressed) && irb->mt->fast_clear_state == INTEL_FAST_CLEAR_STATE_CLEAR) return true; -- 2.5.5 _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div> </div></div>