On Wed, Nov 23, 2016 at 1:16 AM, Topi Pohjolainen < topi.pohjolai...@gmail.com> wrote:
> 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 <topi.pohjolai...@intel.com> > CC: Ben Widawsky <benjamin.widaw...@intel.com> > CC: Kenneth Graunke <kenn...@whitecape.org> > CC: Harri Syrja <harri.sy...@intel.com> > Cc: Chad Versace <c...@kiwitree.net> > --- > 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. > 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? > */ > - 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 > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
