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

[Marek Olšák]

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).

Marek