[Mesa-dev] [PATCH] mesa: Loosen glBlitFramebuffer restrictions on depthstencil buffers (v2)

Brian Paul brianp at vmware.com
Fri Jan 20 06:54:14 PST 2012


On 01/20/2012 05:12 AM, Christoph Bumiller wrote:
> On 20.01.2012 12:45, Henri Verbeet wrote:
>> On 20 January 2012 03:24, Eric Anholt<eric at anholt.net>  wrote:
>>>> So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
>>>> to blit from RGBA8 to BGRA8 then, please ?
>>> That's already allowed.
>>>
>> Yeah, but not for multisampled framebuffers, unless RGBA8 and BGRA8
>> are considered identical (ARB_fbo):
>>
>>      If SAMPLE_BUFFERS for either the read framebuffer or
>>      draw framebuffer is greater than zero, no copy is performed and an
>>      INVALID_OPERATION error is generated if the dimensions of the source
>>      and destination rectangles provided to BlitFramebuffer are not
>>      identical, or if the formats of the read and draw framebuffers are
>>      not identical.
> Yes, sorry, I didn't realize this only applied to multisample buffers.
>
> I just tested again and the blob conveniently ignores the matching
> formats condition altogether.
>
> The point is that I'd really like to support GL_RGBA8 as red-first,
> regardless of the window format.
> There might even be window systems that force either the one or the
> other, and then we could never be compatible with both and support the
> established behaviour of NOT doing 2 blits (first to temporary
> framebuffer where we can be sure the format matches and then to the
> window) when resolving.

I'm OK with removing the exact color format test if that's what other 
drivers are doing.

-Brian


More information about the mesa-dev mailing list