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

[Roland Scheidegger]

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.

Roland