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

[Ilia Mirkin]

On Dec 21, 2015 6:10 PM, "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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151221/79d5c610/attachment.html>