[Mesa-dev] separate depth and stencil buffers in gallium

[Dave Airlie]

On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell
<keith.whitwell at gmail.com> wrote:
> On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie <airlied at 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.