Bug 91558 - With SNA, tabs are not always redrawn in Chrome when switching tabs
Summary: With SNA, tabs are not always redrawn in Chrome when switching tabs
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-04 18:14 UTC by Julian Andres Klode
Modified: 2016-01-24 16:08 UTC (History)
18 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Chrome GPU information (37.78 KB, text/html)
2015-08-04 18:16 UTC, Julian Andres Klode
no flags Details
X Log with UXA (57.56 KB, text/plain)
2015-08-05 09:16 UTC, Julian Andres Klode
no flags Details
X Log with SNA (21.95 KB, text/plain)
2015-08-05 09:16 UTC, Julian Andres Klode
no flags Details
Xorg.log.gz (234.88 KB, application/gzip)
2015-08-12 00:04 UTC, Vasily Khoruzhick
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Andres Klode 2015-08-04 18:14:21 UTC
With SNA in 2.99.917, Chrome does not redraw its tabs correctly when switching tabs. Switching to UXA seems to fix the issue.

Here's a picture of a failed redraw, and a video showing it in action:

https://goo.gl/photos/k6nxDK9Ep4GRc8RV9
Comment 1 Julian Andres Klode 2015-08-04 18:16:34 UTC
Created attachment 117530 [details]
Chrome GPU information

This is the output of Chrome's chrome://gpu page, for reference.

I also reported the issue at the chromium bug tracker, at:

https://code.google.com/p/chromium/issues/detail?id=516679
Comment 2 Chris Wilson 2015-08-05 07:49:32 UTC
Your Xorg.0.log is vital here. As would also confirming this with xf86-video-intel.git.
Comment 3 Julian Andres Klode 2015-08-05 09:16:21 UTC
Created attachment 117536 [details]
X Log with UXA
Comment 4 Julian Andres Klode 2015-08-05 09:16:35 UTC
Created attachment 117537 [details]
X Log with SNA
Comment 5 Julian Andres Klode 2015-08-05 09:19:10 UTC
I added the Xorg log files, one for SNA and one for UXA. They do not report any issues, though.

I'll see if I can check with current git, but things are a bit problematic right now, as Debian is undergoing the libstdc++ transition and I might thus not be able to build things, because my chroot might not be able to install needed build dependencies.
Comment 6 Julian Andres Klode 2015-08-05 10:11:44 UTC
I can reproduce it on current git.
Comment 7 Chris Wilson 2015-08-05 10:17:56 UTC
Looks like a bog standard gnome-shell setup, right? I hope debian closely matches fedora...

One more useful task would be to run with --enable-debug=pixmap (and confirm that Xorg.0.log reports the extra assertions) and see if any fire.
Comment 8 Julian Andres Klode 2015-08-05 10:43:18 UTC
--enable-debug=pixmap did not show anything new in the Xorg log.
Comment 9 Chris Wilson 2015-08-05 10:51:04 UTC
You should see confirmation in the ./configure summary, and then in the log:

"SNA compiled with assertions enabled"
"SNA compiled with extra pixmap/damage validation"
Comment 10 Julian Andres Klode 2015-08-05 10:54:18 UTC
Yeah, it's showing 

[168524.947] (II) intel(0): SNA compiled with extra pixmap/damage validation

but there's no error messages or anything else new coming after the initial set-up.

So, this does not seem to be caught by those assertions.
Comment 11 Julian Andres Klode 2015-08-05 10:54:32 UTC
And yes, it should be relatively standard GNOME Shell 3.16.

For further reference, here are the versions of reverse dependencies of the intel driver.

ii  libc6                                  2.19-19
ii  libdrm-intel1                          2.4.62-1
ii  libdrm2                                2.4.62-1
ii  libpciaccess0                          0.13.4-1
ii  libpixman-1-0                          0.32.6-3
ii  libudev1                               224-1
ii  libx11-6                               2:1.6.3-1
ii  libx11-xcb1                            2:1.6.3-1
ii  libxcb-dri2-0                          1.10-3+b1
ii  libxcb-dri3-0                          1.10-3+b1
ii  libxcb-sync1                           1.10-3+b1
ii  libxcb-util0                           0.3.8-3
ii  libxcb1                                1.10-3+b1
ii  libxcursor1                            1:1.1.14-1+b1
ii  libxdamage1                            1:1.1.4-2+b1
ii  libxext6                               2:1.3.3-1
ii  libxfixes3                             1:5.0.1-2+b2
ii  libxinerama1                           2:1.1.3-1+b1
ii  libxrandr2                             2:1.5.0-1
ii  libxrender1                            1:0.9.8-1+b1
ii  libxshmfence1                          1.2-1
ii  libxtst6                               2:1.2.2-1+b1
ii  libxv1                                 2:1.0.10-1+b1
ii  libxvmc1                               2:1.0.9-1
ii  xserver-xorg-core [xorg-video-abi-19]  2:1.17.2-1
Comment 12 Binyamin Sagal 2015-08-05 10:57:53 UTC
Having the same problem with Kwin 4.11.19 on gentoo
Comment 13 Chris Wilson 2015-08-05 16:58:43 UTC
I've tried on several different computers to reproduce this, and have not. Considering that the bug will be the damage tracking going awry it is going to involve WM + timing. Do you have steps that can reliably reproduce it?
Comment 14 Julian Andres Klode 2015-08-06 15:11:29 UTC
It seems to involve some sort of race, so it's not reliably debuggable. It sometimes took me up two 5 minutes of switching between tabs (just two tabs next to each other) by keyboard to reproduce this (clicking on the tabs does not seem to cause it).

I might check in Fedora 22 soon, I'm currently downloading a live image.
Comment 15 Julian Andres Klode 2015-08-06 16:21:17 UTC
I did not have much time to check in Fedora, but on a first glance, there are no problems at all. Neither this, nor another Chrome rendering bug I experience on Debian (that one is not UXA/SNA related though):

https://code.google.com/p/chromium/issues/detail?id=516756
Comment 16 Julian Andres Klode 2015-08-06 16:45:28 UTC
I also could not reproduce it under metacity, but that was only a very quick dry, so it might simply not have occured yet.

I could reproduce the window resizing bug I mentioned in the previous comment under metacity with compositing enabled, though.

So it seems like this may be a special combination of dependencies in Debian causing the issue (versions and/or patches).
Comment 17 Vasily Khoruzhick 2015-08-06 17:30:14 UTC
I'm hitting it on Archlinux on gnome-shell (3.16) and kde (plasma 5), on Ivy Bridge and Broadwell hardware, in single and multi-monitor configurations. This bug has been here for a while, two month or so, but with recent chromium releases it became even worse. Chris, what chromium version are you running?
Comment 18 Felipe Sateler 2015-08-06 17:58:33 UTC
I am having the same issue. This system is debian sid, with kde plasma 5, so it appears it is not a problem with metacity.
Comment 19 Hemant Kumar 2015-08-07 14:51:05 UTC
I was seeing this problem with Gnome 3.16 and Chrome using Intel Drivers and my conclusion is this is somehow indeed related to Window manager.

As a workaround, try selecting "Use System title bar and Border" in chrome settings and see if this problem goes away. For me that fixed the problem.
Comment 20 Mark B 2015-08-11 06:52:01 UTC
I am seeing this on Arch Linux (x64) as well. I update my systems daily and starting seeing this bug somewhere between 13th to 23rd July on both my Broadwell laptop and Ivy Bridge PC. Looking at my update log, I believe it could be any of the following:

[2015-07-13 00:09] [ALPM] upgraded mesa (10.6.1-1 -> 10.6.2-1)
[2015-07-16 08:22] [ALPM] upgraded chromium (43.0.2357.132-1 -> 43.0.2357.134-1)
[2015-07-16 08:22] [ALPM] upgraded xorg-server (1.17.2-2 -> 1.17.2-3)
[2015-07-18 10:05] [ALPM] upgraded xorg-server (1.17.2-3 -> 1.17.2-4)
[2015-07-22 21:35] [ALPM] upgraded xf86-video-intel (1:2.99.917+364+gb24e758-1 -> 1:2.99.917+381+g5772556-1)
[2015-07-23 08:31] [ALPM] upgraded chromium (43.0.2357.134-1 -> 44.0.2403.89-1)

I don't like using UXA because I lose smooth gnome-shell overview animation so with SNA I am seeing this bug many times per day.
Comment 21 Vasily Khoruzhick 2015-08-12 00:04:46 UTC
Created attachment 117632 [details]
Xorg.log.gz

Here's Xorg log with --enable-debug=full. Repaint failure happened around 16:59:30-17:00:53
Comment 22 Hemant Kumar 2015-08-21 12:52:33 UTC
(In reply to Hemant Kumar from comment #19)
> I was seeing this problem with Gnome 3.16 and Chrome using Intel Drivers and
> my conclusion is this is somehow indeed related to Window manager.
> 
> As a workaround, try selecting "Use System title bar and Border" in chrome
> settings and see if this problem goes away. For me that fixed the problem.

While using "System title bar and Border" fixes redrawing problem, it causes another weird problem which is - whenever I exit a full screen video, Chrome hangs completely (although not always). I will try to grab some logs of when this happens and post it here.
Comment 23 Vasily Khoruzhick 2015-08-25 19:14:49 UTC
https://www.dropbox.com/s/t54yai92gq86621/Xorg.0.log.bz2?dl=0

Issue happened around 27758 +- 5 secs
Comment 24 Vasily Khoruzhick 2015-08-25 20:05:38 UTC
To reproduce this issue I opened/switch/closed chromium tabs. Issue happened during a tab switch, chromium indicated it switched to new tab by highlighting tab header, but content of old tab still remained on the screen. After some time (1-1.5s) redraw happened.

I've noticed that it's enough to switch workspaces or enter gnome-shell overview mode to force chromium redraw.
Comment 25 Vasily Khoruzhick 2015-08-28 18:02:26 UTC
For gnome it's possible to workaround the issue by adding "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" to your environment variables (for archlinux it's /etc/environment)
Comment 26 Mark B 2015-08-31 00:03:53 UTC
@Vasily re comment #25, that definitely stops the problem, unlike the use "system title bar and borders" option which makes no difference. What disadvantage/compromise does this CLUTTER_PAINT workaround impose? I've not noticed anything.
Comment 27 Vasily Khoruzhick 2015-08-31 17:25:37 UTC
@Mark B, as far as I understand it disables partial repaints, so it may result in worse performance and/or higher power consumption.
Comment 28 Ondrej Sury 2015-09-18 11:37:41 UTC
I can confirm the bug on latest Debian testing/stretch on Core M

Chromium 45.0.2454.85-1 (45.0.2454.85-1)
xserver-xorg 1.17.2 (xserver-xorg-core 2:1.17.2-1.1)
mesa 10.6.3 (10.6.3-1)
xserver-xorg-video-intel 2.99.917 (2:2.99.917-2)

and I can reproduce both with Chromium and Chrome.

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 181d
	Flags: bus master, fast devsel, latency 0, IRQ 49
	Memory at f6000000 (64-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
Comment 29 Vasily Khoruzhick 2015-09-19 03:01:12 UTC
For KDE one can use "Tearing prevention ("vsync")" = "Full screen repaints" in "Display & Monitor -> Compositor settings" as a workaround
Comment 30 hello 2015-09-19 11:45:28 UTC
On arch (gnome 3.16), the CLUTTER_PAINT solution stops partial repainting but causes the entire window not to repaint. The only solution for me is to not maximize chrome.
Comment 31 justinmichaelholmes 2015-11-23 22:41:07 UTC
+1 on Comment 25. This solves the issue for me on Fedora 23. Thank you very much!
Comment 32 Julien HENRY 2015-12-02 07:29:32 UTC
+1 for comment #29 works for me on Fedora 23
Comment 33 Robert de Rooy 2015-12-17 12:09:11 UTC
As reported @ https://code.google.com/p/chromium/issues/detail?id=516679

Starting Chrome 47 with --use-virtualized_gl_contexts=0 prevents the issue from occurring.

In Chrome 48 they added a patch to prevent Virtualized GL contexts on non-nvidia GPUs. https://code.google.com/p/chromium/issues/detail?id=514510#c37
Comment 34 Roland Pallai 2016-01-24 16:08:03 UTC
I am experiencing this issue, but the problems are not limited to Chrome. For example, 2 glxgears does not work at the same time, one shows a blank window or still picture meanwhile reports high FPS rates at the console output.

I have tried the following workarounds without success:
- set CLUTTER_PAINT
- kwin "Full screen repaints"
- Chrome 47 with --use-virtualized_gl_contexts=0
- Chrome 48

with success:
- suspend composition on Plasma (alt+shift+f12)
- fall back to UXA

i3-4160 CPU, Fedora 22, Plasma Desktop. 100% reproducible.

UXA definitely fixes every glitches with XGL applications.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.