After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 651312 - nvidia binary driver and gnome-shell equal to a whole lot of tearing in movies
nvidia binary driver and gnome-shell equal to a whole lot of tearing in movies
Status: RESOLVED DUPLICATE of bug 669122
Product: gnome-shell
Classification: Core
Component: drivers
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-05-28 09:40 UTC by Julian Sikorski
Modified: 2012-03-09 16:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0


Attachments
console output (1.25 KB, text/plain)
2011-05-29 09:41 UTC, Julian Sikorski
Details
Screenshot (452.80 KB, image/png)
2012-01-30 20:54 UTC, Júlio Dutra
Details

Description Julian Sikorski 2011-05-28 09:40:14 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
Comment 1 Jasper St. Pierre (not reading bugmail) 2011-05-28 17:25:55 UTC
(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
Comment 2 Julian Sikorski 2011-05-28 19:03:18 UTC
(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?
Comment 3 Jasper St. Pierre (not reading bugmail) 2011-05-28 19:15:58 UTC
> 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.
Comment 4 Julian Sikorski 2011-05-28 19:36:21 UTC
(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.
Comment 5 drago01 2011-05-29 09:21:07 UTC
(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.
Comment 6 Julian Sikorski 2011-05-29 09:41:02 UTC
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.
Comment 7 Julian Sikorski 2011-05-29 09:58:04 UTC
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.
Comment 8 Julian Sikorski 2011-05-29 10:05:26 UTC
(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.
Comment 9 Julian Sikorski 2011-05-31 20:52:31 UTC
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?
Comment 10 Julian Sikorski 2011-05-31 20:54:19 UTC
(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.
Comment 11 Julian Sikorski 2011-06-11 13:07:05 UTC
This is still an issue with 270.41.19 drivers.
Comment 12 Julian Sikorski 2011-06-18 10:05:01 UTC
Still a problem with 275.09.07.
Comment 13 Julian Sikorski 2011-08-04 06:15:12 UTC
280.13 drivers do not help.
Comment 14 Chad Rodrigue 2011-10-29 21:29:42 UTC
Neither do the 285 drivers.
Comment 15 Milan Bouchet-Valat 2011-10-29 21:36:23 UTC
Has somebody tried to report this to NVidia?
Comment 17 Julian Sikorski 2011-11-26 19:04:57 UTC
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?
Comment 18 Júlio Dutra 2011-12-22 12:25:05 UTC
Running smooth for me after add CLUTTER_PAINT=disable-clipped-redraws:disable-culling in /etc/environment.
Comment 19 Chad Rodrigue 2012-01-29 17:52:59 UTC
Julio, **how** did you find that out?

This workaround does the trick for me, too.
Comment 20 Júlio Dutra 2012-01-29 22:07:06 UTC
(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
Comment 21 Júlio Dutra 2012-01-30 12:48:31 UTC
(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
Comment 22 Chad Rodrigue 2012-01-30 17:45:20 UTC
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?
Comment 23 drago01 2012-01-30 17:49:44 UTC
(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?
Comment 24 Julian Sikorski 2012-01-30 17:57:41 UTC
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?
Comment 25 Julian Sikorski 2012-01-30 18:04:42 UTC
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
Comment 26 drago01 2012-01-30 18:13:45 UTC
(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.
Comment 27 Julian Sikorski 2012-01-30 18:25:36 UTC
OK, I understand. I will try to forward these findings to nvidia, let's see what they say.
Comment 28 Chad Rodrigue 2012-01-30 19:01:19 UTC
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).
Comment 29 Chad Rodrigue 2012-01-30 19:04:41 UTC
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.
Comment 30 drago01 2012-01-30 19:39:03 UTC
(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).
Comment 31 Júlio Dutra 2012-01-30 19:51:16 UTC
I have tearing only on the top of screen.
Comment 32 Júlio Dutra 2012-01-30 20:54:16 UTC
Created attachment 206472 [details]
Screenshot

An example.
Comment 33 Julian Sikorski 2012-01-30 21:42:49 UTC
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 &
Comment 34 Julian Sikorski 2012-01-30 21:45:05 UTC
(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 ;)
Comment 35 Julian Sikorski 2012-01-30 21:57:49 UTC
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.
Comment 36 Chad Rodrigue 2012-01-30 23:50:34 UTC
(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?
Comment 37 drago01 2012-01-31 08:32:31 UTC
(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.
Comment 38 Chad Rodrigue 2012-01-31 21:30:12 UTC
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.
Comment 39 drago01 2012-03-09 16:47:55 UTC
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 ***