[Mesa-dev] [PATCH] gallivm: add a horrible hack for stencil texturing with border
Roland Scheidegger
sroland at vmware.com
Wed Dec 16 08:53:32 PST 2015
Am 16.12.2015 um 17:39 schrieb Marek Olšák:
> On Wed, Dec 16, 2015 at 5:18 PM, Roland Scheidegger <sroland at vmware.com> 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?
>
> Border colors are somewhat broken on radeon due to hw design reasons,
> so usually no and I can't do anything about it.
Ah ok. I guess border color for stencil is your least worry then :-).
>
>> 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).
>
> Yeah that would work too.
>
>> 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...)
>
> Well, st/mesa could set the border color to (d,d,d,d) for depth and
> (s,s,s,s) for stencil, so that it works with any hardware behavior we
> may get.
Yes, that would work. I actually thought it would simply pass them
through from gl, but it already does quite some fixup even without the
hw quirks, so that looks like the right place for fixups.
Roland
More information about the mesa-dev
mailing list