[Mesa-dev] [PATCH v2 1/2] r600: correct texture offset for array index lookup

[Gert Wollny]

Am Freitag, den 29.06.2018, 17:42 +0200 schrieb Roland Scheidegger:
[...]
Thanks for the review 

> 
> So for gather4_O (where you'd need to do it differently) it must not
> be
> done, but for gather4 it has to be done?
> Still doesn't make all that much sense to me. The hw may be weird but
> I don't think it would be that weird?
Yes, this made me thinking too. First I was wondering whether all
gather4 operations ignore the offset (as in hardware bug), but no, this
is not the case. Then I looked at the created shaders. The first thing
I don't really understand is why the TGSI has

   TG4 TEMP[1], TEMP[1], IMM[1].xxxx, SAMP[0], 2D_ARRAY, TEMP[2].xyy

i.e. the offset Y coordinate is also passed into Z, but somehow this
seems to be irrelevant - I wonder whether this might pose a problem
somewhere else but here the piglit still passes.

However, the real fun comes from sb: The code created without adding
the offset to the texture coordinate: 

  0032  SET_TEXTURE_OFFSETS R0.____, R0.zww0,   RID:0, SID:0 CT:UUUU
  0036  GATHER4_O           R0.yzxw, R0.xy1_,   RID:18, SID:0 CT:NNUN

and this is what sb does when I add the 0.5 offset the the z
coordinate: 

  0032  SET_TEXTURE_OFFSETS R0.____, R0.____,   RID:0, SID:0 CT:UUUU
  0036  GATHER4_O           R0.yzxw, R0.xyz_,   RID:18, SID:0 CT:NNUN

Consequently, when disabling sb, the piglit also passes when I add the
0.5 offset, I've now also tested what happens when I set this offset
0.5 via SET_TEXTURE_OFFSETS, and it seems to work and sb doesn't do
funny things. 

Best, 
Gert