[Mesa-dev] [PATCH] gallivm: add a horrible hack for stencil texturing with border

[Ilia Mirkin]

On Dec 21, 2015 8:57 PM, "Marek Olšák" <maraeo at gmail.com> wrote:
>
> On Tue, Dec 22, 2015 at 12:10 AM, Roland Scheidegger <sroland at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151221/a98e1f50/attachment.html>