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

Reply via email to