[Nouveau] TLD instruction usage in non-linked sampler mode

[Andy Ritger]

Hi Ilia.

It looks like there is a hardware bug on Fermi and Kepler where TLD 
unconditionally uses the sampler from slot 0.  This is supposedly fixed
in Maxwell.  What I could find internally suggests the bug wasn't present
on Tesla, but let me know if your observations contradict that.

The only work around is to have a sampler defined and bound.  Further,
be careful to have reasonable state in the entry in slot #0: as I
understand it, the one piece of sampler state that will influence TLD
is sRGBConversion (bit 13).

I hope that helps,
- Andy


On Thu, Mar 01, 2018 at 11:47:18PM -0500, Ilia Mirkin wrote:
> Hello,
> 
> This question is in the context of Tesla / Fermi generations, which
> have explicit bindings for textures / samplers. It might also apply to
> Kepler+, not quite as sure due to the bindless nature.
> 
> I've been trying to understand how the TLD operation works (which is
> used to implement texelFetch in GLSL). It does not appear to the op
> takes an explicit sampler id at all (unlike all the other texturing
> operations). In unlinked TSC mode (i.e. method 0x1234 == 0), my
> observation is that it desperately wants for a valid sampler to be
> bound to sampler slot 0. Of course I don't think TLD actually needs
> anything from the sampler, which makes this all the more odd.
> 
> Is that a correct assessment of the operation of the TLD instruction?
> Is there any way to make it just not care about the sampler binding?
> Does the DirectX driver just always keep something bound to sampler
> slot 0? (And what happens on Kepler+? Does it always look at TSC ID ==
> 0?)
> 
> (I kind of assume that all these problems go away in linked TSC mode,
> since it'd naturally just look up the TSC entry associated with the
> bound TIC.)
> 
> Thanks,
> 
>   -ilia