| Summary: | Wrong result of S3TC DXT3 texture rendering | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ruslan Kabatsayev <b7.10110111> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED NOTABUG | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Test case
Screenshot |
||
Created attachment 125876 [details]
Screenshot
On this screenshot LHS is the swrast result, and RHS is i965. The former is wrong, the latter is correct.
[swr is for the literal 'swr' driver, not all swrast, reassigning to core] Sounds like your test-case is doing linear interp, and that's not working in swrast for some reason? Haven't looked at the actual test-case yet. (In reply to Ilia Mirkin from comment #2) > Sounds like your test-case is doing linear interp, and that's not working in > swrast for some reason? Haven't looked at the actual test-case yet. No, it uses nearest-neighbor filtering so that the image pixels are easier to see. The test renders fine for me with radeonsi, llvmpipe, softpipe, swrast. Mesa 11.2.2 and 12.1-dev, llvm 3.8, libtxc-dxtn0 1.0.1. (In reply to almos from comment #4) > The test renders fine for me with radeonsi, llvmpipe, softpipe, swrast. Mesa > 11.2.2 and 12.1-dev, llvm 3.8, libtxc-dxtn0 1.0.1. That's strange... I also tested on Mesa 10.3.2, 10.5.9 and 12.1-dev, but on Intel-based hardware (i915 and i965). Does software renderer somehow use X's HW acceleration for some actions? Might be broken display driver... Without having tested it, the image looks to me like it might be using s2tc decompression (which is what distros install due to patent issues). Which cheats a bit (no interpolation between the two base colors in a block). (In reply to Roland Scheidegger from comment #6) > Without having tested it, the image looks to me like it might be using s2tc > decompression (which is what distros install due to patent issues). Which > cheats a bit (no interpolation between the two base colors in a block). OK, removing libtxc-dxtn-s2tc0 indeed makes it render correctly (when true s3tc library is in LD_LIBRARY_PATH). But if I don't add the correct s3tc lib to LD_LIBRARY_PATH, i965 appears broken too, although its results were correct with s2tc. How can this be explained? Hmm, I seem to have expressed my question badly in comment 7. I mean: 1. with s2tc library and no s3tc, i965 result is correct, and swrast result is wrong 2. without s2tc but with s3tc library both are correct (as expected) 3. with both s2tc and s3tc removed both swrast and i965 are broken completely So the question is now: why is i965 broken without s2tc if it seemed to decode the texture without shortcomings of s2tc when s2tc was installed? How is swrast different from it in this regard? s3tc is completely disabled if libtxc_dxtn.so isn't found. OK, so this seems to be a misconfiguration, not a bug. |
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 125875 [details] Test case The attached test case works correctly when used with e.g. i965 driver, but gives wrong result with LIBGL_ALWAYS_SOFTWARE=1, regardless of what swrast driver is in use: llvmpipe, softpipe and non-gallium SW renderers all behave the same wrong way. I've tried installing libtxc_dxtn, but it didn't change anything.