[softpipe] img_filter_3d_linear returns incorrect results due to texture cache aliasing
Submitted by Arseny Kapoulkine
Assigned to mes..@..op.org
Description
Created attachment 80309 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:
- The 3D texture is 256x256x64; it has a 'wrap' filtering applied - the texture X axis is roughly horizontal on the screen
- 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)
- 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]
- 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.
Attachment 80309, "Bug screenshot":
Version: 9.1