[Mesa-dev] [PATCH] mesa/st: swap order of clear() and clear_with_quad()

[Erik Faye-Lund]

On Tue, 2018-11-13 at 21:53 -0500, Marek Olšák wrote:
> 
> 
> On Tue, Nov 13, 2018, 6:00 PM Rob Clark <robdclark at gmail.com wrote:
> > On Tue, Nov 13, 2018 at 5:25 PM Eric Anholt <eric at anholt.net>
> > wrote:
> > >
> > > Rob Clark <robdclark at gmail.com> writes:
> > >
> > > > If we can't clear all the buffers with pctx->clear() (say, for
> > example,
> > > > because of ColorMask), push the buffers we *can* clear with
> > pctx->clear()
> > > > first.  Tilers want to see clears coming before draws to enable
> > fast-
> > > > paths, and clearing one of the attachments with a quad-draw
> > first
> > > > confuses that logic.
> > >
> > > Oh, nice!
> > >
> > > Reviewed-by: Eric Anholt <eric at anholt.net>
> > >
> > > Though it feels pretty silly that the ->clear() caller needs a
> > > clear_with_quad implementation when the ->clear() implementation
> > in the
> > > driver also needs a clear_with_quad implementation for non-fast-
> > cleared
> > > buffers.  :/
> > 
> > hmm, so perhaps one easy option is to change pctx->clear() to
> > return a
> > boolean, so driver can return false to ask the state tracker to do
> > a
> 
> Ideally all pipe context functions should always return void to allow
> gallium multithreading.
> 
> A pipe cap for colormasked and scissored clears would be better.
> 

I have an ancient patch for the latter lying around:

https://github.com/kusma/mesa/commit/d6be35297ffaa5eeb912e849e55a22ff4ea03868

> > clear_with_quad()..  maybe that would be a first step towards
> > allowing
> > driver to handle clears w/ colormask and possibly scissor (although
> > for the later, plus
> > glInvalidateFramebuffer()/glInvalidateSubFramebuffer(), I was
> > thinking
> > of pctx->invalidate_surface()/pctx->invalidate_sub_surface())
> 
> Pipe context already contains an invalidate function.
> 
> Marek
> 
> > But either way, I guess this patch is a simple stop-gap solution.
> > 
> > BR,
> > -R
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev