Brian Paul wrote:
I'll assume people are familiar with GL_EXT_framebuffer_object. If not, read the spec.
If you still have questions after reading the spec, you can ask me on #dri-devel on freenode. I try to be on there as often as I can.
The gl_renderbuffer's BaseFormat and DataType will implicitly specify which kind of pixel data is being accessed.
I assume gl_renderbuffer will also have a method like ChooseTextureFormat that the driver can over-ride? It seems like there might be enough commonality that gl_renderbuffer and gl_texture should both derrive from a common, virtual base class.
Also, a gl_renderbuffer object can be used as a wrapper for texture images. This will allow render-to-texture functionality. A yet-to-be-written routine will be called to set up the wrapper when the user wants render-to-texture. If the device supports rendering into texture memory, the wrapper will describe how to do that. Otherwise, a software-fallback wrapper would be used.
Do you have any ideas about how this would work? One thing that I'm curious about, and has come up numerous times in the working-group discussions, is supporting render-to-texture when a blit is required. For example, on a architecture with separate texture and framebuffer memory, the driver would have to render to framebuffer memory, then copy that to the texture when the mipmap level was configured to be used as a texture source. Certain restrictions in the spec were crafted specifically to handle this case. It sounds like the wrapper idea should cover this, but I just want to be sure. :)
Anyway, it sounds like you've really thought this through. I'm glad you have at least some time to work on it. :)
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
