[Mesa-dev] [RFC 2/3] mesa: hook up DiscardTexture for InvalidateFramebuffer and friends

Eric Anholt eric at anholt.net
Mon Aug 17 16:45:43 PDT 2015


Rob Clark <robdclark at gmail.com> writes:

> On Mon, Aug 17, 2015 at 3:38 PM, Eric Anholt <eric at anholt.net> wrote:
>> Rob Clark <robdclark at gmail.com> writes:
>>
>>> From: Rob Clark <robclark at freedesktop.org>
>>>
>>> We can use same Driver hook for these, in addition to
>>> DiscardFramebufferEXT()
>>>
>>> Signed-off-by: Rob Clark <robclark at freedesktop.org>
>>> ---
>>>  src/mesa/main/fbobject.c | 25 ++++++++++++++++++++++---
>>>  1 file changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>>> index 42eec89..bac10e6 100644
>>> --- a/src/mesa/main/fbobject.c
>>> +++ b/src/mesa/main/fbobject.c
>>> @@ -4003,9 +4003,28 @@ invalidate_framebuffer_storage(struct gl_context *ctx,
>>>        }
>>>     }
>>>
>>> -   /* We don't actually do anything for this yet.  Just return after
>>> -    * validating the parameters and generating the required errors.
>>> -    */
>>> +   if ((x != 0) || (y != 0))
>>> +      return;
>>> +
>>> +   if ((width != fb->Width) || (height != fb->Height))
>>> +      return;
>>
>> I think you want "(width < fb->Width) || (height < fb->Height)" since
>> _mesa_InvalidateFramebuffer passes MAX_VIEWPORT_WIDTH/HEIGHT.
>
> oh, heh, yeah..
>
>> The loop also looks a lot like the loop in the previous patch.  I think
>> you could just reuse invalidate_framebuffer_storage from
>> DiscardFramebufferEXT -- DFEXT doesn't explicitly specify the
>> INVALID_OPERATION for > MaxColorAttachments, but it seems reasonable and
>> then the new loop only appears once.
>
> DFEXT did check for color != attach0 (although I'm not sure if that
> restriction *should* be dropped if MRT extension supported?)
>
> maybe it is safer just to split out a common helper?

From one of EXT_discard_framebuffer's issues:

        RESOLVED: We'll use a sized list of framebuffer attachments.  This
        will give us some future-proofing for when MRTs and multisampled
        FBOs are supported.

This seems to think that the later extensions to support MRTs should
have updated this spec to allow bigger numbers, but didn't.  But I'd
also be OK with just a helper function for the loop.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150817/a619923e/attachment-0001.sig>


More information about the mesa-dev mailing list