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 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau