On 10/12/2011 10:20 AM, Eric Anholt wrote:
On Mon, 10 Oct 2011 21:05:33 -0600, Brian Paul<brian.e.p...@gmail.com> wrote:
From: Brian Paul<bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
