GNOME Bugzilla – Bug 651312
nvidia binary driver and gnome-shell equal to a whole lot of tearing in movies
Last modified: 2012-03-09 16:47:55 UTC
I started to discuss the issue in the nvnews forums [1], but after some more testing it seems gnome-shell is the culprit. Summing up, if I run gnome-shell in fallback mode, I am able to get tear-free video with mplayer with 3 video output methods (vdpau, xv and gl) on all screens, sometimes with the need to tell the driver which screen to sync to. On the other hand, with full-fledged gnome-shell the videos tear no matter what. I also checked with KDE, and while the videos tear like crazy in windowed mode, fullscreen is fine. I'm assuming they have some option similar to compiz' unredirect fullscreen windows enabled by default. Perhaps gnome-shell could do something like that too? While not perfect, it is certainly better than the current state of affairs. This on an up-to-date Fedora 15 x86_64, with GeForce 485M (no 3d with nouveau last time I checked) and 270.41.06 nvidia binary driver. Let me know if you need more information. [1] http://nvnews.net/vbulletin/showthread.php?t=162808
(In reply to comment #0) > I started to discuss the issue in the nvnews forums [1], but after some more > testing it seems gnome-shell is the culprit. > Summing up, if I run gnome-shell in fallback mode, I am able to get tear-free > video with mplayer with 3 video output methods (vdpau, xv and gl) on all > screens, sometimes with the need to tell the driver which screen to sync to. gnome-shell does not have a fallback mode. You are running uncomposited metacity and gnome-panel in that case, so this could still be a driver bug. > On > the other hand, with full-fledged gnome-shell the videos tear no matter what. > I also checked with KDE, and while the videos tear like crazy in windowed mode, > fullscreen is fine. I'm assuming they have some option similar to compiz' > unredirect fullscreen windows enabled by default. Perhaps gnome-shell could do > something like that too? While not perfect, it is certainly better than the > current state of affairs. I believe we only undirect full screen windows under some specific conditions, otherwise we would lose things like alt-tab. > This on an up-to-date Fedora 15 x86_64, with GeForce 485M (no 3d with nouveau > last time I checked) and 270.41.06 nvidia binary driver. Let me know if you > need more information. > [1] http://nvnews.net/vbulletin/showthread.php?t=162808
(In reply to comment #1) > (In reply to comment #0) > > I started to discuss the issue in the nvnews forums [1], but after some more > > testing it seems gnome-shell is the culprit. > > Summing up, if I run gnome-shell in fallback mode, I am able to get tear-free > > video with mplayer with 3 video output methods (vdpau, xv and gl) on all > > screens, sometimes with the need to tell the driver which screen to sync to. > > gnome-shell does not have a fallback mode. You are running uncomposited > metacity and gnome-panel in that case, so this could still be a driver bug. Sorry, I am not that familiar with the terminology. Is there a way I could test it in order to figure out which one is it? > > On > > the other hand, with full-fledged gnome-shell the videos tear no matter what. > > I also checked with KDE, and while the videos tear like crazy in windowed mode, > > fullscreen is fine. I'm assuming they have some option similar to compiz' > > unredirect fullscreen windows enabled by default. Perhaps gnome-shell could do > > something like that too? While not perfect, it is certainly better than the > > current state of affairs. > > I believe we only undirect full screen windows under some specific conditions, > otherwise we would lose things like alt-tab. Is there a way to override? > > This on an up-to-date Fedora 15 x86_64, with GeForce 485M (no 3d with nouveau > > last time I checked) and 270.41.06 nvidia binary driver. Let me know if you > > need more information. > > [1] http://nvnews.net/vbulletin/showthread.php?t=162808 What is gnome-shell using for compositing, OpenGL or XRender? Also, how are the recent fence syncing patches influencing the situation, if at all?
> Sorry, I am not that familiar with the terminology. Is there a way I could test > it in order to figure out which one is it? If you see "Applications", "Places", "System" in the top-left, you're in the old, uncomposited gnome-panel/metacity fallback. > Is there a way to override? I am unsure. Bugs 618497 and 597014 should have have more information. > What is gnome-shell using for compositing, OpenGL or XRender? gnome-shell uses Mutter and Clutter, which composites with OpenGL through the GLX texture_from_pixmap extension. > Also, how are the recent fence syncing patches influencing the situation, if at all? I have no idea. Adel would know, CC'ing him.
(In reply to comment #3) > > Sorry, I am not that familiar with the terminology. Is there a way I could test > > it in order to figure out which one is it? > > If you see "Applications", "Places", "System" in the top-left, you're in the > old, uncomposited gnome-panel/metacity fallback. Sorry I was not clear. I can tell metacity from gnome-shell, I meant to ask how do I tell if it's a shell bug or a driver bug. > > Is there a way to override? > > I am unsure. Bugs 618497 and 597014 should have have more information. > > > What is gnome-shell using for compositing, OpenGL or XRender? > > gnome-shell uses Mutter and Clutter, which composites with OpenGL through the > GLX texture_from_pixmap extension. > > > Also, how are the recent fence syncing patches influencing the situation, if at all? > > I have no idea. Adel would know, CC'ing him.
(In reply to comment #1) > (In reply to comment #0) > I believe we only undirect full screen windows under some specific conditions, > otherwise we would lose things like alt-tab. The conditions are simple: never ... there are patches in bugzilla for this but they didn't get merged as of now, and those patches wouldn't unredirect videos because fixing tearing isn't what they are trying to solve. (In reply to comment #3) > > Also, how are the recent fence syncing patches influencing the situation, if at all? Those patches are trying to solve a different problem. They are about making sure that damage events are processed correctly so that no screen corruption is appears due to race conditions. As for the actual problem I suspect that GLX_SGI_video_sync is ignoring the "sync on which screen" setting which would be a driver bug. To verify that try running gnome-shell with CLUTTER_DEBUG=disable-clipped-redraws and it should always use a full screen blit/flip using GLX_SGI_swap_control which should respect the "sync on which screen" setting.
Created attachment 188839 [details] console output I ran: $ CLUTTER_DEBUG=disable-clipped-redraws gnome-shell --replace --display=:0 > gnome-shell.log 2>&1 on tty2 and try my set of mplayer tests again. Unfortunately it did not change anything.
I made an interesting observation: with the laptop screen, the "tear line" always stays at the same level, while on the external screen it moves. Moreover, on the internal screen the tearing is almost unnoticeable on the laptop screen. This is definitely peculiar.
(In reply to comment #7) > I made an interesting observation: with the laptop screen, the "tear line" > always stays at the same level, while on the external screen it moves. > Moreover, on the internal screen the tearing is almost unnoticeable on the > laptop screen. This is definitely peculiar. This was supposed to say: with the internal screen the tearing is almost unnoticeable with gl and xv drivers in windowed mplayer. Still visible with vdpau, though.
As suggested yesterday on IRC, I tried playing around with CLUTTER_VBLANK. Setting it to "none" or "dri" produced even more tearing in movies, and nvidia-settings was not able to change anything. Setting to "glx" is what I am observing initially, with the tear line static on the primary screen and moving on secondary. I then tried $ __GL_SYNC_DISPLAY_DEVICE=DFP-2 gnome-shell --replace --display=:0 This resulted in videos tearing on the laptop screen (moving tear line; xv, gl and vdpau) but the second screen was working perfectly. Just to be sure, I then tried Summing up, it seems there are several issues here: 1. nvidia driver can only sync one display device at a time. 2. syncing for the laptop screen is not working entirely well, which results in no tearing in window but a "static" tear line is present when in full screen. (1) is a limitation of nvidia driver and is of no issue here. What is more interesting is (2). Can it be caused by the fact that, according to nvidia-settings, external screen is 60.00 Hz while the internal one is 59.93 Hz?
(In reply to comment #9) Something got lost: > Just to be sure, I then tried $ __GL_SYNC_DISPLAY_DEVICE=DFP-0 gnome-shell --replace --display=:0 but this just brought me back to the starting point.
This is still an issue with 270.41.19 drivers.
Still a problem with 275.09.07.
280.13 drivers do not help.
Neither do the 285 drivers.
Has somebody tried to report this to NVidia?
http://www.nvnews.net/vbulletin/showpost.php?p=2437190&postcount=1
Still a problem with 290.10 drivers and Gnome 3.2. Given that hooks to unredirect fullscreen windows were implemented, is there a way to force such behaviour?
Running smooth for me after add CLUTTER_PAINT=disable-clipped-redraws:disable-culling in /etc/environment.
Julio, **how** did you find that out? This workaround does the trick for me, too.
(In reply to comment #19) > Julio, **how** did you find that out? > > This workaround does the trick for me, too. Here https://bbs.archlinux.org/viewtopic.php?pid=1016569
(In reply to comment #19) > Julio, **how** did you find that out? > > This workaround does the trick for me, too. Here too: https://bbs.archlinux.org/viewtopic.php?pid=1017705
According to those sources, this also fixes the issue for Intel HD video devices. Bugkeepers, is there a way to add this as a default to Gnome-Shell/Mutter?
(In reply to comment #22) > According to those sources, this also fixes the issue for Intel HD video > devices. > > Bugkeepers, is there a way to add this as a default to Gnome-Shell/Mutter? This is not a really a fix ... what you do here is force us to always redraw the entire screen instead of the part that actually changed causing potentially higher power consumption and performance degradation. This basically means that GLX_SGI_video_sync on NVIDIA is broken for multidisplay setups. (we use that to synchronize sub screen blits). As for intel we do not sync sub screen blits *at all* (because the driver is assumed to never tear) ... do you have any pointers to such issues on intel?
Well, I am speaking as a layman here, but the way NVIDIA driver is designed, you can only sync to one screen. So maybe some sort of white/blacklist would be in order?
From the nvidia readme [1]: When using __GL_SYNC_TO_VBLANK with TwinView, OpenGL can only sync to one of the display devices; this may cause tearing corruption on the display device to which OpenGL is not syncing. You can use the environment variable __GL_SYNC_DISPLAY_DEVICE to specify to which display device OpenGL should sync. You should set this environment variable to the name of a display device; for example "CRT-1". Look for the line "Connected display device(s):" in your X log file for a list of the display devices present and their names. You may also find it useful to review Chapter 13, Configuring TwinView "Configuring Twinview" and the section on Ensuring Identical Mode Timings in Chapter 19, Programming Modes. [1] ftp://download.nvidia.com/XFree86/Linux-x86/290.10/README/openglenvvariables.html
(In reply to comment #25) > From the nvidia readme [1]: > > When using __GL_SYNC_TO_VBLANK with TwinView, OpenGL can only sync to one of > the display devices; this may cause tearing corruption on the display device to > which OpenGL is not syncing. You can use the environment variable > __GL_SYNC_DISPLAY_DEVICE to specify to which display device OpenGL should sync. > You should set this environment variable to the name of a display device; for > example "CRT-1". Look for the line "Connected display device(s):" in your X log > file for a list of the display devices present and their names. You may also > find it useful to review Chapter 13, Configuring TwinView "Configuring > Twinview" and the section on Ensuring Identical Mode Timings in Chapter 19, > Programming Modes. This does not explain why GLX_SGI_video_sync is broken it should sync to the display that __GL_SYNC_DISPLAY_DEVICE is pointed to. (In reply to comment #24) > So maybe some sort of white/blacklist would be in order? No.
OK, I understand. I will try to forward these findings to nvidia, let's see what they say.
Now hang on a minute. I'm not using a multi-monitor configuration; I'm using this to fix syncing issues on a *single* screen, which has always had the issues described (syncing for the laptop screen is not working entirely well, which results in no tearing in window but a "static" tear line is present when in full screen) no matter which syncing options I use in the driver's tool. This workaround fixes that on my laptop and on a desktop machine (also using nVidia card).
This would seem to mean that if the following statement is true: "This is not a really a fix ... what you do here is force us to always redraw the entire screen instead of the part that actually changed causing potentially higher power consumption and performance degradation" ...then, given my symptoms, there is something wrong with whatever mechanism detects which part of the screen has actually changed when an application is in fullscreen, which I do not believe is an nVidia problem.
(In reply to comment #29) > This would seem to mean that if the following statement is true: > > "This is not a really a fix ... what you do here is force us to always redraw > the entire screen instead of the part that actually changed causing potentially > higher power consumption and performance degradation" > > ...then, given my symptoms, there is something wrong with whatever mechanism > detects which part of the screen has actually changed when an application is in > fullscreen, which I do not believe is an nVidia problem. No if you have any tearing here it means that GLX_SGI_video_sync does not work for whatever reason i.e a driver bug. (In reply to comment #28) > Now hang on a minute. I'm not using a multi-monitor configuration; [...] > > This workaround fixes that on my laptop and on a desktop machine (also using > nVidia card). I cannot reproduce that (i.e no tearing here at all on NVIDIA, single screen setup).
I have tearing only on the top of screen.
Created attachment 206472 [details] Screenshot An example.
I have no idea how you managed to capture that screenshot. I tried to capture mplayer window but it has never shown the "static tear line". In any case, this solved the problem for me: CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace &
(In reply to comment #5) > (In reply to comment #1) > > (In reply to comment #0) > > > I believe we only undirect full screen windows under some specific conditions, > > otherwise we would lose things like alt-tab. > > The conditions are simple: never ... there are patches in bugzilla for this but > they didn't get merged as of now, and those patches wouldn't unredirect videos > because fixing tearing isn't what they are trying to solve. > > (In reply to comment #3) > > > Also, how are the recent fence syncing patches influencing the situation, if at all? > > Those patches are trying to solve a different problem. They are about making > sure that damage events are processed correctly so that no screen corruption is > appears due to race conditions. > > As for the actual problem I suspect that GLX_SGI_video_sync is ignoring the > "sync on which screen" setting which would be a driver bug. > > To verify that try running gnome-shell with > CLUTTER_DEBUG=disable-clipped-redraws and it should always use a full screen > blit/flip using GLX_SGI_swap_control which should respect the "sync on which > screen" setting. Doh, it is CLUTTER_PAINT, not CLUTTER_DEBUG. Imagine we could have figured it out so much sooner ;)
I just discovered something even more awesome: using the workaround from comment 18 makes the video tear-free on both screens without the need to fiddle with __GL_SYNC_DISPLAY_DEVICE. This kind of makes sense, since both the internal and the external screen are running at 60 Hz.
(In reply to comment #30) > (In reply to comment #29) > No if you have any tearing here it means that GLX_SGI_video_sync does not work > for whatever reason i.e a driver bug. Except, in my case, it actually does work: - Everything NOT fullscreened is syncing perfectly. - Everything that *is* fullscreened syncs, just not perfectly - I have a "tear line" near the very top of the screen, about where the bottom edge of the Gnome-Shell "panel" would be, that tears. This "tear line" never moves - it is always up there - and almost always tears: above the "tear line" is 1 frame behind everything below. Clearly, this is synchronized, just not well. Turning Syncing off in the nVidia control panel produces a lack of syncing everywhere - on the desktop, in windowed and fullscreen movie/GLX apps (I'm using SNES9X to test) - everywhere, and the position of the tear changes just about every frame. Turning vsync on, and enabling the environment value for CLUTTER_PAINT, makes everything 100% perfect - which, if this were an nVidia bug, certainly wouldn't be possible, would it?
(In reply to comment #36) > (In reply to comment #30) > > (In reply to comment #29) > > > No if you have any tearing here it means that GLX_SGI_video_sync does not work > > for whatever reason i.e a driver bug. > > Except, in my case, it actually does work: > > - Everything NOT fullscreened is syncing perfectly. > > - Everything that *is* fullscreened syncs, just not perfectly - I have a "tear > line" near the very top of the screen, about where the bottom edge of the > Gnome-Shell "panel" would be, that tears. This "tear line" never moves - it is > always up there - and almost always tears: above the "tear line" is 1 frame > behind everything below. Clearly, this is synchronized, just not well. Talked to NVIDIA about this. The problem is that the blit (coping the sub region from the back to front buffer) takes longer then a vsync period (which explains the tearing on the exact same place). There are two ways to solve this either just resort to a fullscreen redraw and buffer swap when the changed area is bigger than a certain size (which you do with the environment variable for everything) or split the area into smaller parts and blit them one by one. The problem is that we'd need some heuristic to detect what "area is too big" means. It depends on the memory bandwidth of the GPU among other how long the copy will take. I will talk to the cogl people trying to find a solution here.
Thank you for digging so deep into this and entertaining my less-informed protestations. Either way, as it stands now, I'm pretty happy - this is the first time where *everything* I run in a Gnome environment is VSync'd, and that's something I've wanted for a very long time indeed. I hope the workaround doesn't disappear anytime soon.
Works is being done on opengl extension that is supposed to fix this and improve rendering performance by doing so. So closing this bug as a duplicate of the cogl one. Once we have the new opengl extension and start using it this issue will be gone. *** This bug has been marked as a duplicate of bug 669122 ***