[Mesa-dev] [PATCH] st/mesa: apply DepthMode swizzle to stencil texturing as well

[Roland Scheidegger]

Am 17.02.2016 um 17:17 schrieb Ilia Mirkin:
> On Wed, Feb 17, 2016 at 11:13 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 17.02.2016 um 14:43 schrieb Ilia Mirkin:
>>> Gallium doesn't present these as GL_RED-style. A swizzle is necessary to
>>> present the proper data in the unused components.
>>>
>>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>>> ---
>>>
>>> The GL 4.5 compat spec also makes it clear that sampling from stencil is the
>>> same as sampling from depth (except obviously the stencil value is used). So
>>> the same swizzling rules should apply.
>>>
>>> However I'm unaware that this fixes anything in particular.
>>>
>>>  src/mesa/state_tracker/st_atom_texture.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_atom_texture.c b/src/mesa/state_tracker/st_atom_texture.c
>>> index f59eeec..4b7ad77 100644
>>> --- a/src/mesa/state_tracker/st_atom_texture.c
>>> +++ b/src/mesa/state_tracker/st_atom_texture.c
>>> @@ -148,9 +148,7 @@ compute_texture_format_swizzle(GLenum baseFormat, GLenum depthMode,
>>>        else
>>>           return SWIZZLE_XYZW;
>>>     case GL_STENCIL_INDEX:
>>> -      return SWIZZLE_XYZW;
>>>     case GL_DEPTH_STENCIL:
>>> -      /* fall-through */
>>>     case GL_DEPTH_COMPONENT:
>>>        /* Now examine the depth mode */
>>>        switch (depthMode) {
>>>
>>
>> A while ago I noticed and asked about the interaction with gallium
>> formats. The problem is that for gallium this would be more like a
>> "green" swizzle, since according to current format definitions stencil
>> is always the second channel, i.e PIPE_FORMAT_S8_UINT has a channel
>> swizzle of _x__, PIPE_FORMAT_X24S8_UINT _y__ and so on. This is a
> 
> Hrmph... do these swizzles get applied anywhere, or just "in the
> spec"? FWIW nouveau just returns stencil-in-all-channels for
> stencil-only formats. I guess util/formats.csv has it as you
> described, but I'm not sure that gets applied anywhere.
Yes, I suppose most drivers ignore this. But for software based drivers,
a mismatch means these formats need to have special code for sampling
(and there's always the chance you miss that somewhere). That said there
is already some code to deal with it, though it isn't quite all working
(for gl).

> 
>> d3d10-ism really, but because it is legal in gallium to sample formats
>> which have both depth and stencil the channel swizzle cannot be
>> described consistently (this could be fixed by requiring depth-only or
>> stencil-only formats for sampler views).
>> Albeit for border color, we still need the "red" component (d310, of
>> course, doesn't have any problem there, since border color is impossible
>> with int/uint formats).
>> But this change is ok by me, it doesn't really make things worse...
> 
> It didn't at all fix the dEQP tests I was hoping it would fix, but it
> seems like the right thing. I think there's a lot of confusion around
> what goes in what channel for depth/stencil. If all drivers can agree
> on something consistent, we can implement that here too.
> 

I suppose doing this gl-style here makes sense. Not sure if the format
defs really should be changed, probably just need some code to handle
border specially for stencil formats in gallivm sampling code for llvmpipe.

Reviewed-by: Roland Scheidegger <sroland at vmware.com>