Leif Delgass wrote:
> On Tue, 9 Apr 2002, Keith Whitwell wrote:
> > Probably just the way it was done. It would be fairly easy to allow an
> > XF86Config option for zbuffer depth, but quite a bit more work to support 16
> > and 32 bpp side-by-side.
>
> We talked about this a bit at yesterday's IRC. The mach64 can only use a
> 16-bit depth buffer, even with a 32bpp framebuffer, so I'm also interested
> in this. I couldn't see a way to request a smaller buffer from the XFree
> framebuffer manager (currently we allocate a 32-bit depth buffer, but are
> only using 16-bit z-buffer depth). It looks like the utah-glx driver was
> able to accomplish this since it's managing it's own buffers. Most of the
> drivers seem to have a comment in the ScreenInit of the DDX driver about,
> "When we move to dynamic allocation of back and depth buffers...". Could
> anyone explain what the plan was regarding this?
The basic idea of static vs. dynamic buffer allocation is this:
Static - we allocate a single screen-sized Z buffer, stencil
buffer, back color buffer, etc which is shared by all windows.
In regions where windows overlap, the ancilliary buffer data is
only valid for the top-most window.
Pros: simple, bounded memory usage
Cons: may waste video memory that could otherwise be used for textures
Dynamic - for each window we allocate a private (Width * Height) Z,
stencil, back buffer etc. Obscured window regions effectively
have backing store for the ancilliary data. The buffers are
reallocated when the window size changes, deallocated when the
window is ummapped, etc.
Pros: only use as much video memory as needed, might be easily
extended to support P-buffers.
Cons: more complicated, have to deal with fragmentation, running
out of memory, etc.
All the DRI drivers use static allocation at this time.
-Brian
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
