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

Eric Anholt eric at anholt.net
Tue Nov 13 23:19:50 UTC 2018


Rob Clark <robdclark at gmail.com> writes:

> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181113/358a5b07/attachment.sig>


More information about the mesa-dev mailing list