On Wed, Feb 17, 2016 at 11:13 AM, Roland Scheidegger <[email protected]> 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 <[email protected]> >> --- >> >> 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. > 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. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
