| Summary: | [softpipe] img_filter_3d_linear returns incorrect results due to texture cache aliasing | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Arseny Kapoulkine <arseny.kapoulkine> |
| Component: | Drivers/Gallium/softpipe | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 9.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Bug screenshot | ||
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. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/210. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.