[Mesa-dev] [PATCH 1/2] i965: Make the precompile ignore DEPTH_TEXTURE_MODE on Gen7.5+.

Kenneth Graunke kenneth at whitecape.org
Fri Jan 2 03:01:23 PST 2015


On Thursday, January 01, 2015 11:16:17 PM Ian Romanick wrote:
> On 01/01/2015 10:51 PM, Kenneth Graunke wrote:
> > On Thursday, January 01, 2015 10:21:43 PM Ian Romanick wrote:
> >> On 12/31/2014 08:04 PM, Kenneth Graunke wrote:
> >>> Gen7.5+ platforms that support the "Shader Channel Select" feature leave
> >>> key->tex.swizzles[i] as SWIZZLE_NOOP except when GL_DEPTH_TEXTURE_MODE
> >>> is GL_ALPHA (which is really uncommon).  So, the precompile should leave
> >>> them as SWIZZLE_NOOP (aka SWIZZLE_XYZW) as well.
> >>>
> >>> We didn't notice this because prog->ShadowSamplers is not set correctly.
> >>> The next patch will fix that problem.
> >>
> >> I had some patches related to this a long time ago, but I'm not sure
> >> what happened to them.  My recollection is that, basically, nothing
> >> should use prog->ShadowSamplers.  That was only used by the
> >> ARB_fragment_program assembler, and other paths (including ff fragment
> >> programs) don't set these fields.  I just pushed the (ancient!) branch
> >> to my fd.o repo as r300-shadow-samplers.  The two patches are from 2011. :(
> > 
> > No, it's definitely set.
> > 
> > link_uniforms.cpp sets shader->shadow_samplers, which ir_to_mesa copies
> > to prog->ShadowSamplers.  I'm guessing we stopped copying that at some point.
> > 
> > I don't see why we shouldn't use it...
> 
> The commit message from one of those patches explains it:
> 
> commit 6498addabe8fcb8a96064ecdd15b6438b66e1089
> Author: Ian Romanick <ian.d.romanick at intel.com>
> Date:   Mon Nov 14 21:33:27 2011 -0800
> 
>     r300g: Use rc_sub_instruction::TexShadow, not gl_program::ShadowSamplers
>     
>     gl_program::ShadowSamplers has two possible meanings.  For
>     ARB_fragment_program, it tells which texture units have been used with
>     shadow comparisons (e.g., the SHADOW2D texture target).  The flags are
>     used by the assembler to generate errors when programs use the same
>     texture unit for both shadow and non-shadow look-ups.
>     
>     For a GLSL program, it tells which *abstract* GLSL sampler uniforms
>     were declared as a shadow sampler type (e.g., sampler1DShadow).  In
>     GLSL, sampler indices do *NOT* correspond to texture units (as they do
>     in ARB_fragment_program).  By calling glUniform1i, an application can
>     bind texture unit 3 to sampler 7.
>     
>     At this point in code generation, we may want to know if texture unit
>     3 has shadow comparisons enabled or if sampler 7 was a shadow sampler.
>     The old code determined if texture unit 3 has shadow comparisons
>     enabled or if sampler 3 was a shadow sampler.  This is clearly wrong.
>     
>     Signed-off-by: Ian Romanick <ian.d.romanick at intel.com>
>     Cc: Tom Stellard <tstellar at gmail.com>
>     Cc: Marek Olšák <maraeo at gmail.com>
>     Cc: Alex Deucher <alexander.deucher at amd.com>
> 
> Long story short, from the next commit message, "The only places that
> really need this data are at fairly high levels in the GLSL compiler or
> the ARB_fragment_program assembler.  Every place else really wants some
> other field."
> 
> At the time I wrote that code, r300 was the only driver using
> gl_program::ShadowSamplers.  It looks like i965 started using it about
> a year later.  Either the meaning of that field has changed, my
> understanding of it is completely wrong, or we shouldn't use it either.
> 
> > --Ken

Ah.  I see what you mean.  However, I believe i965 is doing the right thing,
and really does want ShadowSamplers.

The i965 backend compiler uses abstract sampler numbers, and doesn't care
what texture units they currently correspond to.  (Otherwise, we'd have to
recompile every time we changed sampler uniforms, which would be awful!)

When populating the program key, we loop over the samplers, and look at which
texture units they're currently bound to.  We also inspect the images bound
to those texture units.  (In other words, we map from sampler -> texunit -> 
texobj.)  We store this information in fields indexed by the abstract sampler
number (/not/ the texture unit).  For example, key->tex.swizzles[sampler].

We recompute the program key on _NEW_TEXTURE, and uniform_query.cpp flags
_NEW_TEXTURE whenever the sampler uniforms change.  So, the program key
has an accurate view of current bindings.

When precompiling, we look at prog->ShadowSamplers, which tells us
which sampler uniform variables have (e.g.) sampler2DShadow type.  The
assumption is that shadow samplers will be used with depth textures,
and regular sampler variables will be used with color textures.  There is
no current state when precompiling; we're just guessing what the likely state
will be at some point in the future.

When computing the actual program key, we consult the actual texture object
currently bound (doing the sampler -> texunit -> texture object mapping).
We do *not* use prog->ShadowSamplers here.  We use real data.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150102/a652491c/attachment.sig>


More information about the mesa-dev mailing list