[Mesa-dev] gallium separate depth and stencil

[Roland Scheidegger]

To provide some background why separate attachments aren't supported in
gallium:
1) OpenGL always allowed this, however noone seriously expected this to
actually be supported. At least gaming hardware pretty much was limited
to d24s8.
2) D3D10 also only has one attachment point for both, so there might
still be restrictions what newer hardware can do (apparently radeons
have some even though they support separate attachments).

I don't know if there'd be much benefit for allowing separate
attachments. FWIW it is not exposable at all in GLES neither (the "whole
framebuffer completeness" section says this in an incomplete
framebuffer, not just implementation dependent as it is in GL). I guess
you could have some faster path somewhere when the (GL) app is
specifying separate s8 + d32f attachments, but I doubt there's really a
lot of apps out there which do that (not to mention having to actually
transfer depth or stencil data should be hopefully pretty rare).

Roland


Am 18.03.2015 um 17:51 schrieb Marek Olšák:
> Manual interleaving and deinterleaving in the driver seems to be the
> easiest solution. You just need 2 blits. You can reuse u_blitter for
> setting up stuff or you can create your own thing.
> 
> Adding separate Z+S to Gallium and st/mesa would be quite a lot work,
> and what you want to support is an interleaved format anyway. I
> suppose you wouldn't be exposing separate formats to applications, you
> just want a way to convert an interleaved ZS to separate buffers for
> your driver.
> 
> We don't plan to expose separate Z+S to applications due to tiling
> restrictions on Radeon.
> 
> Marek
> 
> 
> On Wed, Mar 18, 2015 at 4:52 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Hello,
>>
>> I've run into a situation where a3xx hardware does not natively
>> support Z32F_S8 (interleaved). However it will happily support Z32F
>> and S8 separately (and at the same time). Haven't looked at how a4xx
>> handles this, but wouldn't be surprised if it were the same.
>>
>> One way to do this is to expose the Z32F_X24S8 format in the driver,
>> but internally just store the two sets of data separately. Then add
>> hooks to the transfer logic to interleave/deinterleave the data on
>> transfer in/out. This seems hacky.
>>
>> Another approach is to teach gallium about split depth/stencil
>> buffers, i.e. adding a pipe_surface *sbuf next to the zsbuf. Then,
>> guarded by a PIPE_CAP, the st would be able to make use of it. Both
>> for binding separate depth/stencil textures (e.g. Z16 + S8), as well
>> as to create adapters for this situation. I guess it'd still be a bit
>> of a hack, but at least it would be reusable by other hw.
>>
>> Is there any other hw out there that would need this? Any preferences
>> on how I should approach it?
>>
>> FTR, Z32F_X24S8 is needed for both GL3 (ARB_depth_buffer_float) and GLES3.
>>
>> Cheers,
>>
>>   -ilia
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=d4_9DUsUo6ay357-gBSSVT0WimyK680Y4WYaBBUGRB4&s=tPeOYQp70nxiWtHEf6fjisUqi7YjDogh0TzsgJ-GCb0&e= 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=d4_9DUsUo6ay357-gBSSVT0WimyK680Y4WYaBBUGRB4&s=tPeOYQp70nxiWtHEf6fjisUqi7YjDogh0TzsgJ-GCb0&e= 
>