Created attachment 80309 [details]
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.
I think this is all the same issue as bug #62922, #62482. This sort of aliasing problem only got noticeable when we shrunk the cache size (probably was always present just not visible). I guess we're missing some code somewhere to notice if the tile actually matches.
My version of Mesa predates the change mentioned in these two bugs - i.e. my number of texture tiles is actually 50, not 4. Note that in this case the hash collision happens before doing the % NUM_ENTRIES operation - i.e. the number of entries in the cache does not affect this bug.