Rob Clark <robdcl...@gmail.com> writes: > 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 > 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()).
I was thinking you'd return the mask of what buffers you couldn't (fast) clear.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
