Bug 90264

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?

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.

(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.

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.

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.

I should add, I get "Hardware Accelerated" because I enabled "Override software rendering list" ( chrome://flags/#ignore-gpu-blacklist ) in Chromium...

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.

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.

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.

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.

My bug may have a different cause, as downgrading to Chromium 43.0.2357.73 restored correct behavior.

(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.

(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.

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

(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).

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?pretty=fuller

http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=SUCCESS_REV:FAILURE_REV

(see https://code.google.com/p/chromium/wiki/UsefulURLs)

(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/28ad5e6b1100a7f0d25a5e6741f7241a86cf61bd..1050ee48b1d8fe353bfc7df3b0ea4e5300260f5c

…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.)

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.18?pretty=fuller&n=10000

And surely enough: https://chromium.googlesource.com/chromium/src/+/4c9c8b2238012338a6395f7101d036e3634ed687

"Enable hardware acceleration for Nouveau and Stage3D".

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?

I booted up a Haswell (i7-4770) machine 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 re-classified this under Mesa core for now.

Can anybody confirm that this issue isn't present with the Nvidia proprietary driver?

This seems to have been fixed, I can't see the corruption anymore. I'm using Chromium 43.0.2357.81 on Ubuntu 14.04 (64-bit) and Mesa 10.7.0-devel (git-20dca37 2015-06-23 trusty-oibaf-ppa).

This bug also occur on my computer with Intel graphics. It seems that it only occur with DRI3 enabled, tested with both xf86-video-intel and xf86-video-modesetting drivers.

Still there for me.

I'm using Ubuntu 15.04, Chrome 43.0.2357.130, Linux 4.1, and Mesa 10.7~git1506250730.d1663c~gd~v from oibaf ppa.

Furkan, try launching chrome with LIBGL_DRI3_DISABLE=1 and see if the problem still persist. The problem at least went away on my machine when I disable DRI3.

I forgot to add, I have DRI3 disabled already. From my Xorg log:

[    12.974] (II) RADEON(0): [DRI2] Setup complete
[    12.974] (II) RADEON(0): [DRI2]   DRI driver: radeonsi
[    12.974] (II) RADEON(0): [DRI2]   VDPAU driver: radeonsi
[    12.974] (II) RADEON(0): Front buffer size: 9120K
[    12.974] (II) RADEON(0): VRAM usage limit set to 1857373K
[    12.974] (==) RADEON(0): DRI3 disabled

(In reply to Matt Whitlock from comment #15)
> (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.

Based on above comments, on Intel disabling DRI3 also makes the bug go away, but not on AMD.  What about your Nouveau setup?

(In reply to Eero Tamminen from comment #26)
> (In reply to Matt Whitlock from comment #15)
> > (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.
> 
> Based on above comments, on Intel disabling DRI3 also makes the bug go away,
> but not on AMD.  What about your Nouveau setup?

Nouveau doesn't yet support DRI3 (on my chipset?).

(II) NOUVEAU(0): [DRI2] Setup complete
(II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
(II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
(II) GLX: Initialized DRI2 GL provider for screen 0

(In reply to Matt Whitlock from comment #27)
> (In reply to Eero Tamminen from comment #26)
> > (In reply to Matt Whitlock from comment #15)
> > > (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.
> > 
> > Based on above comments, on Intel disabling DRI3 also makes the bug go away,
> > but not on AMD.  What about your Nouveau setup?
> 
> Nouveau doesn't yet support DRI3 (on my chipset?).
> 
> (II) NOUVEAU(0): [DRI2] Setup complete
> (II) NOUVEAU(0): [DRI2]   DRI driver: nouveau
> (II) NOUVEAU(0): [DRI2]   VDPAU driver: nouveau
> (II) GLX: Initialized DRI2 GL provider for screen 0

If you get the nouveau ddx from git, it should have DRI3 support.

(In reply to Ilia Mirkin from comment #28)
> If you get the nouveau ddx from git, it should have DRI3 support.

I might look into that. Is there any compelling reason why I should care about DRI3?

Also, for what it's worth, this problem seems to have disappeared for me. I have rebuilt Mesa 10.5.6 without the revert of 95073a2d, and Chromium 44.0.2403.30 is no longer exhibiting the bug for me. I am still on libdrm 2.4.59, but I have since upgraded my Linux kernel to 4.0.5-gentoo.

(In reply to Matt Whitlock from comment #29)
> Also, for what it's worth, this problem seems to have disappeared for me. I
> have rebuilt Mesa 10.5.6 without the revert of 95073a2d, and Chromium
> 44.0.2403.30 is no longer exhibiting the bug for me. I am still on libdrm
> 2.4.59, but I have since upgraded my Linux kernel to 4.0.5-gentoo.
>
> Is there any compelling reason why I should care about DRI3?

Just to verify whether the issue is (now) DRI3 specific like it seems to be for other drivers.

FWIW, I tried temporarily enabling DRI3, and the effect for me is exactly the same as it is with DRI2.

I have other problems with DRI3 and Chrome (that's why I keep it disabled), but that's a subject for another bug report.

(In reply to Matt Whitlock from comment #29)
> Also, for what it's worth, this problem seems to have disappeared for me. I
> have rebuilt Mesa 10.5.6 without the revert of 95073a2d, and Chromium
> 44.0.2403.30 is no longer exhibiting the bug for me. I am still on libdrm
> 2.4.59, but I have since upgraded my Linux kernel to 4.0.5-gentoo.

I spoke too soon. I am still seeing tooltip corruptions in Chromium 44.0.2403.61 on Linux 4.0.5-gentoo, libdrm 2.4.62, Nouveau 1.0.11, and Mesa 10.6.1 (without the revert of 95073a2d).

(In reply to Jose P. from comment #21)
> This seems to have been fixed, I can't see the corruption anymore. I'm using
> Chromium 43.0.2357.81 on Ubuntu 14.04 (64-bit) and Mesa 10.7.0-devel
> (git-20dca37 2015-06-23 trusty-oibaf-ppa).
This is wrong, the bug surely hasn't been fixed. As Furkan says in #18, GPU acceleration was disabled in the Chromium package (ver 43.0.2357.81) in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1466670/ , the reason being "because GPU crashes (on Intel, Nvidia, and AMD) was the biggest cause of crash reports in all of Ubuntu"...

I'm also in for the tooltip corruption. I'd say it started around the time when chromium added/enabled aura/ash or what that custom OpenGL-based frontend is called. Though, I thought it's something specific to my machine. So it's not.

Anyway, encountering the issue on Mesa 10.7.0-devel (git-ad2c390). Most often if the height of the tooltip changes whilst the width keeps the same.

Reverting the commit mentioned in #1 (95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6), the problem is gone (or at least seems to).

About the way chromium seems to do it's tooltips: The tooltip view seems to get re-used all the time, just being resized/viewport adjusted. With apitrace one can find something like this
<snip>
44579 glDisable(cap = GL_SCISSOR_TEST)
44580 glScissor(x = 0, y = 0, width = 364, height = 38)
44581 glViewport(x = 0, y = 0, width = 370, height = 72)
<snap>
While the real tooltip is 364x38, the viewport image is 370x72. Thus the actual tooltip is in the lower left corner of the texture. Not quite sure about the precedence of scissor vs. viewport, but if the scissor test wouldn't get disabled, the texture should be clipped to the smaller size?

Anyway, reverting that particular commit results in ctx.Driver.Viewport being called on every glViewport call. For radeon that's going to be something like
.radeon_viewport(ctx)
..radeon_draw_buffer(ctx, radeon->glCtx.DrawBuffer);
...radeonUpdateScissor(ctx); << unconditionallly sets the correct texture size from glScissor call
...radeon->NewGLState |= _NEW_SCISSOR; << unconditionally requests scissor update
And then somewhere the draw with the correctly scissored texture happens and the tooltip gets properly displayed. I'm even not quite sure if radeon_draw_buffer() should unconditionally update the scissor?

Looks like an application error?

Just some more input

Debuggable with smth like 
`/usr/lib/chromium-browser/chrome --user-data-dir=/tmp/fake --no-sandbox --enable-gpu-debugging  --gpu-launcher="xterm -e gdb --args"` and break at gfx::NativeViewGLSurfaceGLX::Resize

531 bool NativeViewGLSurfaceGLX::Resize(const gfx::Size& size) {
532   size_ = size;
533   glXWaitGL();
534   XResizeWindow(g_display, window_, size.width(), size.height());
535   glXWaitX();
536   return true;
537 }

Is called for every tooltip. Looks like the tooltip xwindow is resized:
(gdb) x/2d $rsi
0x7fffffffc2f0: 221     21  ('New tab' tooltip 221x21)
(gdb) x/2d $rsi
0x7fffffffc2f0: 370     72  (chromium bug 442111 tooltip 370x72)

From the 'New tab' tooltip to chromium bug 442111 tooltip, the gl calls looks really wierd. The final tooltip should be 370x72, but the gl calls setup something from the old 112x21 tooltip plus the missing 51px to get to Xx72

100959 glUseProgram(program = 15)
100960 glDisable(cap = GL_SCISSOR_TEST)
100961 glScissor(x = 0, y = 51, width = 112, height = 21)
100962 glViewport(x = 0, y = 0, width = 59, height = 21)
100963 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
100965 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR)
100967 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_LINEAR)
100969 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_CLAMP_TO_EDGE)
100971 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_CLAMP_TO_EDGE)
100974 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
100977 glTexStorage2D(target = GL_TEXTURE_2D, levels = 1, internalformat = GL_RGBA8, width = 370, height = 72)
100980 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
100983 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0, yoffset = 0, width = 370, height = 72, format = GL_BGRA, type = GL_UNSIGNED_BYTE, pixels = blob(106560))
100987 glXWaitGL()
// right here the above ::Resize is called for the xwindow.. probably confusing Mesa?
100988 glXWaitX()

Iirc from my last post, radeon_draw_buffer() does re-evaluate window sizes. That's probably why the reverted commit makes things work again.

(In reply to Heiko from comment #35)
> Iirc from my last post, radeon_draw_buffer() does re-evaluate window sizes.
> That's probably why the reverted commit makes things work again.

Ken, do you think it's plausible that your commit causes problems with window resizes vs. glViewport calls?

(In reply to Heiko from comment #35)
> Just some more input
> 
> Debuggable with smth like 
> `/usr/lib/chromium-browser/chrome --user-data-dir=/tmp/fake --no-sandbox
> --enable-gpu-debugging  --gpu-launcher="xterm -e gdb --args"` and break at
> gfx::NativeViewGLSurfaceGLX::Resize
> 
> 531 bool NativeViewGLSurfaceGLX::Resize(const gfx::Size& size) {
> 532   size_ = size;
> 533   glXWaitGL();
> 534   XResizeWindow(g_display, window_, size.width(), size.height());
> 535   glXWaitX();
> 536   return true;
> 537 }
> 
> Is called for every tooltip. Looks like the tooltip xwindow is resized:
> (gdb) x/2d $rsi
> 0x7fffffffc2f0: 221     21  ('New tab' tooltip 221x21)
> (gdb) x/2d $rsi
> 0x7fffffffc2f0: 370     72  (chromium bug 442111 tooltip 370x72)
> 
> From the 'New tab' tooltip to chromium bug 442111 tooltip, the gl calls
> looks really wierd. The final tooltip should be 370x72, but the gl calls
> setup something from the old 112x21 tooltip plus the missing 51px to get to
> Xx72
> 
> 100959 glUseProgram(program = 15)
> 100960 glDisable(cap = GL_SCISSOR_TEST)
> 100961 glScissor(x = 0, y = 51, width = 112, height = 21)
> 100962 glViewport(x = 0, y = 0, width = 59, height = 21)
> 100963 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
> 100965 glTexParameteri(target = GL_TEXTURE_2D, pname =
> GL_TEXTURE_MIN_FILTER, param = GL_LINEAR)
> 100967 glTexParameteri(target = GL_TEXTURE_2D, pname =
> GL_TEXTURE_MAG_FILTER, param = GL_LINEAR)
> 100969 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S,
> param = GL_CLAMP_TO_EDGE)
> 100971 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T,
> param = GL_CLAMP_TO_EDGE)
> 100974 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
> 100977 glTexStorage2D(target = GL_TEXTURE_2D, levels = 1, internalformat =
> GL_RGBA8, width = 370, height = 72)
> 100980 glBindTexture(target = GL_TEXTURE_2D, texture = 145)
> 100983 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0,
> yoffset = 0, width = 370, height = 72, format = GL_BGRA, type =
> GL_UNSIGNED_BYTE, pixels = blob(106560))
> 100987 glXWaitGL()
> // right here the above ::Resize is called for the xwindow.. probably
> confusing Mesa?
> 100988 glXWaitX()
> 
> Iirc from my last post, radeon_draw_buffer() does re-evaluate window sizes.
> That's probably why the reverted commit makes things work again.

Can you make glXWaitX "re-evaluate window sizes"? That's the reason we call it - we just resized the window, we want to make sure we're drawing to the right back buffer. This is a UI workload, we may draw only once and we don't want flashing (what a glXSwapBuffers would do), so we want to make sure we're drawing to a buffer of the right size - glXWaitX is meant to synchronize GL with changes in X.

In this trace, you're only seeing parts of the calls - in particular there should be a glViewport and draws and a glXSwapBuffers after the resize.

I don't think there's confusion from the app side. Parts of what you're seeing is chromium restoring state between its "virtual contexts" (we have different subsystems that all need to access GL, and are multiplexed, possibly on a single GL context, depending on the version), so it's not necessarily surprising to see scissor/viewport that doesn't match the window size - until we get to actually draw the picture on screen. In particular, the texture is correctly loaded with 370x72, so no confusion there.

(In reply to Antoine Labour from comment #37)
> Can you make glXWaitX "re-evaluate window sizes"? That's the reason we call
> it - we just resized the window, we want to make sure we're drawing to the
> right back buffer. This is a UI workload, we may draw only once and we don't
> want flashing (what a glXSwapBuffers would do), so we want to make sure
> we're drawing to a buffer of the right size - glXWaitX is meant to
> synchronize GL with changes in X.
> 
> In this trace, you're only seeing parts of the calls - in particular there
> should be a glViewport and draws and a glXSwapBuffers after the resize.
> 
> I don't think there's confusion from the app side. Parts of what you're
> seeing is chromium restoring state between its "virtual contexts" (we have
> different subsystems that all need to access GL, and are multiplexed,
> possibly on a single GL context, depending on the version), so it's not
> necessarily surprising to see scissor/viewport that doesn't match the window
> size - until we get to actually draw the picture on screen. In particular,
> the texture is correctly loaded with 370x72, so no confusion there.

Well, most of my findings were pretty vague, because I'm neither a GL expert nor a mesa expert.

With your hint, I just noticed that dri2_wait_x()/dri2_wait_gl() don't do anything, because of priv->have_fake_front being zero all the time. It would be set to 1 for buffer attachments of __DRI_BUFFER_FAKE_FRONT_LEFT, but that's nowhere set in mesa. Thus gcc just optimized it away completely along with dri2_copy_drawable().

Seems to be related to [1]?


[1] http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html

(In reply to Heiko from comment #38)
> (In reply to Antoine Labour from comment #37)
> > Can you make glXWaitX "re-evaluate window sizes"? That's the reason we call
> > it - we just resized the window, we want to make sure we're drawing to the
> > right back buffer. This is a UI workload, we may draw only once and we don't
> > want flashing (what a glXSwapBuffers would do), so we want to make sure
> > we're drawing to a buffer of the right size - glXWaitX is meant to
> > synchronize GL with changes in X.
> > 
> > In this trace, you're only seeing parts of the calls - in particular there
> > should be a glViewport and draws and a glXSwapBuffers after the resize.
> > 
> > I don't think there's confusion from the app side. Parts of what you're
> > seeing is chromium restoring state between its "virtual contexts" (we have
> > different subsystems that all need to access GL, and are multiplexed,
> > possibly on a single GL context, depending on the version), so it's not
> > necessarily surprising to see scissor/viewport that doesn't match the window
> > size - until we get to actually draw the picture on screen. In particular,
> > the texture is correctly loaded with 370x72, so no confusion there.
> 
> Well, most of my findings were pretty vague, because I'm neither a GL expert
> nor a mesa expert.
> 
> With your hint, I just noticed that dri2_wait_x()/dri2_wait_gl() don't do
> anything, because of priv->have_fake_front being zero all the time. It would
> be set to 1 for buffer attachments of __DRI_BUFFER_FAKE_FRONT_LEFT, but
> that's nowhere set in mesa. Thus gcc just optimized it away completely along
> with dri2_copy_drawable().
> 
> Seems to be related to [1]?
> 
> 
> [1] http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html

Maybe, I'm not a DRI2 (or 3 or n) expert.

There is fundamentally a race between X and GL during resize, because the back buffer is supposed to be the same size as the window, but the window gets resized on the X server, whereas the back buffer is a property of the client and/or the GL stream. So, at some point, the client needs to take a "snapshot" of the window dimensions to operate, and problems come up if the window gets resized between the time the snapshot is taken and the time glXSwapBuffers occur. I think that's what's happening in this bug. It sounds like the referenced commit changes when the snapshot is taken.

From my quick reading of the radeon driver (sorry, I'm absolutely not familiar with the codebase), if I understand correctly, it looks like that snapshot is taken with the DRI2GetBuffer{,WithFormat}, via radeon_update_renderbuffers, which is called in a few places, notably in radeon_viewport, which was always called on every glViewport before http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6 , but after which is only called on non-redundant glViewport. radeon_update_renderbuffers is also called on radeonMakeCurrent, which is called on non-redundant glXMakeCurrent, and on radeon_prepare_render when dri2 stamps don't match which I think is meant to capture querying new buffers after glXSwapBuffers. There's a couple of other places too, but they may not matter for this.


So, I guess there could be a couple of workarounds in chrome to force radeon_update_renderbuffers (e.g. non-idempotent glViewport or glXMakeCurrent), but they're hacks. Or the driver could make sure it invalidates whatever is needed in glXWaitX, because that's what the user uses to synchronize between X and GL (i.e. you can assume that something in X has changed).

Created attachment 117445 [details] [review]
A naïve synchronization within dri2_wait_x.

Seems to workaround the issue.

Note, that Firefox also encountered issues with the X/GL synchronization [1]. They went to use XSync directly.

Additionally, could one extend 95073a2d with something like
-   if (ctx->Driver.Viewport) {
+   if (ctx->Driver.Viewport && (ctx->NewState & _NEW_VIEWPORT)) {
? At least doesn't blow up my machine...


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=687831

I'm adding Thomas and James to the list, since they may have some insight if this is relevant to their prior discussion (this link was posted in that Firefox bug report): http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html

Created attachment 117446 [details]
attachment-16123-0.html

Hi!

I'm on vacation and will be back on August 2nd 2015.

Thanks,
Thomas Hellstr?m

I see, the XResizeWindow would cause a DRI2 Invalidate event on the server side, and the XSync would make sure it's handled on the client before anything else happens. That seems like it would do the right thing (at the cost of a server round-trip).

(In reply to Antoine Labour from comment #43)
> I see, the XResizeWindow would cause a DRI2 Invalidate event on the server
> side, and the XSync would make sure it's handled on the client before
> anything else happens. That seems like it would do the right thing (at the
> cost of a server round-trip).

Well, from what I figured, chromium gets about 2-5 XExpose events per tooltip resizing after the XMapWindow call. As per XMapWindow manpage, the tooltip window seems to get tiled into the original region plus horizontal extension, plus vertical extension. Though, sometimes, there's additional XExpose for another horizontal extension of the tooltip. Thus you get 2-5 Calls into ::ScheduleRedrawRect and probably also 2-5 calls to glViewport (I bet that's the reason for the 'weird' values I found in apitrace). Also there are some XExpose events with send_event true. 

Would it be possible to build a single (damage_)rect (for a time slice) to get most or all parts of the tooltip into one draw call?

For the generic case: I thought one would need the round-trip to the server to make sure X and GL are in sync. Or what would be some other way; short sleep, some GL-Redraw? Not sure how the binary blobs handle this, but I bet they also call XSync/XFlush.

Alternatively,

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 5767026..01b5c28 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -656,6 +656,8 @@ dri2_wait_x(struct glx_context *gc)
    struct dri2_drawable *priv = (struct dri2_drawable *)
       GetGLXDRIDrawable(gc->currentDpy, gc->currentDrawable);
 
+   dri2InvalidateBuffers(gc->currentDpy, gc->currentDrawable);
+
    if (priv == NULL || !priv->have_fake_front)
       return;

I've tested both patches (#40 and #45) and they both seem to work for me.

Heiko, do you think you could send out your patch (with Chris' revision?) onto the mailing list? Perhaps it could be merged for 11.0.

I think Chris' patch is a superior replacement of Heiko's patch, not a revision of it. Chris, please submit your patch to the mesa-dev mailing list for review.

The patch has been on the mailing list since Aug. 10th but there's only one comment so far - is there anybody else who can pitch in?

http://lists.freedesktop.org/archives/mesa-dev/2015-August/091306.html

Since 11.0 was just released, would it be possible to have it included in the next point-release (11.0.1)?

It was brought to my attention on IRC that the proposed patch only fixes the issue with DRI2, but not DRI3. I tried applying the same fix to dri3_glx.c, but it doesn't seem to have any effect. Any ideas why? Or does it work for anybody else?

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 96f13e6..4676166 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -723,6 +723,9 @@ dri3_wait_x(struct glx_context *gc)
    struct dri3_screen *psc;
    struct dri3_buffer *front;
 
+   if (gc->currentDpy != NULL)
+      XSync(gc->currentDpy, False);
+
    if (priv == NULL || !priv->have_fake_front)
       return;

I'm on Fedora 22 x64 with Nouveau and I have this tooltip corruption in Chromium too. I hope that can be fixed.
Thank you

I don't know if you are aware but there is a similar bug in chromium that as been fixed.
https://code.google.com/p/chromium/issues/detail?id=442111

Created attachment 119519 [details]
attachment-31510-0.html

I'll be out of the office for the next 2-3 weeks.

For Vulkan issues, talk to Damien Leone (dleone@nvidia.com)

For EGL issues, talk to Daniel Kartch (dkartch@nvidia.com)

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Quoted from the Chromium bug report page:

"I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest build of chromium"

I don't know what that does, but it looks like a workaround.

(In reply to paviluf from comment #52)
> I don't know if you are aware but there is a similar bug in chromium that as
> been fixed.
> https://code.google.com/p/chromium/issues/detail?id=442111

Yeah, that bug cross-links here.

(In reply to Furkan from comment #54)
> Quoted from the Chromium bug report page:
> 
> "I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest
> build of chromium"
> 
> I don't know what that does, but it looks like a workaround.

enabling use_virtualized_gl_contexts was originally a workaround for some other drivers. We originally enabled it everywhere, but it uncovered this issue, so we disabled it on drivers that don't absolutely need it.

Whichever way you take it, various drivers from different vendors are inconsistent and we have to workaround some and/or others.

There will be a workaround in chromium and the Tooltips will work but something still need to be fixed in nouveau if I understand corrcectly ?

(In reply to paviluf from comment #57)
> There will be a workaround in chromium and the Tooltips will work but
> something still need to be fixed in nouveau if I understand corrcectly ?

Unfortunately chrome workarounds tend to be done incorrectly -- they look at the hw in the system, not the driver being used. (e.g. if you have intel + nvidia gpu, it'll enable all the nvidia workarounds despite the rendering happening all on intel, or that nouveau is used for the nvidia gpu).

I filed a bug about this a while back which has gotten no attention.

https://code.google.com/p/chromium/issues/detail?id=505969

I hope the bug you filed about this will have some attention.
https://code.google.com/p/chromium/issues/detail?id=505969

But you didn't said if something still need to be fixed in nouveau ;)

Has this been resolved for anybody? I'm running Xorg 1.18.2 and Mesa 11.2rc3. I still get the same corruption, with both DRI2 and DRI3.

Created attachment 122573 [details]
attachment-20584-0.html

I'm on paternity leave from January 25th - April 15th.

While I'm out, please contact the following people:

linux-bugs@nvidia.com for Linux graphics bug triage issues

Damien Leone (dleone 'at' nvidia.com) for Linux Vulkan WSI issues

Jeff Juliano (jjuliano 'at' nvidia.com) for Windows Vulkan WSI issues

Daniel Kartch (dkartch 'at' nvidia.com) for EGL issues

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

 I'm still getting these tooltip rendering issue in with mesa 11.1.2 and chromium-browser 49.0.2623.87.
 I'd fix this myself but I have no idea what the problem is. I'm not sure if the problem lies with MESA and is just exposed by Chromium or if this is really Chromium doing something incorrectly.

I still have this problem. I often see part of the previous tooltip.

Chrome 51
Fedora 24
Kernel 4.6.3
Nouveau driver

The good news is that this bug have been fixed but I don't know in what Chrome release it will be.

https://code.google.com/p/chromium/issues/detail?id=505969

I'm seeing it too:

Chrome 51.0.2704.84
Ubuntu 16.04
Kernel 4.6.2
Mesa   12.1~git1606270730.d20b89~gd~t (oibaf)
radeonsi (r9 390x)

Created attachment 124924 [details]
attachment-26000-0.html

Hi!

I'm on vacation and will be back on Monday August 8. For vmware linux graphics driver issues, please contact
<linux-graphics-maintainer@vmware.com>

Thanks,
Thomas Hellstr?m

I have this issue as well, I'm on Arch Linux (x86-64).

mesa 12.0.1-2
xorg-server 1.18.4-1
linux 4.6.4-1

Using modesetting here, ThinkPad T450 (broadwell i5-5300U).

(In reply to Diego Viola from comment #66)
> I have this issue as well, I'm on Arch Linux (x86-64).
> 
> mesa 12.0.1-2
> xorg-server 1.18.4-1
> linux 4.6.4-1
> 
> Using modesetting here, ThinkPad T450 (broadwell i5-5300U).

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

For what it's worth, I installed AMDGPU-PRO today, and the problem went away.

(In reply to Furkan from comment #68)
> For what it's worth, I installed AMDGPU-PRO today, and the problem went away.

That's a completely different OpenGL driver.

FWIW, https://patchwork.freedesktop.org/patch/117379/ fixes half of this for me with DRI3: The tooltips are no longer corrupted when moving the cursor from a tab with a single-line tooltip to a tab with a multi-line one. However, when going in the opposite direction, the single-line tooltip still shows stale contents from the multi-line tooltip.

I applied patches in #45 and #50, no more tooltip corruption in Chrome.

GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) Sandybridge Desktop
GL_VERSION	3.3 (Core Profile) Mesa 13.0.4

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
VPx Video Decode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Driver Bug Workarounds
adjust_src_dst_region_for_blitframebuffer
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
decode_encode_srgb_for_generatemipmap
disable_framebuffer_cmaa
disable_post_sub_buffers_for_onscreen_surfaces
msaa_is_slow
remove_invariant_and_centroid_for_essl3
scalarize_vec_and_mat_constructor_args

Problems Detected
Accelerated video decode is unavailable on Linux: 137247
 - Disabled Features: accelerated_video_decode
Clear uniforms before first program use on all platforms: 124764, 349137
 - Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
 - Applied Workarounds: count_all_in_varyings_packing
Disable partial swaps on Mesa drivers (detected with GL_RENDERER): 339493
 - Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Always rewrite vec/mat constructors to be consistent: 398694
 - Applied Workarounds: scalarize_vec_and_mat_constructor_args
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
 - Applied Workarounds: msaa_is_slow
Timer queries crash on Intel GPUs on Linux: 540543, 576991
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
 - Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
 - Decode and encode before generateMipmap for srgb format textures on os except macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
 - adjust src/dst region if blitting pixels outside read framebuffer on Linux Intel: 664740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
 - Mesa driver GL 3.3 requires invariant and centroid to match between shaders: 639760, 641129
Applied Workarounds: remove_invariant_and_centroid_for_essl3
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Accelerated rasterization has been disabled, either via blacklist, about:flags or the command line.
 - Disabled Features: rasterization
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
 - Disabled Features: native_gpu_memory_buffers

Created attachment 130930 [details] [review]
DRI2 fixed for me; not DRI3 though  (chromium tooltip corruption tested on youtube videos)

as the comment above, fixed for me but only for DRI2. Patch attached.(&confirmed to fail without patch)

Does anyone know what's the equivalent of that XSync in DRI3 speak?

+   if (gc->currentDpy != NULL)
+      XSync(gc->currentDpy, False);

I can give more info & test any patches, if anyone's willing and has the time...

Cheers.


Chromium	59.0.3068.0
mesa 17.0.4-2 (in Arch Linux)
GL_VENDOR	X.Org
GL_RENDERER	Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-rc7-g4f7d029b9bf0, LLVM 3.9.1)
GL_VERSION	3.3 (Core Profile) Mesa 17.0.4

I'm still seeing this with Mesa 17.1.0rc2 and xf86-video-intel from git 2017-04-18 	c72bb27a3a68ecc616ce2dc8e9a1d20354504562 on Skylake with DRI3 and xorg-server 1.19.3.

For a while, I'd been using the 3 patches from this series:
https://patchwork.freedesktop.org/patch/117379/

but they never fixed the Chrome tooltip corruption issue with DRI3, and it looks like that series never got pushed to Mesa.

(In reply to Joseph Yasi from comment #73)
> I'm still seeing this with Mesa 17.1.0rc2 and xf86-video-intel from git
> 2017-04-18 	c72bb27a3a68ecc616ce2dc8e9a1d20354504562 on Skylake with DRI3
> and xorg-server 1.19.3.
> 
> For a while, I'd been using the 3 patches from this series:
> https://patchwork.freedesktop.org/patch/117379/
> 
> but they never fixed the Chrome tooltip corruption issue with DRI3, and it
> looks like that series never got pushed to Mesa.

I'm also seeing it on Ivy Bridge and Broadwell graphics with mesa 17.0.4 and xf86-video-intel 2.99.917+772+gc72bb27a

I still have the problem on Fedora 25 and Intel GPU. This problem affect other softwares that are based on electron like VS Code.

https://github.com/Microsoft/vscode/issues/23946

This problem happens when a tooltip was previously shown with a multi-line content and the current tooltip has smaller number of lines than the previous one. Check this topic for detailed explanation: https://www.kubuntuforums.net/showthread.php?t=71878

It's like the placement of the drawn element is calculated according to the previous tooltip size (aligned to the bottom).

Thank you, omerfarukdogan95@hotmail.com.

I could reproduce this problem in Chrome and tried to capture it in this video:

https://www.useloom.com/share/14090a28f6d64fb6a4ba74056aac14f5

Does the problem have to be addressed in Chrome and Chromium?

Sorry, I shared the wrong link to the video in my previous comment:

https://youtu.be/3mXXnlwrXm0

Have the same issue with the tabs.

Chromium 59.0.3071.104
Mesa 13.0.6
Kernel amd64 4.11.6-1

All as packaged by Debian (Debian Testing).

Here is the output of chrome://gpu https://pastebin.com/WPEp71Mk

It seem that will be "fixed" soon in chromium. They will disable compositing for tooltips on Linux. I still hope that the root of the bug will be fixed in mesa.

https://bugs.chromium.org/p/chromium/issues/detail?id=442111

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/988.