| Summary: | Dota2 shimmering artifacts on Mesa 10.0.1 on Iris Pro graphics | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Pierre-Loup A. Griffais <pgriffais> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | cworth, eero.t.tamminen, jljusten, mattst88 |
| Version: | 10.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 77449 | ||
| Attachments: | Screenshot of the corruption; this effect is supposed to be a subtle specular reflection | ||
I can confirm; Dylan has been able to reproduce this on our end. I have been able to reproduce this on Ivy bridge GT2 on Gentoo and on Haswell HD4400 on Debian sid, both with mesa from git. I have observed that disabling GL_DITHER will remove this undesirable rendering. DOTA2 is rendering to a framebuffer bound to an RGB10_A2 texture when the corruption first appears to happen. The undesirable rendering appears on the alpha channel. It doesn't appear that DOTA2 gets or sets GL_DITHER. According to the OpenGL spec, dithering is enabled by default, but Matt Turner also points out that the spec notes in "Appendix B Corollaries": "Dithering algorithms may be different for different components. In particular, alpha may be dithered differently from red, green, or blue, and an implementation may choose to not dither alpha at all." So, it appears that other implementations may disable dithering for alpha, or perhaps only for alpha on RGB10_A2. A question regarding DOTA2: Does it specifically want GL_DITHER enabled? Interesting; thanks for tracking this down. This might explain why we're also seeing this on Mac if this is a different HW behavior. I'll try to figure out whether we want dithering, and whether this is in line with what we'd expect. I suspect that this default behavior makes rendering RGB10_A2 on Intel pretty different from what people will actually expect... (In reply to comment #3) > I have observed that disabling GL_DITHER will > remove this undesirable rendering. I won't even ask how you noticed that... > DOTA2 is rendering to a framebuffer bound to an > RGB10_A2 texture when the corruption first appears > to happen. The undesirable rendering appears on the > alpha channel. I think dithering is useless on 10-bit colors (because there are enough steps in the gradient already), and it's actively harmful on 2-bit components (because there aren't enough!). Let's just always disable dithering on RGB10_A2. There may be a couple other color formats where we should also disable it. (In reply to comment #5) > (In reply to comment #3) > > DOTA2 is rendering to a framebuffer bound to an > > RGB10_A2 texture when the corruption first appears > > to happen. The undesirable rendering appears on the > > alpha channel. > > I think dithering is useless on 10-bit colors (because there are enough > steps in the gradient already), and it's actively harmful on 2-bit > components (because there aren't enough!). Let's just always disable > dithering on RGB10_A2. There may be a couple other color formats where we > should also disable it. Looking in the OpenGL 3.2 Core spec, there is very little really mentioned about dithering requirements. The quote I mentioned before does seem to give drivers plenty of wiggle room for how to implement dithering. It specifically says that alpha dithering may be disabled and says that "Dithering algorithms may be different for different components." Is fully disabling dithering for this format acceptable, or do we need to just disable alpha dithering? I would be all for just blanket disabling dithering with RGB10_A2 if it is fine spec-wise. Valve still might want to consider disabling it at the app level given driver install base issues. (Assuming that is acceptable for DOTA2 rendering.) Jordan, I don't think we have independent dithering controls for RGB vs. A. Just disabling it altogether for 1010102 seems reasonable to me. Looking at our code it seems to already believe dithering is a non-managed state (good), with a default state of disabled (incorrect). I'll slam it off by default in Dota OpenGL contexts, which should avoid this issue entirely. Thanks a lot for tracking this down. i have problem whith my texture after updating linux karnel 3.14 i m runing mint 16 http://imgur.com/5pCfzOn http://imgur.com/1si6T86 http://imgur.com/UrBpTfy http://imgur.com/IQc2Txl any help for me i think that is rendering mode problem ? Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller X.Org: 1.14.5 drivers: intel (unloaded: fbdev,vesa) Resolution: 1360x768@59.8hz GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.2.0-devel OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: (In reply to comment #7) > Jordan, I don't think we have independent dithering controls for RGB vs. A. > Just disabling it altogether for 1010102 seems reasonable to me. i have problem whith my texture after updating linux karnel 3.14 i m runing mint 16 http://imgur.com/5pCfzOn http://imgur.com/1si6T86 http://imgur.com/UrBpTfy http://imgur.com/IQc2Txl any help for me i think that is rendering mode problem ? Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller X.Org: 1.14.5 drivers: intel (unloaded: fbdev,vesa) Resolution: 1360x768@59.8hz GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.2.0-devel OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Add Comment (In reply to comment #10) > i have problem whith my texture after updating linux karnel 3.14 i m runing > mint 16 File another bug. Don't clutter this one. Verified fixed in app. |
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 93638 [details] Screenshot of the corruption; this effect is supposed to be a subtle specular reflection We're seeing a problem where DOTA2 exhibits incorrect specular reflections when ran on Intle graphics. To reproduce this issue, watching any ongoing game and panning the camera over the Radiant side of the map seems to do it. What is supposed to be subtle specular reflection on the ground and trees ends up looking very noisy and shimmery. This is very easy to reproduce out of the box on the Brix SteamOS machines.