[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