GNOME Bugzilla – Bug 711028
Tearing on Intel GPU - the CLUTTER_PAINT workaround
Last modified: 2014-09-17 19:00:15 UTC
Fedora x86_64, confirmed on Fedora 19 through 20 TC1 with Gnome Shell 3.10. Thinkpad T500 Additional info: Tested on Fedora 19 installed and updated yesterday but all of logs/tests/videos come from Live Fedora 19 made of Fedora-Live-Desktop-x86_64-19-TC6-1.iso [liveuser@localhost ~]$ uname -a Linux localhost 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [liveuser@localhost ~]$ glxinfo | grep rendere OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset [liveuser@localhost ~]$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Displays: Only one - the internal laptop display. Exactly asd described here https://bbs.archlinux.org/viewtopic.php?id=118441&p=2 adding the following two lines to /etc/environment: CLUTTER_PAINT=disable-clipped-redraws:disable-culling CLUTTER_VBLANK=True reduces/eliminates the tearing. However:"It makes the desktop strangely laggy. When I drag a window it always takes a moment to catch up with the mouse." Another forum topic: http://forums.fedoraforum.org/showthread.php?p=1541466#post1541466 Videos here: https://bugzilla.redhat.com/show_bug.cgi?id=977391#c1 This is a well known pet-bug so please refer to the videos only if you really have to.
The "additional info" section is a copy/paste from my other bug report (redhat, 977391) and I forgot to correct some bits: "19 installed and updated yesterday" should be "19 installed and updated on 2013-06-23" Fedora 20 TC1 is not the last version that exhibits the issue. I just gave up on the issue then.
This is a known issue see bug 669122 (and already fixed from a gnome-shell / mutter POV). Basically the thing is when something changes on the screen only try to only redraw those parts to both improve performance and lower power consumption (that's what clipped redraws and culling is about). This sub screen updates have limited vsync support but its a "best effort" approach i.e it does not guarantee no tearing. To fix this a new GLX/EGL extension (buffer_age) has been introduced which we use since 3.8. So why do you still get tearing? Because unfortunately the extension cannot be supported by a DRI2 driver under X11. This limitation will be removed in DRI3 which will give us the buffer_age extension on open source drivers under X. (DRI3 is expected to ship with xserver-1.15) Under wayland we have the buffer_age extension so no tearing there. > However:"It makes the desktop strangely laggy. When I drag a window it always takes a moment to catch up with the mouse." You are forcing full stage redraws i.e always drawing the whole screen for every update. This is expected to be slower.
(In reply to comment #2) > So why do you still get tearing? Because unfortunately the > extension cannot be supported by a DRI2 driver under X11. This limitation will > be removed in DRI3 which will give us the buffer_age extension on open source > drivers under X. (DRI3 is expected to ship with xserver-1.15) So basically I will see this fixed when xserver-1.15 lands in Fedora. Understood. http://www.phoronix.com/scan.php?page=news_item&px=MTUwMDY BTW, I know that end-user experience is not a priority in Linux but don't you think it was a bit too much? Bringing desktop experience for many users to a miserable state, for a year, because some guy had a problem with 'a hardcoded value'. Adjust your freaking priorities, will you?
(In reply to comment #3) > (In reply to comment #2) > > So why do you still get tearing? Because unfortunately the > > extension cannot be supported by a DRI2 driver under X11. This limitation will > > be removed in DRI3 which will give us the buffer_age extension on open source > > drivers under X. (DRI3 is expected to ship with xserver-1.15) > > So basically I will see this fixed when xserver-1.15 lands in Fedora. > Understood. And a mesa version that take advantaged of it. > > BTW, I know that end-user experience is not a priority in Linux but don't you > think it was a bit too much? Bringing desktop experience for many users to a > miserable state, for a year, because some guy had a problem with 'a hardcoded > value'. Adjust your freaking priorities, will you? This is sheer nonsense. Older Intel hardware (up to gen5) had a hardware feature that was used by the intel driver to prevent tearing in pretty much all case. Unfortunately the hardware designers removed it (don't ask my why I don't know). There is no magic "hardcoded value" that makes your system tear no idea why where you got that from. As for our priorities as you can see in the other bug I worked on implementing the fix; Robert come up with the extension we need for the fix. We had some discussions with NVIDIA to clarify the extension language. The extension is now supported by their driver, fglrx and open source drivers on wayland. It does not work on DRI2 with X11 ... as you can see Keith has been working on addressing that. Stuff like that does not happen over night. Attacking people on bugzilla wont make your problem magically go away, so while I understand your frustration this is not helpful.
(In reply to comment #4) > There is no magic "hardcoded value" that makes your system tear no idea > why where you got that from. From the bug description https://bugzilla.gnome.org/show_bug.cgi?id=669122 But it doesn't really matter. It's beyond my capabilities to tell who has introduced the regression. For a simpleton like me it's like "It used to work in Fedora 17 and it doesn't now, since Q1 2013. And it took a year to fix the damn thing!". Whoever is responsible for this makes people advocating for Linux look like fools and this is the sole reason I went 'rant mode'. > Attacking people on bugzilla wont make your problem magically go away, so while > I understand your frustration this is not helpful. I know, but this was the worst *up since the infamous Linux kernel power regressions galore of 2011 (2.6+). OK, no more ranting. I only wish you guys took more caution while fiddling with what works already/communicate better with the Intel devs. Can I provide any additional info to make up for the rant? :)
Created attachment 259135 [details] My system info.
> Older Intel hardware (up to gen5) had a hardware > feature that was used by the intel driver to prevent tearing in pretty much all > case. As you see I've edited the bug title because according to this resource my hardware is not of Sandy Bridge generation. It's GM45 so Gen4. Does it change anything regarding this particular bug report and tearing on Intel in general?
May I ask for an update on the situation? Most importantly, are we stuck with tearing until Gnome 3.14/Wayland? I've tested it again with various tweak combinations (+defaults) to no avail, running: xorg-server-1.15.0-5 mesa 10.0.3-1 xf86-video-intel 2.99.910-1 intel-dri 10.0.3-1 It would also be great if new official recommendations were provided as to tweaks users can apply as a workaround. Right now the Internet is full of tweaks which are supposed to address the problem. I'm talking about: [1]clutter tweaks file: /etc/environment CLUTTER_PAINT=disable-clipped-redraws:disable-culling CLUTTER_VBLANK=True [2]xorg tweaks (the ones below are for intel graphics) file: /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "TearFree" "true" Option "SwapbuffersWait" "true" Option "AccelMethod" "sna" EndSection note 1: issue still also present on older gen Intel graphics, e.g. Gen 4 note 2: the CLUTTER_PAINT workaround does not restore the performance/smoothness from before the issue started biting
(In reply to comment #8) > May I ask for an update on the situation? Yes. > Most importantly, are we stuck with > tearing until Gnome 3.14/Wayland? No. > I've tested it again with various tweak combinations (+defaults) to no avail, > running: > xorg-server-1.15.0-5 > mesa 10.0.3-1 > xf86-video-intel 2.99.910-1 > intel-dri 10.0.3-1 If you are really into "tweaking" you can get it working by building stuff by yourself. To get buffer_age working with intel drivers you would need: 1. xserver 1.15 (which you already have) 2. mesa 10.1 + the patches from http://thread.gmane.org/gmane.comp.video.mesa3d.devel/73553 3. xf86-video-intel from that branch: http://cgit.freedesktop.org/~keithp/xf86-video-intel/log/?h=dri3 4. That https://git.gnome.org/browse/clutter/commit/?h=clutter-1.16&id=6665f47d66a871b6e1a5f4200282f42da043a0e8 clutter patch
The tearing is still present on Gen4 non-SB graphics with the following stack: # pacman -Q | egrep '^mesa|intel|clutter ' clutter 1.16.4-3 intel-dri-git 62265.a22d944-1 lib32-intel-dri 10.1.0-4 mesa-git 62265.a22d944-1 mesa-libgl-git 62265.a22d944-1 xf86-video-intel-dri3-git 7820.6caf295-1 Tested on Arch.
(In reply to comment #10) > The tearing is still present on Gen4 You cannot get tearing on gen4 ever, are you using multiple monitors? > non-SB graphics SB is gen6 ... Can you attach glxinfo and lspci output?
(In reply to comment #11) > You cannot get tearing on gen4 ever, are you using multiple monitors? I stated that my graphics is gen4 long time ago. No, I'm using single notebook display. > Can you attach glxinfo and lspci output? Already attached to the bug report: https://bugzilla.gnome.org/attachment.cgi?id=259135
Created attachment 274034 [details] System info, april 2014
(In reply to comment #12) > (In reply to comment #11) > > You cannot get tearing on gen4 ever, are you using multiple monitors? > I stated that my graphics is gen4 long time ago. No, I'm using single notebook > display. > That's odd can you run with CLUTTER_DEBUG=clipping gnome-shell --replace > debug.txt 2<&1 and attach the debug.txt ?
(In reply to comment #14) > That's odd can you run with CLUTTER_DEBUG=clipping gnome-shell --replace > > debug.txt 2<&1 and attach the debug.txt ? I've added the line to /etc/environment and logged out / in. Can't seem to locate the debug.txt. Also, is the '2<&1' intended or just a 'typo'?
(In reply to comment #15) > (In reply to comment #14) > > That's odd can you run with CLUTTER_DEBUG=clipping gnome-shell --replace > > > debug.txt 2<&1 and attach the debug.txt ? > I've added the line to /etc/environment and logged out / in. Can't seem to > locate the debug.txt. Also, is the '2<&1' intended or just a 'typo'? You are supposed to type that command in a terminal i.e open gnome-terminal paste CLUTTER_DEBUG=clipping gnome-shell --replace > debug.txt 2<&1 press enter. The "2<&1" is not a typo it merges stdout and stderr into one stream that gets redirected to debug.txt
(In reply to comment #16) > CLUTTER_DEBUG=clipping gnome-shell --replace > debug.txt 2<&1 As non-root: permission denied As a root: Failed to connect to session bus: The connection is closed
(In reply to comment #17) > (In reply to comment #16) > > CLUTTER_DEBUG=clipping gnome-shell --replace > debug.txt 2<&1 > > As non-root: permission denied You need to do it while in a folder where you have write access like your home directory ... alternatively use ~/debug.txt instead of debug.txt and the file will end up in your home directory. > As a root: Failed to connect to session bus: The connection is closed Don't do that.
OK, got it. But the command didn't 'end' I had to use Ctrl+C to terminate it. The contents of debug.txt doesn't seem to be relevant: Gjs-Message: JS LOG: GNOME Shell started at Thu Apr 10 2014 23:24:42 GMT+0200 (CEST) Window manager warning: Log level 16: Could not initialize NMClient /org/freedesktop/NetworkManager: Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory. Window manager warning: Log level 16: fetch_connections_done: error fetching connections: (32) Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory.. Do I need to install NetworkManager for the debug command to succeed?
(In reply to comment #19) > OK, got it. But the command didn't 'end' I had to use Ctrl+C to terminate it. > The contents of debug.txt doesn't seem to be relevant: > Gjs-Message: JS LOG: GNOME Shell started at Thu Apr 10 2014 23:24:42 GMT+0200 > (CEST) > Window manager warning: Log level 16: Could not initialize NMClient > /org/freedesktop/NetworkManager: Unit > dbus-org.freedesktop.NetworkManager.service failed to load: No such file or > directory. > Window manager warning: Log level 16: fetch_connections_done: error fetching > connections: (32) Unit dbus-org.freedesktop.NetworkManager.service failed to > load: No such file or directory.. > > Do I need to install NetworkManager for the debug command to succeed? No looks like your clutter is built with debug disabled. Are you running sna or uxa? Does changing this make any difference? Also please file a driver bug at bugzilla.freedesktop.org
(In reply to comment #20) > Are you running sna or > uxa? Does changing this make any difference? UXA. Changing to SNA doesn't make a difference. > Also please file a driver bug at bugzilla.freedesktop.org You said gen4 will never be tear-free. I will file a bug report but could you perhaps briefly explain what's the point in such a case? BTW, after installing and configuring NetworkManager I got the following debug output: Gjs-Message: JS LOG: GNOME Shell started at Fri Apr 11 2014 18:48:54 GMT+0200 (CEST) Window manager warning: last_focus_time (145656) is greater than comparison timestamp (145655). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... Window manager warning: Log level 16: STACK_OP_RAISE_ABOVE: sibling window 0x1400009 not in stack Window manager warning: Log level 16: STACK_OP_LOWER_BELOW: sibling window 0x1400009 not in stack
(In reply to comment #21) > (In reply to comment #20) > > Are you running sna or > > uxa? Does changing this make any difference? > UXA. Changing to SNA doesn't make a difference. > > > Also please file a driver bug at bugzilla.freedesktop.org > You said gen4 will never be tear-free. No ... I said it should *always be tear free* ... that's a very big difference i.e we shouldn't have to had this discussion at all. I in fact cannot reproduce any tearing on GM45 ... > I will file a bug report but could you > perhaps briefly explain what's the point in such a case? Because it does not suppose to tear ever because the hardware is set up (by the driver) in a way that prevents that. Are you sure that tearing is what you are experiencing? > BTW, after installing and configuring NetworkManager [...] This has nothing to do with NM.
(In reply to comment #22) > No ... I said it should *always be tear free* ... that's a very big difference > i.e we shouldn't have to had this discussion at all. I in fact cannot reproduce > any tearing on GM45 ... My bad! Please consider that resolution may be a factor. If I reduce it to 800x600 the tearing is greatly reduced. > Are you sure that tearing is what you are experiencing? Pretty sure, yes. Most notably the CLUTTER_PAINT workaround did bring an improvement on my system* (not only for video tearing but for desktop tearing as well). That said it's not as easy to prove tearing like it is in games. If there's a desktop method for that, please tell me. I haven't heard of anything like that apart from high-speed cameras. What I actually see I can describe as animations with frame rate reduced at least 3 times combined with some elements of moving windows (in Activities) drawn behind them for a blink of an eye. I've uploaded two new videos, one recorded with my discrete ATI and one with integrated Intel GM45. Please disregard the inherent limitations of such recording and rather focus your attention on the difference, especially when exiting Activities is shown. https://onedrive.live.com/redir?resid=66CF2646234394FC!2536&authkey=!APhX4WS4a7HN1zE&ithint=folder%2c.mp4 *it stopped making any difference only recently on my system.
(In reply to comment #23) > (In reply to comment #22) > > No ... I said it should *always be tear free* ... that's a very big difference > > i.e we shouldn't have to had this discussion at all. I in fact cannot reproduce > > any tearing on GM45 ... > My bad! > Please consider that resolution may be a factor. If I reduce it to 800x600 the > tearing is greatly reduced. > > > Are you sure that tearing is what you are experiencing? > Pretty sure, yes. Most notably the CLUTTER_PAINT workaround did bring an > improvement on my system* (not only for video tearing but for desktop tearing > as well). > That said it's not as easy to prove tearing like it is in games. If there's a > desktop method for that, please tell me. I haven't heard of anything like that > apart from high-speed cameras. > > What I actually see I can describe as animations with frame rate reduced at > least 3 times combined with some elements of moving windows (in Activities) > drawn behind them for a blink of an eye. I've uploaded two new videos, one > recorded with my discrete ATI and one with integrated Intel GM45. Please > disregard the inherent limitations of such recording and rather focus your > attention on the difference, especially when exiting Activities is shown. > https://onedrive.live.com/redir?resid=66CF2646234394FC!2536&authkey=!APhX4WS4a7HN1zE&ithint=folder%2c.mp4 That does not look like tearing to me just horrible performance (i.e still a bug but a different one). Do you see any tearing line when you scroll in a big window or when you open a windowed opengl game?
I don't see any distinct tearing line in neither of cases. I used OpenArena with default settings running at 1280x960, windowed. If this is the case I'm sorry, but the window 'leftovers' in activities animations really led me into thinking it is tearing. What do I do now? Do I file a driver bug at bugzilla.freedesktop.org? I would just like to stress that I filed a bug report already at bugzilla.redhat.org a year ago or so. I even provided some requested brief gnome shell benchmark data and we've arrived at nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=977391
(In reply to comment #25) > I don't see any distinct tearing line in neither of cases. I used OpenArena > with default settings running at 1280x960, windowed. > If this is the case I'm sorry, but the window 'leftovers' in activities > animations really led me into thinking it is tearing. > > What do I do now? Do I file a driver bug at bugzilla.freedesktop.org? Yes please.
Performance regression on Gen4 Intel GM45 GMA4500MHD https://bugs.freedesktop.org/show_bug.cgi?id=77372
(In reply to comment #9) > To get buffer_age working with intel drivers you would need: > > 1. xserver 1.15 (which you already have) > > 2. mesa 10.1 + the patches from > http://thread.gmane.org/gmane.comp.video.mesa3d.devel/73553 > > 3. xf86-video-intel from that branch: > http://cgit.freedesktop.org/~keithp/xf86-video-intel/log/?h=dri3 > > 4. That > https://git.gnome.org/browse/clutter/commit/?h=clutter-1.16&id=6665f47d66a871b6e1a5f4200282f42da043a0e8 > clutter patch I found it very confusing to know which patches, and in which order, must be applied. Is there any chances those fixes to get buffer_age working with intel drivers will get applied to relevant packages before the arrival of Wayland? I've been suffering the same video tearing issues for years on gen4 Intel GM965 GMA X3100, which is reported in /var/log/Xorg.0.log as Broadwater, but it's actually Crestline.
(In reply to comment #29) > (In reply to comment #9) > > To get buffer_age working with intel drivers you would need: > > > > 1. xserver 1.15 (which you already have) > > > > 2. mesa 10.1 + the patches from > > http://thread.gmane.org/gmane.comp.video.mesa3d.devel/73553 > > > > 3. xf86-video-intel from that branch: > > http://cgit.freedesktop.org/~keithp/xf86-video-intel/log/?h=dri3 > > > > 4. That > > https://git.gnome.org/browse/clutter/commit/?h=clutter-1.16&id=6665f47d66a871b6e1a5f4200282f42da043a0e8 > > clutter patch > > I found it very confusing to know which patches, and in which order, must be > applied. Is there any chances those fixes to get buffer_age working with intel > drivers will get applied to relevant packages before the arrival of Wayland? All of them are already upstream.
(In reply to comment #30) > All of them are already upstream. That's good news, I'll try them out and test Gnome in an Arch distro. Thanks.
It's no all good news after all. I just learnt that Arch has decided to temporarily disable DRI3 support with their xf86-video-intel DDX driver package because of multiple rendering bugs with the Intel DRI3 support $ grep -i dri3 /var/log/Xorg.0.log [ 41.411] Initializing built-in extension DRI3 [ 41.885] (II) Loading sub module "dri3" [ 41.885] (II) LoadModule: "dri3" [ 42.009] (WW) Warning, couldn't open module dri3 [ 42.009] (II) UnloadModule: "dri3" [ 42.009] (II) Unloading dri3 [ 42.009] (EE) intel: Failed to load module "dri3" (module does not exist, 0)
(In reply to comment #32) > It's no all good news after all. I just learnt that Arch has decided to > temporarily disable DRI3 support with their xf86-video-intel DDX driver package > because of multiple rendering bugs with the Intel DRI3 support Well that's a distro issue. Talk to the arch people. As for the rendering bugs ... that only happens with SNA you ask them to use that patch: https://bugs.freedesktop.org/show_bug.cgi?id=81551#c7 (or just don't use SNA). Anyway there is nothing left to do on the GNOME side here.
Is there a distro that includes all the needed packages right now in standard-only repos? I'm selling the damn thing and I could try one last time.
(In reply to comment #34) > Is there a distro that includes all the needed packages right now in > standard-only repos? I'm selling the damn thing and I could try one last time. Fedora 21: http://download-ib01.fedoraproject.org/pub/alt/stage/21_Alpha_TC7/Workstation/x86_64/iso/
(In reply to comment #35) > (In reply to comment #34) > > Is there a distro that includes all the needed packages right now in > > standard-only repos? I'm selling the damn thing and I could try one last time. > > Fedora 21: > http://download-ib01.fedoraproject.org/pub/alt/stage/21_Alpha_TC7/Workstation/x86_64/iso/ I've just checked the image. The issue is still there for my system. Nothing has changed. It must be something different to what you addressed with the set of fixes F21 is supposed to employ.
(In reply to comment #36) > (In reply to comment #35) > > (In reply to comment #34) > > > Is there a distro that includes all the needed packages right now in > > > standard-only repos? I'm selling the damn thing and I could try one last time. > > > > Fedora 21: > > http://download-ib01.fedoraproject.org/pub/alt/stage/21_Alpha_TC7/Workstation/x86_64/iso/ > I've just checked the image. The issue is still there for my system. Nothing > has changed. It must be something different to what you addressed with the set > of fixes F21 is supposed to employ. Oh sorry mixed you up with the other guy .. there is no tearing issue on GM45 your problem is bad performance not tearing. You even have a driver bug filed https://bugs.freedesktop.org/show_bug.cgi?id=77372
(In reply to comment #37) > Oh sorry mixed you up with the other guy .. there is no tearing issue on GM45 > your problem is bad performance not tearing. You even have a driver bug filed > https://bugs.freedesktop.org/show_bug.cgi?id=77372 And I've mixed the bug reports :) So yes, the performance regression is still there but I've retired my T500 today.