[Mesa-dev] [PATCH 5/7] intel: Directly implement blit glBlitFramebuffer instead of awkward reuse.

[Kenneth Graunke]

On 06/07/2013 12:58 PM, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
>
>> On 06/05/2013 10:14 AM, Eric Anholt wrote:
>>> This gets us support for blitting to attachment types other than
>>> textures.
>>> +      /* Blit to all active draw buffers.  We don't do any pre-checking,
>>> +       * because we assume that copying to MRTs is rare, and failure midway
>>> +       * through copying is even more rare.  Given that feedback loops in
>>> +       * glFramebufferBlit() are undefined, we can safely fail out after
>>> +       * having partially completed our copies.
>>
>> The first part of this comment makes sense: yes, it's obviously rare.
>> The second part I feel could use a little more explanation:
>>
>> If we fail midway through a blit, we return without clearing
>> BUFFER_BITS_COLOR from the mask.  The caller will fall back to the next
>> method (i.e. meta_BlitFramebuffer) and use that to blit /all/ RTs - even
>> ones we already successfully blit.  Given that feedback loops in
>> glFramebufferBlit() are undefined, we can safely fail out after having
>> partially completed our copies.
>>
>> Unless there's some kind of blending, it doesn't even seem
>> undefined...meta should just overwrite the colors again, and everything
>> will work out.
>
> Better?
>
>        /* Blit to all active draw buffers.  We don't do any pre-checking,
>         * because we assume that copying to MRTs is rare, and failure midway
>         * through copying is even more rare.  Even if it was to occur, it's
>         * safe to let meta start the copy over from scratch, because
>         * glBlitFramebuffer completely overwrites the destination pixels, and
>         * results are undefined if any destination pixels have a dependency on
>         * source pixels.
>         */

Yes, I like this better.  I'm good with this series now.  Thanks!

--Ken