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

[Marek Olšák]

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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181113/73a87990/attachment.html>