[Mesa-dev] [PATCH 3/6] mesa: check attachment Type field in renderbuffer_exists()

[Brian Paul]

On 10/12/2011 10:20 AM, Eric Anholt wrote:
> On Mon, 10 Oct 2011 21:05:33 -0600, Brian Paul<brian.e.paul at gmail.com>  wrote:
>> From: Brian Paul<brianp at vmware.com>
>>
>> Instead of the renderbuffer pointer.  In the future, attaching a texture
>> may not mean the renderbuffer pointer gets set too.
>> Plus, remove some commented-out assertions.
>
> I'm curious where you're going with not having a Renderbuffer for
> textures.

At this point, it's more of a change just to reflect the GL spec.  The 
GL spec certainly doesn't say anything about a "fake" renderbuffer 
being created when there's a texture attachment.  So I was changing 
the checks there to reflect that.


> I've wished that Mesa core handled making a Renderbuffer for
> textures, since there was this ugly driver code for cooking up a
> Renderbuffer even though everyone's should be basically the same.

At some point we might have a third type of object which is some kind 
of union of gl_texture_image and gl_renderbuffer (like gallium's 
pipe_resource).  Or maybe we should just create texture images all the 
time instead of renderbuffers.  But I really haven't begun to consider 
this in any depth yet.

But if you think automatically creating renderbuffer wrappers for 
textures would be helpful, we could explore that.  So far, that's only 
been an artifact of the way swrast did things.  And I'd like to get 
all that baggage out of core Mesa.


> Maybe having the Renderbuffer go away will help, I'm not sure.  In the
> rbmapping in swrast, I'm constantly wanting to know the format of
> fb->Attachments[WHATEVER] and get a mapping of it.  I think that's the
> most important to have easy access to, whether it's from the
> Renderbuffer or helper functions on the attachment point (but it's sure
> easier to be able to pass a gl_renderbuffer around than fb+attachment).

Understood.

-Brian