On Tue, 2018-11-13 at 21:53 -0500, Marek Olšák wrote: > > > On Tue, Nov 13, 2018, 6:00 PM Rob Clark <robdcl...@gmail.com wrote: > > On Tue, Nov 13, 2018 at 5:25 PM Eric Anholt <e...@anholt.net> > > wrote: > > > > > > Rob Clark <robdcl...@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 <e...@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@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
