https://bugs.freedesktop.org/show_bug.cgi?id=90264
Bug ID: 90264 Summary: [Regression, bisected] Tooltip corruption in Chrome Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: falaca@gmail.com CC: kenneth@whitecape.org
There is intermittent tooltip corruption in Chrome, after the following Mesa commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4...
In order to verify, I built mesa 10.6 master from git (w/ llvm 3.4.2, to stay consistent with my git bisect) with those lines commented, and the bug is no longer present.
The bug has been reported here, and affects both r600 and radeonsi users: https://code.google.com/p/chromium/issues/detail?id=442111
On that page, affected users are reporting a range of kernel versions (3.16+) and mesa versions (10.4+).
Another anecdote which may help narrow down the issue: Sometimes the tooltip shows partial contents from a previously-displayed tooltip. As can be seen from the following screenshot, the tooltip shows the last few characters of the #radeon channel topic, followed by a white space and then the alt text of another channel: https://www.dropbox.com/s/lsg0walzuvw12of/tooltip_corruption2.png?dl=0
Another user (see IRC log from screenshot above) mentioned that sometimes the tooltip even shows contents from another process.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|DRM/Radeon |Drivers/Gallium/radeonsi Version|unspecified |git Product|DRI |Mesa QA Contact| |dri-devel@lists.freedesktop | |.org
--- Comment #1 from Michel Dänzer michel@daenzer.net --- Does it also happen if you run Chrome with the environment variable LIBGL_ALWAYS_SOFTWARE=1 to use the llvmpipe software rasterizer? Or do you know if it also happens e.g. with the nouveau drivers?
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #2 from falaca@gmail.com --- Michel, I just tested it right now, and there is no corruption when I set LIBGL_ALWAYS_SOFTWARE=1.
The screenshot I linked to is from the glowing-bear web IRC client, and I just need to mouse over 2 or 3 items before the corruption shows up, so it should be pretty easy for anybody else to reproduce with Chrome.
Further info: I'm running linux 3.19, Xorg 1.17.1, and both mesa & DDX from git.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #3 from Michel Dänzer michel@daenzer.net --- (In reply to falaca from comment #2)
Michel, I just tested it right now, and there is no corruption when I set LIBGL_ALWAYS_SOFTWARE=1.
Does Chrome enable GPU acceleration in that case as well? If yes, the bug seems to be somewhere in the Radeon specific code.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #4 from falaca@gmail.com --- When I set LIBGL_ALWAYS_SOFTWARE=1, chrome://gpu shows "Software only" for all the features, and the GL_RENDERER string is "Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)".
It does appear to be a bug somewhere in the Radeon-specific code, but based on my tests above, it looks like the bug is triggered by the Mesa commit that I bisected. The purpose of the commit (if I understand correctly) is to avoid processing redundant viewport updates, so it seems like that causes the radeon driver to display stale content.
This may or may not be related, but here is another interesting screenshot: https://www.dropbox.com/s/9ydljofmj8kfxme/corruption_2.png?dl=0
That is my desktop, and you can see some white tiles surrounding the "Portal" icon. Those tiles are showing content from another window (Android Studio) which I had previously launched and then minimized. If you download the picture and zoom in, you can see the little folder icons with the Android logo on them. So that also seems like an issue of displaying stale content.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #5 from Jose P. lbdkmjdf@sharklasers.com --- I can confirm this bug, that I've seen text from other processes in the corrupted tooltips, and that Chromium + LIBGL_ALWAYS_SOFTWARE=1 does not show corruption. With LIBGL_ALWAYS_SOFTWARE=1, in Chromium ( chrome://gpu ) I get "Hardware Accelerated" for all items under "Graphics Feature Status", and GL_RENDERER = "Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)". BTW, I have a Llano APU: OpenGL renderer string: Gallium 0.4 on AMD SUMO.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #6 from Jose P. lbdkmjdf@sharklasers.com --- I should add, I get "Hardware Accelerated" because I enabled "Override software rendering list" ( chrome://flags/#ignore-gpu-blacklist ) in Chromium...
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #7 from falaca@gmail.com --- FWIW, the corruption doesn't occur on my laptop with Intel graphics (w/ hardware accelerated compositing, just like on my desktop). Also, on my desktop when I set LIBGL_ALWAYS_SOFTWARE=1 and the flag in chrome://flags to force hardware acceleration, I get the same result as Jose (no corruption).
I realized that, at least for me, this is much easier to reproduce on some pages than on others. It's much more likely to happen with multi-line tooltips. To make it easy for anybody to test, I exported this HTML page from my web IRC client: https://www.dropbox.com/s/8kkanknv25jzvtk/test_tooltips.html?dl=1
The easiest way to test it is to mouse over the #radeon channel topic at the top of the page and view the tooltip (this one is 3 lines long). Then, mouse over some of the channel names on the left-hand side to view their tooltips. Then, start mousing back and forth between the channel topic and the different channels. After a couple of tries, you'll start to see the corruption and stale content, with parts of the #radeon channel topic being replaced by the other channel names.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #8 from AP ap345621@gmail.com --- I can confirm this issue. Running the latest Mesa built from Pali's 12.04 backports PPA (https://launchpad.net/~pali/+archive/ubuntu/graphics-drivers) I am seeing the same kind of graphical corruption in tooltips: They will often look scrambled and, as pointed out above, are sometimes replaced by textures from other apps (e.g. my dock). As far as I can tell this is restricted to Chrome for now.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
Matt Whitlock freedesktop@mattwhitlock.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |freedesktop@mattwhitlock.na | |me
--- Comment #9 from Matt Whitlock freedesktop@mattwhitlock.name --- It's not just Radeon. I'm running the Nouveau driver 1.0.11 on Linux 3.18.12-gentoo with Mesa 10.5.6, and I am seeing corruption of tooltips and some context menus in Chromium 44.0.2403.30.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #10 from Matt Whitlock freedesktop@mattwhitlock.name --- Whenever a context menu in Chromium fails to display correctly (shows as solid black instead), the following lines (or similar) are appended to the kernel message log:
nouveau E[chrome[5932]] multiple instances of buffer 249 on validation list nouveau E[chrome[5932]] validate_init nouveau E[chrome[5932]] validate: -22
Does not happen upon display of corrupted tooltips, only context menus.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #11 from Matt Whitlock freedesktop@mattwhitlock.name --- My bug may have a different cause, as downgrading to Chromium 43.0.2357.73 restored correct behavior.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #12 from Ilia Mirkin imirkin@alum.mit.edu --- (In reply to Matt Whitlock from comment #10)
Whenever a context menu in Chromium fails to display correctly (shows as solid black instead), the following lines (or similar) are appended to the kernel message log:
nouveau E[chrome[5932]] multiple instances of buffer 249 on validation list nouveau E[chrome[5932]] validate_init nouveau E[chrome[5932]] validate: -22
Does not happen upon display of corrupted tooltips, only context menus.
I suspect you were using libdrm 2.4.60. Use either .59 or .61 and that particular error will go away. That said, I also see the tooltip fail in chrome on a GF108 (nvc0 driver) for a few versions of chrome now.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #13 from Matt Whitlock freedesktop@mattwhitlock.name --- (In reply to Ilia Mirkin from comment #12)
(In reply to Matt Whitlock from comment #10)
nouveau E[chrome[5932]] multiple instances of buffer 249 on validation list nouveau E[chrome[5932]] validate_init nouveau E[chrome[5932]] validate: -22
I suspect you were using libdrm 2.4.60. Use either .59 or .61 and that particular error will go away. That said, I also see the tooltip fail in chrome on a GF108 (nvc0 driver) for a few versions of chrome now.
Thanks! I was indeed using libdrm 2.4.60. Downgrading to 2.4.59 solved the problem of the solid black menus, so at least my Chromium is usable again, but I still have corrupted tooltips sometimes.
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #14 from Furkan falaca@gmail.com --- For those of you who are using nouveau, does the problem go away after reverting the mesa commit that I bisected?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4...
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #15 from Matt Whitlock freedesktop@mattwhitlock.name --- (In reply to Furkan from comment #14)
For those of you who are using nouveau, does the problem go away after reverting the mesa commit that I bisected?
http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6
Yes, the problem goes away after reverting that commit on Mesa 10.5.6.
The problem also goes away when using an old enough Chrome.
bisect-builds.py (Chrome):
You are probably looking for a change made after 324982 (known good), but no later than 324987 (first known bad).
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #16 from Furkan falaca@gmail.com --- What do those revision numbers represent? Are they binary builds? They don't look like svn/git commits. If we have a commit range, we can view the changelog between them by plugging the revision numbers into one of these URLs:
https://chromium.googlesource.com/chromium/src/+log/SUCCESS_REV..FAILURE_REV...
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/t...
(see https://code.google.com/p/chromium/wiki/UsefulURLs)
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #17 from Matt Whitlock freedesktop@mattwhitlock.name --- (In reply to Furkan from comment #16)
What do those revision numbers represent? Are they binary builds? They don't look like svn/git commits.
They're Subversion revisions, which is what Chromium's bisect-builds.py script demands.
bisect-builds.py also kicked out this ChangeLog URL:
https://chromium.googlesource.com/chromium/src/+log/28ad5e6b1100a7f0d25a5e67...
…but it doesn't show any commits. I don't know why.
The command line I used for bisecting was:
$ ./bisect-builds.py -a linux64 --use-local-cache -g 323860 -b 330231
Revisions 323860 and 330231 correspond to releases 43.0.2357.73 and 44.0.2403.18, respectively. (The rendering problem appeared on my system when I upgraded Chromium from the former to the latter release, so those were my starting points for bisection.)
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #18 from Furkan falaca@gmail.com --- I'm using Chrome 43.0.2357.124 (latest stable version).
I installed the latest Chromium build from the Ubuntu repo, which is 43.0.2357.81. However, going to chrome://gpu shows that everything is "software only" (so the tooltips work fine).
Might be worth taking a look if maybe going from one version to the other caused you to switch from software only to hardware-accelerated?
You mentioned the issue happened when you upgraded from 43.0.2357.73 to 44.0.2403.18. So I checked out this URL:
https://chromium.googlesource.com/chromium/src/+log/43.0.2357.73..44.0.2403....
And surely enough: https://chromium.googlesource.com/chromium/src/+/4c9c8b2238012338a6395f7101d...
"Enable hardware acceleration for Nouveau and Stage3D".
https://bugs.freedesktop.org/show_bug.cgi?id=90264
Furkan falaca@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brianp@vmware.com Component|Drivers/Gallium/radeonsi |Mesa core Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org
--- Comment #19 from Furkan falaca@gmail.com --- I booted up a Haswell box from an Ubuntu 15.04 live USB, and was able to reproduce the same glitch.
It looks like we can reproduce this on radeon, nouveau, and i965, but not llvmpipe. What does that mean? I am re-classifying this under Mesa core for now. Would it fit better under any other category?
Can anybody confirm that this issue isn't present with the Nvidia proprietary driver?
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org