[Mesa-dev] gallium separate depth and stencil

Ilia Mirkin imirkin at alum.mit.edu
Wed Mar 18 10:31:14 PDT 2015

OK, makes sense. The other place where separate buffers could be
reasonable is, unrelatedly, ARB_texture_stencil8. My plan for that was
to just let it be though and just disallow any depth attachments next
to that s8 attachment. (The implementation got stymied when I realized
that nvidia hw doesn't actually support a S8 zsbuf type in the first
place, so it'll have to be a X24S8 situation. Ugh.)

On Wed, Mar 18, 2015 at 12:51 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list