On Thursday 03 March 2005 10:42, Brian Paul wrote:
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.
Would one side effect of this be that the driver could implement (say) accum buffers entirely in swrast but still have hardware acceleration for the normal set of buffers?
Yes. It'll also allow hardware accumulation buffers in a straight-forward manner.
The Mesa fall-back routines for rasterization, accumulation, etc will do all their pixel-oriented work through the gl_renderbuffer's methods so it won't matter which buffers are hardware or software based.
Currently, the software fallbacks, in some places, are more intimately tied to the memory allocation than needed.
In the new scheme, all the code for allocating software buffers will be pulled out of the swrast routine and put into a utility routine, probably in drivers/common/.
This might be an interim solution for pbuffers until the DRI drivers get decent memory management.
Well, GL_EXT_framebuffer_object should be able to replace pbuffers, but it'll still require a DRI mechanism for dynamically allocating rendering buffers (if you want hardware rendering).
-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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
