[Mesa-dev] [PATCH 5/7] intel: Directly implement blit glBlitFramebuffer instead of awkward reuse.
eric at anholt.net
Fri Jun 7 12:58:47 PDT 2013
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
>> + /* 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.
/* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the mesa-dev