On Dec 21, 2015 8:57 PM, "Marek Olšák" <mar...@gmail.com> wrote: > > On Tue, Dec 22, 2015 at 12:10 AM, 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. > > Since no GPU can fetch UNORM and UINT with the same sampler AFAIK, the > only swizzles that make sense are .xxxx and .yyyy (and combinations > with 0 and 1).
Fwiw you can set these per component on nv50+. Not sure if it'd actually work though. -ilia
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
