Created attachment 80309 [details]
Bug screenshot

img_filter_3d_linear calls get_texel_3d 8 times for each of the 8 neighbor pixels; get_texel_3d returns a pointer to the texel data.

In some cases the data referenced by one the pointers changes in a subsequent call to get_texel_3d; as a result, filtering works on wrong values and produces bogus results.

Screenshot of the bug is attached; note that the lighting data (gradients) is sampled from a 3D texture, and the texel size is the same as the size of one brick-textured cell on the screenshot; i.e. the edges in the gradients are caused by filtering errors.

Here's what happens:
1. The 3D texture is 256x256x64; it has a 'wrap' filtering applied - the texture X axis is roughly horizontal on the screen
2. A shader requests a texture fetch which results in the following 2x2x2 texel region:
[255 11 0] - [0 12 1]

(the region wraps around along X)

3. Mesa computes the texture tile indices for each sample; for one corner of the sampled region this is [3 0 0]; for the other it's [0 0 1]
4. The texture cache is addressed based on the hash of the tile index, which is computed by tex_cache_pos; it returns 3 for both tiles

As a result, when the second group of texels (that corresponds to Z=1) is fetched, a tile for Z=0 is overwritten by the tile for Z=1. Since img_filter_3d_linear does not copy the data, the pointers tx00, tx01, tx02, tx03 now point to the tile for Z=1 instead of Z=0.