On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell <keith.whitw...@gmail.com> wrote: > On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie <airl...@gmail.com> wrote: >> So Evergreen hardware appears to have only completely separate depth >> and stencil buffers and doesn't natively support a combnined DS buffer >> from what I can see. I'm awaiting clarification from AMD. >> >> Now gallium and st/mesa seem to be quite dedicated to the whole >> combined DS cause. > > What formats exactly does it support?
It looks like Z16,24 and a 32-float, along with I think an S8 stencil (its a one bit format). I'm not sure if the Z24 is packed or its actually X8Z24, this only matters when I need to know what size buffers to allocate in the DDX for passing over DRI2. > > It's interesting because DX10 (and presumably 11) always talk about > combined buffers - but the abstraction is such (with staging > resources, no direct mapping of the buffers, etc) that there's nothing > which constrains the layout to be an interleaved depth+stencil. IE. > you could quite happily allocate the combined depth/stencil as a > planar depth buffer and a separate planar stencil buffer - both hidden > behind the same resource handle. Yeah thats what I'm wondering if I should just hide this all in the driver resource handling. The hw is a bit messy anyways, we can't attach DB direct to texture, we have to flush it out via a DB->CB rendering pass, so I think its probably possible with sufficent shader to make it produce a combined ZS from the separated buffers. I' > I would have hoped we'd have the same flexibility in gallium - > basically that nobody should be able to tell whether depth & stencil > are swizzled together or separate. > > The obvious case where the app & state tracker might be alerted to > your unusual layout is in transfers. An interim solution would be to > swizzle/unswizzle depth buffer transfer data (or organize for the card > to do so for you). > > >> I'm mainly posting just wondering if anyone else has considered this >> or any other hardware this might be useful for exists, or if anyone >> can speak to the pitfalls I'll face. >> >> I've got some initial done in 30 mins hacks >> http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs So I'm guessing I've taken the wrong approach here from reading this, I should probably not expose this to gallium, and just make sure the DDX allocates a large enough buffer for two planes. Hopefully Alex can dig out some more info. Thanks, Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
