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

[Ilia Mirkin]

Hi Andy,

Thanks for checking! I do see an issue on Tesla as well (at least G92,
and I believe someone else reported on a GT215 or GT218). However I
haven't confirmed that it's the identical issue to what I see on Fermi
with quite as much certainty as what I've checked on a GF108. (For the
G92, the texture buffer object test fails in the same way it does on
Fermi, but there could be other reasons for that.)

To be clear, when I say "unbound" for Fermi / Tesla, I mean
BIND_TSC(ACTIVE=0) (method 0x2400, bit 0 == 0). Kepler doesn't have
that, so presumably you mean TLD will look at TSC ID == 0,
irrespective of the TSC ID encoded into the texture handle.

The sRGB thing is ... rather annoying. Especially since texelFetch has
some kind of extra-specially-odd rule around sRGB conversion. I don't
remember what it is, but it feels like this would potentially make it
impossible to follow. But I guess going back in time and fixing the hw
is also difficult.

Can you confirm whether it will always look at slot 0, even in
LINKED_TSC mode (i.e. method 0x1234 == 1)? We don't currently make use
of that mode in nouveau, but I'm thinking about doing it on Tesla /
Fermi so that we can get more than 16 textures per stage on there.

Thanks again for the info!

  -ilia

On Wed, Mar 7, 2018 at 3:21 PM, Andy Ritger <aritger at nvidia.com> wrote:
> 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