Bugzilla – Bug 73978
Intel driver breaks hardware accelerated flash on Chrome
Last modified: 2014-01-28 05:23:14 UTC
Created attachment 92673 [details]
Screenshot illustrating problem
The git snapshots from the past couple of days cause a problem in Google Chrome related to Flash, where pages with flash embedded are rendered incorrectly. I attached a screenshot to illustrate. Running Chrome with --disable-accelerated-compositing works, although there's just a black screen on flash videos. My hardware is Ivybridge. I have SNA enabled and no xorg.conf file, so defaults otherwise.
Another ivy bridge user here.
If you go to about:flags and enable the #ignore-gpu-blacklist and then enable #force-compositing-mode-2 for all websites, all websites will be broken in this way.
Just saying it's not just flash.
The easy remedy is not ignoring the gpu blacklist for now. :)
It's in chromium 32 and chrome 34.
In firefox nightly everything works as far as I have seen including webgl stuff.
So it's rather specific to whatever chromium does.
I can confirm that, and the issue is still there in the latest snapshots
I also confirmed this issue on two laptops, with Ivy Bridge and i965 graphics.
I have a feeling that I caused this with commit b2d1c579bb84a88179072a6a783f8827e218db55. I'll investigate.
Could you try these two patches?
Created attachment 92854 [details]
chromium: ignore gpu blacklist and active compositing on all websites
The two patches from comment #5 do not seem to help for me.
But do we even talk about the same problem?
Shaders don't seem to fail to compile, at least as far as I have seen. Is there anything that would help you figure this out like MESA_GLSL=dump?
I can confirm this bug on Sandybridge with SNA enabled (I'll try UXA and Glamor tonight) it doesn't show up when I use DRI_PRIME=1 on my r600g card if that provides any clues
Created attachment 92865 [details]
Spotify desktop client rendering
Getting similar distortion as shown in https://bugs.freedesktop.org/attachment.cgi?id=92854
In addition to Chrome and Chromium there's also parts of Spotify linux client that is affected with a similar distortion (attached screenshot). Started after updating a few days ago.
I got Chrome fixed by disabling "Use hardware acceleration when available" but no way to tell that to Spotify.
Firefox with default settings works alright, not sure about its accel settings..
i965 graphics (Intel HD3000).
Lenovo T520. Ubuntu running xmonad, kernel 3.12.0-031200-generic.
Not sure if it's helping but here's glxinfo | grep -i opengl
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.1.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.1.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
Sorry, forgot to add, not using git version..
Give this a try?
(In reply to comment #6)
> Shaders don't seem to fail to compile, at least as far as I have seen. Is
> there anything that would help you figure this out like MESA_GLSL=dump?
Yeah, MESA_GLSL=dump would probably be useful.
last good mesa version i built was git20140117.1c5e2965, first bad one was git20140124.43e77215, i didn't build anything between the two unfortunately. I'll add that patch to the PPA now
Created attachment 92885 [details]
MESA_GLSL=dump output with git20140127.4dd445f1
Created attachment 92886 [details]
google chrome shader dump
Here is another one, google chrome unstable starting up to the landing page or whatever it is which has the problem too.
This is with the latest patch from comment #10. It did sadly not help with the distortion, still there.
Thanks for finding out a close good mesa version, I'll see whether bisecting does result in the commit Matt Turner thought may caused it.
I created it with
MESA_GLSL=dump google-chrome-unstable > MESA_GLSL=dump_google-chrome-unstable
because with MESA_GLSL=log it says "Unable to open shader_1.vert for writing" for some reason. On the same system with radeonsi (DRI_PRIME=1) it can write the shaders. Strange. Might be another bug?
git bisect says
4bd6e0d7c69b304be88996a6c2b96ce7d996e627 is the first bad commit
narrowed it down a bit more, git20140121.ff59b3d9 was good
Ahh didn't see it was bisected already, sorry for the noise!
(In reply to comment #14)
> git bisect says
> 4bd6e0d7c69b304be88996a6c2b96ce7d996e627 is the first bad commit
If the shaders have flow-control, see bug #74113. See also bug #73954.
Let's try this too: http://patchwork.freedesktop.org/patch/18743/
Winner! The combo of the two does seem to work.
*** Bug 74058 has been marked as a duplicate of this bug. ***
Thanks guys! Committed as