Bug 74700 - Dota2 shimmering artifacts on Mesa 10.0.1 on Iris Pro graphics
Summary: Dota2 shimmering artifacts on Mesa 10.0.1 on Iris Pro graphics
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.0
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 77449
  Show dependency treegraph
 
Reported: 2014-02-08 01:17 UTC by Pierre-Loup A. Griffais
Modified: 2014-09-05 22:06 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the corruption; this effect is supposed to be a subtle specular reflection (1.58 MB, image/png)
2014-02-08 01:17 UTC, Pierre-Loup A. Griffais
Details

Description Pierre-Loup A. Griffais 2014-02-08 01:17:27 UTC
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.
Comment 1 Kenneth Graunke 2014-02-08 03:14:27 UTC
I can confirm; Dylan has been able to reproduce this on our end.
Comment 2 Dylan Baker 2014-02-25 19:09:26 UTC
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.
Comment 3 Jordan Justen 2014-03-04 02:48:55 UTC
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?
Comment 4 Pierre-Loup A. Griffais 2014-03-04 03:03:20 UTC
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...
Comment 5 Ian Romanick 2014-03-07 14:08:57 UTC
(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.
Comment 6 Jordan Justen 2014-03-11 23:49:13 UTC
(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.)
Comment 7 Kenneth Graunke 2014-03-12 00:50:27 UTC
Jordan, I don't think we have independent dithering controls for RGB vs. A.
Just disabling it altogether for 1010102 seems reasonable to me.
Comment 8 Pierre-Loup A. Griffais 2014-03-31 21:34:10 UTC
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.
Comment 9 domagoj 2014-04-01 14:03:31 UTC
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:
Comment 10 domagoj 2014-04-01 14:43:38 UTC
(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
Comment 11 Matt Turner 2014-04-01 20:41:23 UTC
(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.
Comment 12 Courtney Goeltzenleuchter 2014-09-05 22:06:39 UTC
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.