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 <mar...@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 <imir...@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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
