This extension can't be easily/cleanly added to Mesa without rewriting and changing some existing code. But ultimately, the changes will be for the better, much in the way that GL_NV/ARB_vertex_program improved the TNL code.
I'll assume people are familiar with GL_EXT_framebuffer_object. If not, read the spec.
The new code will be "C object-oriented" so I'll use OOP terms here.
The basic idea is to merge the GLframebuffer class (in mtypes.h) with the new gl_framebuffer class (in fbobject.h).
The stencil, depth, accum, aux, etc. buffer pointers in GLframebuffer will go away, replaced by gl_renderbuffer_attachment members.
Each of the logical buffers (such as color, depth, stencil, etc) which form the overall framebuffer will be represented by a gl_renderbuffer object (see fbojbect.h). These renderbuffers can either be allocated/managed by the device driver, or by core Mesa as a software fallback.
Device drivers will have the opportunity to derive device-specific classes from the gl_renderbuffer and gl_framebuffer classes. They're allocated with the ctx->Driver.NewRenderbuffer() and ctx->Driver.NewFramebuffer() functions. Each of these classes have their own Delete member functions.
The gl_framebuffer class will be used both for user-allocated framebuffers (made via glBindFramebufferEXT) and for the window-system framebuffers that correspond to GLX windows.
gl_renderbuffer objects have an AllocateStorage() method that's used for allocating storage for the buffer's depth/color/stencil/etc. In the case of DRI drivers, this would be a no-op for the statically allocated window buffers, but would allocate VRAM for user-allocated renderbuffers. There's also a Delete() method.
The gl_renderbuffer's GetPointer(), GetRow(), GetValues(), PutRow(), and PutValues() methods will used by the software fallback routines to access the pixels in a buffer. This will replace the current swrast span read/write routines. Note that there's no distinction between color, depth or stencil in these routines. The gl_renderbuffer's BaseFormat and DataType will implicitly specify which kind of pixel data is being accessed.
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.
All this means that core Mesa can treat windows, off-screen "pbuffers" and texture images in a unified manner.
I'll continue to plug away on this stuff in my spare time.
-Brian
------------------------------------------------------- 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
