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