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

Ian Romanick idr at freedesktop.org
Fri Jan 20 19:06:57 PST 2012


On 01/20/2012 04: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 discussed this with some people in Khronos, and I've been convinced 
that we're slightly misinterpreting the spec on this topic.  The 
behavior mentioned in the spec is concerned with the internalFormat (and 
the GL-selected internalFormat) supplied to glRenderbufferStorage and 
friends.  In this case, BGRA is *not* an internalFormat that an 
application can request.  A driver can choose to use that ordering, but 
it should be transparent to the application.

All of the possible formats are in table 3.16 and table 4.11 in the 
OpenGL 3.0 spec.

Based on that, I think we should treat all of the permutations of RGBAn 
as equivalent.  That is, MESA_FORMAT_ARGB8888 can blit to 
MESA_FORMAT_ARGB8888_REV can blit to
MESA_FORMAT_RGBA8888 because the all map to RGBA8 in table 3.16.  If we 
had a function that could map a MESA_FORMAT_ back to a GL 
internalFormat, we could just compare those.


More information about the mesa-dev mailing list