Bug 73978 - Intel driver breaks hardware accelerated flash on Chrome
Intel driver breaks hardware accelerated flash on Chrome
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Matt Turner
Intel 3D Bugs Mailing List
:
: 74058 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-23 15:13 UTC by Brandon
Modified: 2014-01-28 05:23 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot illustrating problem (434.79 KB, image/png)
2014-01-23 15:13 UTC, Brandon
Details
chromium: ignore gpu blacklist and active compositing on all websites (103.02 KB, image/png)
2014-01-27 13:10 UTC, Christoph Haag
Details
Spotify desktop client rendering (312.15 KB, image/png)
2014-01-27 15:39 UTC, Ahti Kitsik
Details
MESA_GLSL=dump output with git20140127.4dd445f1 (84.40 KB, text/plain)
2014-01-27 21:12 UTC, Robert Hooker (Sarvatt)
Details
google chrome shader dump (40.00 KB, text/plain)
2014-01-27 22:08 UTC, Christoph Haag
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon 2014-01-23 15:13:07 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.
Comment 1 Christoph Haag 2014-01-25 23:20:56 UTC
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.
Comment 2 Dmitry Pashkevich 2014-01-26 11:53:09 UTC
I can confirm that, and the issue is still there in the latest snapshots
Comment 3 Victor 2014-01-26 20:22:44 UTC
I also confirmed this issue on two laptops, with Ivy Bridge and i965 graphics.
Comment 4 Matt Turner 2014-01-26 23:27:09 UTC
I have a feeling that I caused this with commit b2d1c579bb84a88179072a6a783f8827e218db55. I'll investigate.
Comment 5 Matt Turner 2014-01-27 02:15:58 UTC
Could you try these two patches?

http://patchwork.freedesktop.org/patch/18800/
http://patchwork.freedesktop.org/patch/18801/
Comment 6 Christoph Haag 2014-01-27 13:10:47 UTC
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?
Comment 7 Mike Lothian 2014-01-27 14:57:09 UTC
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
Comment 8 Ahti Kitsik 2014-01-27 15:39:14 UTC
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)
OpenGL extensions:
Comment 9 Ahti Kitsik 2014-01-27 16:12:52 UTC
Sorry, forgot to add, not using git version..

xserver-xorg-video-intel: 2:2.99.907+git20140125.294180b3-0ubuntu0sarvatt~saucy
Comment 10 Matt Turner 2014-01-27 18:57:27 UTC
Give this a try?

http://patchwork.freedesktop.org/patch/18837/

(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.
Comment 11 Robert Hooker (Sarvatt) 2014-01-27 21:04:58 UTC
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
Comment 12 Robert Hooker (Sarvatt) 2014-01-27 21:12:08 UTC
Created attachment 92885 [details]
MESA_GLSL=dump output with git20140127.4dd445f1
Comment 13 Christoph Haag 2014-01-27 22:08:03 UTC
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?
Comment 14 Christoph Haag 2014-01-27 22:27:48 UTC
git bisect says 

4bd6e0d7c69b304be88996a6c2b96ce7d996e627 is the first bad commit
Comment 15 Robert Hooker (Sarvatt) 2014-01-27 22:35:38 UTC
narrowed it down a bit more, git20140121.ff59b3d9 was good
Comment 16 Robert Hooker (Sarvatt) 2014-01-27 22:36:04 UTC
Ahh didn't see it was bisected already, sorry for the noise!
Comment 17 Ian Romanick 2014-01-27 22:37:57 UTC
(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.
Comment 18 Matt Turner 2014-01-27 22:56:45 UTC
Let's try this too: http://patchwork.freedesktop.org/patch/18743/
Comment 19 Robert Hooker (Sarvatt) 2014-01-27 23:01:13 UTC
Winner! The combo of the two does seem to work.
Comment 20 Matt Turner 2014-01-27 23:45:13 UTC
*** Bug 74058 has been marked as a duplicate of this bug. ***