On Dec 21, 2015 6:10 PM, "Roland Scheidegger" <srol...@vmware.com> wrote: > > Am 21.12.2015 um 20:59 schrieb Jose Fonseca: > > On 16/12/15 16:18, Roland Scheidegger wrote: > >> Am 16.12.2015 um 12:52 schrieb Marek Olšák: > >>> This is not well defined in gallium, but r600g and radeonsi use these > >>> default swizzles for depth and stencil surfaces and it's probably the > >>> only reasonable thing to do: > >>> > >>> Format = Default swizzle > >>> Z24X8 = XXXX (Z) > >>> Z24S8 = XXXX (Z) > >>> X24S8 = YYYY (S) > >>> X8Z24 = YYYY (Z) > >>> S8Z24 = YYYY (Z) > >>> S8X24 = XXXX (S) > >>> Z32_S8X24 = XXXX (Z) > >>> X32_S8X24 = YYYY (S) > >> > >> I suppose you also get the right border color without any hacks? > >> I guess in theory these formats could use replicated swizzles in the > >> u_format description, instead of only the one-channel ones. That would > >> give the right result without doing anything special in drivers > >> following those bits. However, it can't be done consistently, since it > >> obviously won't work for depthstencil formats (which are still valid in > >> gallium for texturing, albeit it would be possible to change that and > >> enforce D24X8 views to be used instead). > >> And this wouldn't do anything for the fact you can't get the right bits > >> for stencil border color automatically that way (which is more > >> problematic since no matter the format swizzling or sampler state > >> swizzling it will always be wrong). (FWIW d3d10 decidedly uses the "G" > >> channel for stencil, and you'd supposedly get R = B = 0, G = S, A = 1 - > >> albeit there's no stencil-only S8 format, and since it's not possible to > >> use integer textures with ordinary sampling just ld, there's no sampler, > >> no border, no problem there...) > > > > We should do something sensible in u_format. State trackers should set > > texture_swizzle to get behavior to match whatever the API happens to > > prescribe. > > > It isn't really obvious if it's possible to do something more sensible > than what we've got now. The channel swizzle as-is make sense if you > look at it from the depth-stencil aspect - 1st component depth, 2nd > stencil, the rest undefined. For texturing, indeed it looks like the > requirements are different for everybody (d3d9, d3d10, legacy gl, new > gl), in particular for stencil (d3d10 will need stencil in green channel > with r/b 0 and a 1, gl will need stencil in red channel and god knows > what in the remaining channels), therefore requiring the texture_swizzle > in state trackers to take care of it really sounds like the only > possible solution. > I think the only way to make it less hacky would be to require texturing > from combined depthstencil surfaces to always use formats which have > only either depth or stencil but not both. Since right now sampling > depthstencil surfaces means just sampling the depth component. If we'd > enforce that such formats have to use a d24x8 format in the view, then > we would be able to use swizzles of xxxx (for depth) and yyyy (for > stencil) in the u_format descriptions. Albeit we could already do that > for s8, x24s8 etc. (everything with just stencil) for stencil. In any > case though that would need some more changes, there's code which relies > on those components having NONE swizzle to detect if the format contains > depth or stencil. > And it looks like no matter what we'd still need the state tracker to do > border color swizzling for stencil too.
This is roughly how the GL st works... It will select a stencil only version of the format for the view when stencil texturing. For zs views, the assumption is that you want z. -ilia
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
