[Mesa-dev] [PATCH 3/3] swrast: map/unmap attachments, not renderbuffers in glReadPixels

[Brian Paul]

On 11/06/2011 05:20 PM, Eric Anholt wrote:
> On Sat,  5 Nov 2011 13:15:41 -0600, Brian Paul<brianp at vmware.com>  wrote:
>> Most drivers have been creating fake/wrapper renderbuffers when a
>> texture image is attached to an FBO.  But that's not a requirement
>> of core Mesa.
>>
>> So an FBO attachment that points into a texture may not have a
>> (fake) renderbuffer.  This caused the new glReadPixels code to fail
>> when reading from a buffer that's actually a texture.
>>
>> Now, we check the attachment point to see if it's a real renderbuffer
>> or a texture image and call the corresponding MapRenderbuffer() or
>> MapTextureImage() function.
>>
>> This fixes a bunch of piglit fbo failures when using the non-DRI
>> swrast driver.
>
> I'm not excited about needing getters for the attachment's format -- I
> wish we just had one structure with the Format in it we could reference
> when talking about an attachment, since we need that field so often.
>
> On the other hand, I like the idea of forcing using a helper function
> for doing the mappings, instead of going straight to ctx->Driver.  With
> all the hardware drivers needing to privately store x/y/w/h/mode/some
> other pointer, it means that we can't recursively map a buffer (which
> would be easy to accidentally do when doing packed depth/stencil or
> CopyPixels).  I've been thinking it would be nice to make MTI/MRB
> helpers that stored those right in the GL struct, and used those fields
> to assert that someone testing on a software driver doesn't produce
> recursive mappings.


I was thinking about this stuff more over the weekend and I'm going to 
hold off on this patch until I can spend more time on the problem.

I think that there should be renderbuffers for texture attachments to 
make surface access uniform regardless of the underlying object type.

-Brian