New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSync #7

Open
ghost opened this Issue Feb 25, 2012 · 115 comments

Comments

Projects
None yet
@ghost

ghost commented Feb 25, 2012

Is it possible to implement vsync into compton? I like this compositor very much, but tearing is annoying some time.

@chjj

This comment has been minimized.

Show comment
Hide comment
@chjj

chjj Feb 27, 2012

Owner

I don't think there is any xrender function to explicitly get or wait for the vblank interval. It doesn't have any vsync support. I know the XFCE guys had a problem with this for their compositor. I also think compiz (GL) had a hard time maintaining a vsync feature because it would conflict with video drivers that were also trying to sync to the vblank rate. So even if I could, I would be hesitant about adding this.

Owner

chjj commented Feb 27, 2012

I don't think there is any xrender function to explicitly get or wait for the vblank interval. It doesn't have any vsync support. I know the XFCE guys had a problem with this for their compositor. I also think compiz (GL) had a hard time maintaining a vsync feature because it would conflict with video drivers that were also trying to sync to the vblank rate. So even if I could, I would be hesitant about adding this.

@chjj chjj closed this Feb 27, 2012

@corenominal

This comment has been minimized.

Show comment
Hide comment
@corenominal

corenominal Apr 23, 2012

Apologies for commenting on a closed issue, but I noticed that an initial tearing/vsync fix has been commited to cairo-compmgr. I have tested the fix and it seems to work well -- when watching http://www.youtube.com/watch?v=ZCPkOpMHB7g there is no visible tearing at all.

The commit, in case you wanted to check it out: http://git.tuxfamily.org/?p=ccm/cairocompmgr.git;a=commitdiff;h=efa4ceb97da501e8630ca7f12c99b1dce853c73e

I am loving compton and think it would be fantastic if this could be implemented as an option.

corenominal commented Apr 23, 2012

Apologies for commenting on a closed issue, but I noticed that an initial tearing/vsync fix has been commited to cairo-compmgr. I have tested the fix and it seems to work well -- when watching http://www.youtube.com/watch?v=ZCPkOpMHB7g there is no visible tearing at all.

The commit, in case you wanted to check it out: http://git.tuxfamily.org/?p=ccm/cairocompmgr.git;a=commitdiff;h=efa4ceb97da501e8630ca7f12c99b1dce853c73e

I am loving compton and think it would be fantastic if this could be implemented as an option.

@glesik

This comment has been minimized.

Show comment
Hide comment
@glesik

glesik Jul 9, 2012

Sorry for yet another comment on closed issue, but I've found a patch which seems to implement vsync in Xfwm and thus, hopefully, enables tearing-free video playback:

https://bugzilla.xfce.org/show_bug.cgi?id=8898

I wonder if this or previously mentioned piece of code can be incorporated in Compton.

glesik commented Jul 9, 2012

Sorry for yet another comment on closed issue, but I've found a patch which seems to implement vsync in Xfwm and thus, hopefully, enables tearing-free video playback:

https://bugzilla.xfce.org/show_bug.cgi?id=8898

I wonder if this or previously mentioned piece of code can be incorporated in Compton.

@Janhouse

This comment has been minimized.

Show comment
Hide comment
@Janhouse

Janhouse Oct 1, 2012

Compton with video tearing is kind of unusable.
I hope this gets fixed at some point.

Janhouse commented Oct 1, 2012

Compton with video tearing is kind of unusable.
I hope this gets fixed at some point.

@richardgv richardgv reopened this Oct 2, 2012

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 2, 2012

Collaborator
  1. As chjj pointed out, Xrender itself has no support for VSync. People says the whole X server isn't actually aware of VSync, only the driver is.
  2. Despite that I know nothing about OpenGL and little about X, I've thought about 3 approaches after some research:
    1. Pure software method. Detect the refresh rate with Xrandr, then repaint with the pace. If the refresh rate is 60Hz, we paint at most 60 times per second.

      Pros: Easy to implement, low cost, saves resources by delaying event processing and repainting.

      Cons: sleep() may not accurately work (I've seen poll() not sleeping accurately); If the repaint starts at a particular time, maybe screen tearing will increase instead of decrease.

    2. Relying on DRM_IOCTL_WAIT_VBLANK. Simulating the xfwm4 patch corenominal pointed out.

      Cons: DRM_IOCTL_WAIT_VBLANK is reported to be "downright broken" on some chips in some cases; No documentation I could find; I have idea if it will work on proprietary drivers; the author says there's 10 pixel tearing area, and I don't know if it could get larger under specific situations (like very high load).

    3. Using OpenGL VSync functionalities. Simulating cairo-compmgr and Compipz.

      Cons: Might be driver-dependent, Compiz's VSync feature at least used to be broken on some chips; OpenGL wiki says "Your application's use of swap interval may be overridden by external, driver-specific configuration"; Little documentation; Uncertain if will conflict with the VSync feature of the driver like what chjj said; Linking to libGL.

      And I'm not quite sure what is the correct interface to use. SGI_swap_control, SGI_video_sync, or GLX_OML_sync_control? And bitSphere says mesa and nVidia/ATI drivers use different functions.

  3. The biggest problem is lack of documentation... I could try writing some code but there won't be a way for me test on every sort of GPUs. We don't have many developers, and I guess we are not rich enough to have many computers with different GPUs.
  4. My current suggestion is to check your driver for VSync support. The nVidia binary blob provides a "Sync to VBlank" option for me and I don't seem getting any tearing.
Collaborator

richardgv commented Oct 2, 2012

  1. As chjj pointed out, Xrender itself has no support for VSync. People says the whole X server isn't actually aware of VSync, only the driver is.
  2. Despite that I know nothing about OpenGL and little about X, I've thought about 3 approaches after some research:
    1. Pure software method. Detect the refresh rate with Xrandr, then repaint with the pace. If the refresh rate is 60Hz, we paint at most 60 times per second.

      Pros: Easy to implement, low cost, saves resources by delaying event processing and repainting.

      Cons: sleep() may not accurately work (I've seen poll() not sleeping accurately); If the repaint starts at a particular time, maybe screen tearing will increase instead of decrease.

    2. Relying on DRM_IOCTL_WAIT_VBLANK. Simulating the xfwm4 patch corenominal pointed out.

      Cons: DRM_IOCTL_WAIT_VBLANK is reported to be "downright broken" on some chips in some cases; No documentation I could find; I have idea if it will work on proprietary drivers; the author says there's 10 pixel tearing area, and I don't know if it could get larger under specific situations (like very high load).

    3. Using OpenGL VSync functionalities. Simulating cairo-compmgr and Compipz.

      Cons: Might be driver-dependent, Compiz's VSync feature at least used to be broken on some chips; OpenGL wiki says "Your application's use of swap interval may be overridden by external, driver-specific configuration"; Little documentation; Uncertain if will conflict with the VSync feature of the driver like what chjj said; Linking to libGL.

      And I'm not quite sure what is the correct interface to use. SGI_swap_control, SGI_video_sync, or GLX_OML_sync_control? And bitSphere says mesa and nVidia/ATI drivers use different functions.

  3. The biggest problem is lack of documentation... I could try writing some code but there won't be a way for me test on every sort of GPUs. We don't have many developers, and I guess we are not rich enough to have many computers with different GPUs.
  4. My current suggestion is to check your driver for VSync support. The nVidia binary blob provides a "Sync to VBlank" option for me and I don't seem getting any tearing.
@corenominal

This comment has been minimized.

Show comment
Hide comment
@corenominal

corenominal Oct 3, 2012

I guess we are not rich enough to have many computers with different GPUs.

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

corenominal commented Oct 3, 2012

I guess we are not rich enough to have many computers with different GPUs.

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 3, 2012

Collaborator

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

Honestly I thought Plan 1 is the worst of all. :-) I might try to implement if you are interested, but not too soon -- it doesn't have the highest priority and I started getting busy recently.

Collaborator

richardgv commented Oct 3, 2012

If you wanted to give option 1 a try, I have a bunch of different system I can test it on. Also, I think I could encourage a good few CrunchBang users to help with testing. Just a thought.

Honestly I thought Plan 1 is the worst of all. :-) I might try to implement if you are interested, but not too soon -- it doesn't have the highest priority and I started getting busy recently.

@Janhouse

This comment has been minimized.

Show comment
Hide comment
@Janhouse

Janhouse Oct 3, 2012

I don't have much free time but if you need some help with testing or something else, I could try finding some time for it.

I can test it on laptops with Radeon X1200 (open source driver only) and Intel (3rd Gen Core processor Graphics Controller) video cards.

Janhouse commented Oct 3, 2012

I don't have much free time but if you need some help with testing or something else, I could try finding some time for it.

I can test it on laptops with Radeon X1200 (open source driver only) and Intel (3rd Gen Core processor Graphics Controller) video cards.

richardgv added a commit that referenced this issue Oct 8, 2012

Feature: #7: VSync
- Add VSync feature. 3 possible VSync methods available: "sw" (software,
  not too reliable, but at least you have something to fallback to),
  "drm" (using DRM_IOCTL_WAIT_VBLANK, should work only on DRI drivers),
  "opengl" (using SGI_swap_control extension OpenGL, might work on more
  drivers than the DRM method). "sw" and "opengl" are briefly tested,
  "drm" received utterly no test (because I use the nVidia binary blob).
  They are enabled with "--vsync sw" / "--vsync drm" / "--vsync opengl".

- Add --refresh-rate to let user specify a refresh rate for software
  VSync, in case the automatic refresh rate detection does not work
  well.

- Seemingly the automatic refresh rate detection using X RandR in
  software VSync detects refresh rate incorrectly. Need further investigation.

- Fix a few bugs in fading timing.

- Add a workaround for client window detection on Fluxbox, as Fluxbox
  (incorrectly?) sets the override-redirect flag upon all frame
  windows.

- Software VSync adds dependency on librt (a part of glibc) for
  nanosecond-level timing functions, and libXrandr for automatic refresh
  rate detection; DRM VSync adds dependency on libdrm to use its drm.h,
  but does not link to libdrm; OpenGL VSync adds dependency on libGL.

- Print timing information on DEBUG_REPAINT.
@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 8, 2012

Collaborator

Here you go, guys. Clone richardgv-dev branch and test! Read the commit log or usage text for information for how to enable VSync. All 3 methods need testing, but especially the DRM one -- it's entirely not tested.

When you try the software VSync remember to use --refresh-rate to specify your refresh rate. Probably the refresh rate detection isn't working.

If you have the the interest to further investigate if the painting time is correct, compile compton with:

make clean; CFLAGS='-DDEBUG_REPAINT' make

And compton will print out the detailed time of painting like this:

[     0:020020472 ] [     7.38 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020006796 ] [     7.40 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019991037 ] [     7.42 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019996693 ] [     7.44 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019993656 ] [     7.46 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020007497 ] [     7.48 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020004597 ] [     7.50 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a

The things in the first bracket is the time passed since last paint, in the format of [ SECONDS:NANOSECONDS ]; the second is the time passed since the program starts. If you see the interval is always N times of a fixed value (200, 000, 000 nanoseconds in the case above, as compton thinks my refresh rate is 50Hz -- but in fact it's 60Hz, the detection didn't work correctly), VSync is working.

This feature will not be available as a configuration file option before I'm sure it's working.

Collaborator

richardgv commented Oct 8, 2012

Here you go, guys. Clone richardgv-dev branch and test! Read the commit log or usage text for information for how to enable VSync. All 3 methods need testing, but especially the DRM one -- it's entirely not tested.

When you try the software VSync remember to use --refresh-rate to specify your refresh rate. Probably the refresh rate detection isn't working.

If you have the the interest to further investigate if the painting time is correct, compile compton with:

make clean; CFLAGS='-DDEBUG_REPAINT' make

And compton will print out the detailed time of painting like this:

[     0:020020472 ] [     7.38 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020006796 ] [     7.40 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019991037 ] [     7.42 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019996693 ] [     7.44 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:019993656 ] [     7.46 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020007497 ] [     7.48 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a
[     0:020004597 ] [     7.50 ] paint: 0x00c00352 0x00c00661 0x00c076eb 0x00c04cb8 0x00c0397a

The things in the first bracket is the time passed since last paint, in the format of [ SECONDS:NANOSECONDS ]; the second is the time passed since the program starts. If you see the interval is always N times of a fixed value (200, 000, 000 nanoseconds in the case above, as compton thinks my refresh rate is 50Hz -- but in fact it's 60Hz, the detection didn't work correctly), VSync is working.

This feature will not be available as a configuration file option before I'm sure it's working.

@corenominal

This comment has been minimized.

Show comment
Hide comment
@corenominal

corenominal Oct 8, 2012

Thank you for your continued work, @richardgv. The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode, but I have tested the sofware and opengl modes.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked. If I am super lucky with my timing, it appears either at the very top or very bottom of screen and is only noticable when playing fullscreen video.

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

I hope the above makes sense. Sorry I have not been able to provide any debug output, I will try and do some more testing on different systems tonight.

corenominal commented Oct 8, 2012

Thank you for your continued work, @richardgv. The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode, but I have tested the sofware and opengl modes.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked. If I am super lucky with my timing, it appears either at the very top or very bottom of screen and is only noticable when playing fullscreen video.

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

I hope the above makes sense. Sorry I have not been able to provide any debug output, I will try and do some more testing on different systems tonight.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 8, 2012

Collaborator

@corenominal:

The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode

The DRM VSync should work for Intel drivers. I believe the driver use DRI in the kernel, right? Please check what error message are you receiving. "vsync_drm_init(): Failed to open device." indicates compton had troubles opening /dev/dri/card0, and please check if there's anything under /dev/dri. Other error messages or no error message generally indicates a bug in my code.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked.

Oh, well, cairo-compmgr uses quite a similar method, and it does not have a tearing problem when we do? The only difference I could see is cairo-compmgr is probably using X DBE extension for rendering. Hmm, should we implement the same thing?

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

There are two problems here that I could not understand:

  1. I've did a test here with 50Hz refresh rate specified in software VSync. There is an inaccuracy of tens of thousand nanoseconds per paint, possibly because of the time that compton's calculation takes, and inaccuracy in ppoll(), but this inaccuracy does not accumulate, so it should not cause the tearing line to move continuous in one direction (but it should cause the tearing line to go back and forth), unless you specified the wrong refresh rate -- which will probably make the tearing line move much more speedy than what you saw -- or compton does not count time in the same speed of your monitor.
  2. Even if we have a timing issue in the program, I imagine the tearing line should disappear after it goes over the bottom edge of the screen, instead of rotating instantly.

And at last, I have no luck reproducing any tearing, still. My knowledge about the whole thing is... Close to none. Before I read this issue report, I had no idea what VSync is. When I neither have sufficient knowledge nor could actually see and test about this problem, I'm afraid you can't expect much from me. Let's hope chjj could spot what's wrong in my code.

Collaborator

richardgv commented Oct 8, 2012

@corenominal:

The chipset on this machine (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller) does not seem to support the DRM mode

The DRM VSync should work for Intel drivers. I believe the driver use DRI in the kernel, right? Please check what error message are you receiving. "vsync_drm_init(): Failed to open device." indicates compton had troubles opening /dev/dri/card0, and please check if there's anything under /dev/dri. Other error messages or no error message generally indicates a bug in my code.

Visually, the opengl mode seems to be working better on this system, there is tearing but it happens at a static position on the screen. I guess it's a timing issue as to when compton starts because the tearing will be displayed at a different position on the screen, each time compton is invoked.

Oh, well, cairo-compmgr uses quite a similar method, and it does not have a tearing problem when we do? The only difference I could see is cairo-compmgr is probably using X DBE extension for rendering. Hmm, should we implement the same thing?

Using the software mode, the tearing is visable again in a single position on the screen, but moves slowley down until it reaches the bottom, then starts again from the top. I guess the timing is very slightly out?

There are two problems here that I could not understand:

  1. I've did a test here with 50Hz refresh rate specified in software VSync. There is an inaccuracy of tens of thousand nanoseconds per paint, possibly because of the time that compton's calculation takes, and inaccuracy in ppoll(), but this inaccuracy does not accumulate, so it should not cause the tearing line to move continuous in one direction (but it should cause the tearing line to go back and forth), unless you specified the wrong refresh rate -- which will probably make the tearing line move much more speedy than what you saw -- or compton does not count time in the same speed of your monitor.
  2. Even if we have a timing issue in the program, I imagine the tearing line should disappear after it goes over the bottom edge of the screen, instead of rotating instantly.

And at last, I have no luck reproducing any tearing, still. My knowledge about the whole thing is... Close to none. Before I read this issue report, I had no idea what VSync is. When I neither have sufficient knowledge nor could actually see and test about this problem, I'm afraid you can't expect much from me. Let's hope chjj could spot what's wrong in my code.

@Janhouse

This comment has been minimized.

Show comment
Hide comment
@Janhouse

Janhouse Oct 8, 2012

Device is 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) on Macbook Air running ArchLinux Linux janhouse 3.6.0-1-ARCH #1 SMP PREEMPT Mon Oct 1 20:51:05 CEST 2012 x86_64 GNU/Linux

$ ./compton --vsync sw --refresh-rate 60

In sw mode it is tearing in different place each time I start compton.
If I start it at the right time it is hard to see tearing in VLC but I see it in http://www.youtube.com/watch?v=ZCPkOpMHB7g

Same command with debugging mode:

[     0:016670824 ] [    11.98 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016663557 ] [    12.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659790 ] [    12.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016679815 ] [    12.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016661141 ] [    12.05 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033333099 ] [    12.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033365424 ] [    12.11 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659622 ] [    12.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033304886 ] [    12.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016677879 ] [    12.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016714321 ] [    12.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165

$ ./compton --vsync opengl

I see tearing

With debugging:

[     0:016460135 ] [     5.12 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016680112 ] [     5.14 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:022602128 ] [     5.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:017290292 ] [     5.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:010186604 ] [     5.19 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:020854538 ] [     5.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:012569494 ] [     5.22 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:033688256 ] [     5.26 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016036658 ] [     5.27 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016708235 ] [     5.29 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165

$ ./compton --vsync drm

I see tearing

And with debugging:

[     0:016664764 ] [    10.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016689692 ] [    10.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016641894 ] [    10.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033361276 ] [    10.06 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016673573 ] [    10.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016663371 ] [    10.10 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033328853 ] [    10.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033339222 ] [    10.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016658948 ] [    10.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016677822 ] [    10.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016668543 ] [    10.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4

Janhouse commented Oct 8, 2012

Device is 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) on Macbook Air running ArchLinux Linux janhouse 3.6.0-1-ARCH #1 SMP PREEMPT Mon Oct 1 20:51:05 CEST 2012 x86_64 GNU/Linux

$ ./compton --vsync sw --refresh-rate 60

In sw mode it is tearing in different place each time I start compton.
If I start it at the right time it is hard to see tearing in VLC but I see it in http://www.youtube.com/watch?v=ZCPkOpMHB7g

Same command with debugging mode:

[     0:016670824 ] [    11.98 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016663557 ] [    12.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659790 ] [    12.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016679815 ] [    12.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016661141 ] [    12.05 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033333099 ] [    12.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033365424 ] [    12.11 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016659622 ] [    12.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:033304886 ] [    12.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016677879 ] [    12.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165
[     0:016714321 ] [    12.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061b1f6 0x0061b264 0x006104b4 0x00615165

$ ./compton --vsync opengl

I see tearing

With debugging:

[     0:016460135 ] [     5.12 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016680112 ] [     5.14 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:022602128 ] [     5.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:017290292 ] [     5.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:010186604 ] [     5.19 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:020854538 ] [     5.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:012569494 ] [     5.22 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:033688256 ] [     5.26 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016036658 ] [     5.27 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165
[     0:016708235 ] [     5.29 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x00600d38 0x0061541d 0x0061af10 0x0061af7e 0x006104b4 0x00615165

$ ./compton --vsync drm

I see tearing

And with debugging:

[     0:016664764 ] [    10.00 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016689692 ] [    10.01 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016641894 ] [    10.03 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033361276 ] [    10.06 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016673573 ] [    10.08 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016663371 ] [    10.10 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033328853 ] [    10.13 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:033339222 ] [    10.16 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016658948 ] [    10.18 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016677822 ] [    10.20 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
[     0:016668543 ] [    10.21 ] paint: 0x006001a2 0x0060f623 0x00610477 0x00610877 0x006116f9 0x00611756 0x0061672b 0x0060a352 0x0061541d 0x00600d38 0x0061a6e2 0x00615165 0x0061a694 0x006104b4
@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 9, 2012

Collaborator

Ah, I forgot to say, thanks for your tests. :-)

@Janhouse:

The good thing is I saw under both the sw mode and the drm mode, compton is painting with the correct timing. The opengl mode test result looks somewhat incorrect, but, hmm, it's working in both in corenominal's and my tests.

The bad thing is, looks like by controlling the timing of painting I only (mostly) successfully sticked the tearing line to a fixed place on the screen instead of removing it. Hmm, I have no idea what's wrong...

Collaborator

richardgv commented Oct 9, 2012

Ah, I forgot to say, thanks for your tests. :-)

@Janhouse:

The good thing is I saw under both the sw mode and the drm mode, compton is painting with the correct timing. The opengl mode test result looks somewhat incorrect, but, hmm, it's working in both in corenominal's and my tests.

The bad thing is, looks like by controlling the timing of painting I only (mostly) successfully sticked the tearing line to a fixed place on the screen instead of removing it. Hmm, I have no idea what's wrong...

richardgv added a commit that referenced this issue Oct 23, 2012

Improvement #7: Add double buffering
Add double buffering with X DBE extension in hope to get rid of the
tearing issue. Thanks to cairo-compmgr for providing hints. Could be
enabled with --dbe. Only very limited tests have been done, I don't know
if it actually solves the tearing issue. My estimation is it is harmful
for performance, but I found no clear evidence. Experimental, so no
configuration file option is available for it.

MONITOR_REPAINT is broken if --dbe is turned on, this is intended for
testing whether DBE is actually working.
@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 23, 2012

Collaborator

Alright, another attempt: Double buffering, stolen from cairo-compmgr. Please clone from richardgv-dev branch and run compton with a VSync method and --dbe, and test if the tearing changes somehow. (But I'm interested in the result when --dbe alone is enabled, too.) Although I don't think double buffering will cause a huge drop in performance, I still would recommend you guys to check for any possible performance issue caused by double buffering.

kwin does not seem supporting VSync at all in its XRender mode, and I'm unsuccessful in finding the VSync code in mutter. If double buffer fails to work... Are you guys aware of any other compositing window manager that supports VSync and uses XRender as backend?

Collaborator

richardgv commented Oct 23, 2012

Alright, another attempt: Double buffering, stolen from cairo-compmgr. Please clone from richardgv-dev branch and run compton with a VSync method and --dbe, and test if the tearing changes somehow. (But I'm interested in the result when --dbe alone is enabled, too.) Although I don't think double buffering will cause a huge drop in performance, I still would recommend you guys to check for any possible performance issue caused by double buffering.

kwin does not seem supporting VSync at all in its XRender mode, and I'm unsuccessful in finding the VSync code in mutter. If double buffer fails to work... Are you guys aware of any other compositing window manager that supports VSync and uses XRender as backend?

@Janhouse

This comment has been minimized.

Show comment
Hide comment
@Janhouse

Janhouse Oct 23, 2012

A quick test didn't show any improvements but then I started googling and found that many people have the tearing problem with those new Intel graphics cards. I installed some git versions for those drivers and will test if something changes after I reboot.
Will post how it goes after I test it.

Janhouse commented Oct 23, 2012

A quick test didn't show any improvements but then I started googling and found that many people have the tearing problem with those new Intel graphics cards. I installed some git versions for those drivers and will test if something changes after I reboot.
Will post how it goes after I test it.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 23, 2012

Collaborator

Now it's the real problem why apparently VSync in cairo-compmgr is working for corenominal, but I cloned its VSync and it did not work... Is there still a tearing line appearing in a fixed place?

If you have some extra time, I hope you could do some tests to help the diagnostics:

  1. Try the git version of cairo-compmgr and see if it's tearing-free. I personally could not get the version working without segfault, somehow.
  2. Try commenting out line 1704 of ./src/compton.c, which is:
    XdbeSwapBuffers(dpy, &swap_info, 1);

Then compile, and run with:

./compton --dbe --vsync sw --refresh-rate 60

If everything goes right, all your windows will disappear, with only the root window (wallpaper) left. (Then you use Ctrl-C to terminate compton blindly.) This verifies if double buffering is actually working.

I'm still not sure about the process of how things are rendered to monitor, and why people are not able to stop tearing by starting compton in a specific range of time between refreshes with software VSync...

If I could not find a better solution I might have to let compton wait for one frame before painting so the tearing line, with the best luck, might stick to somewhere pretty close to the top of the screen. And that will still not work for software VSync...

Update: Ah, I saw this, which indeed probably points to a driver issue instead of a compositing window manager issue: http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTM

But you see absolutely no tearing if compton is not running, right? Even with the unaccelerated x11 video output mode?

Collaborator

richardgv commented Oct 23, 2012

Now it's the real problem why apparently VSync in cairo-compmgr is working for corenominal, but I cloned its VSync and it did not work... Is there still a tearing line appearing in a fixed place?

If you have some extra time, I hope you could do some tests to help the diagnostics:

  1. Try the git version of cairo-compmgr and see if it's tearing-free. I personally could not get the version working without segfault, somehow.
  2. Try commenting out line 1704 of ./src/compton.c, which is:
    XdbeSwapBuffers(dpy, &swap_info, 1);

Then compile, and run with:

./compton --dbe --vsync sw --refresh-rate 60

If everything goes right, all your windows will disappear, with only the root window (wallpaper) left. (Then you use Ctrl-C to terminate compton blindly.) This verifies if double buffering is actually working.

I'm still not sure about the process of how things are rendered to monitor, and why people are not able to stop tearing by starting compton in a specific range of time between refreshes with software VSync...

If I could not find a better solution I might have to let compton wait for one frame before painting so the tearing line, with the best luck, might stick to somewhere pretty close to the top of the screen. And that will still not work for software VSync...

Update: Ah, I saw this, which indeed probably points to a driver issue instead of a compositing window manager issue: http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTM

But you see absolutely no tearing if compton is not running, right? Even with the unaccelerated x11 video output mode?

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 24, 2012

Collaborator

Another update:

Please clone from richardgv-dev and check if the painting-on-overlay support added in 049621b helps. Please test both --paint-on-overlay and --paint-on-overlay --dbe (of course, enable --vsync, too). Although I don't think they are much related, it at least simulates cairo-compmgr better.

Collaborator

richardgv commented Oct 24, 2012

Another update:

Please clone from richardgv-dev and check if the painting-on-overlay support added in 049621b helps. Please test both --paint-on-overlay and --paint-on-overlay --dbe (of course, enable --vsync, too). Although I don't think they are much related, it at least simulates cairo-compmgr better.

@uzvermode

This comment has been minimized.

Show comment
Hide comment
@uzvermode

uzvermode Oct 25, 2012

Latest richardgv-dev, trying all variants:

xubuntu 12.10
nvidia 310.14 (card GT240)

--vsync opengl --dbe
--vsync opengl --dbe --paint-on-overlay
--vsync opengl --paint-on-overlay

top half screen tearing

--vsync sw --refresh-rate 60 --dbe
--vsync sw --refresh-rate 60 --dbe --paint-on-overlay
--vsync sw --refresh-rate 60 --paint-on-overlay

tearing goes from top of screen to bottom with some delay

uzvermode commented Oct 25, 2012

Latest richardgv-dev, trying all variants:

xubuntu 12.10
nvidia 310.14 (card GT240)

--vsync opengl --dbe
--vsync opengl --dbe --paint-on-overlay
--vsync opengl --paint-on-overlay

top half screen tearing

--vsync sw --refresh-rate 60 --dbe
--vsync sw --refresh-rate 60 --dbe --paint-on-overlay
--vsync sw --refresh-rate 60 --paint-on-overlay

tearing goes from top of screen to bottom with some delay

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 26, 2012

Collaborator

Very well then. I guess I've done pretty much what I could do, and eventually I have to ask somebody else. Let's hope the Xorg guys will bring us something impressive: http://lists.x.org/archives/xorg/2012-October/054996.html

Meanwhile, please check the OpenGL settings and XVideo settings in nvidia-settings, and enable their "Sync To VBlank", see if things changes.

Update:

Ah, I thought about a thing! Probably I have fundamentally misunderstand VSync. Will try to implement later.

Collaborator

richardgv commented Oct 26, 2012

Very well then. I guess I've done pretty much what I could do, and eventually I have to ask somebody else. Let's hope the Xorg guys will bring us something impressive: http://lists.x.org/archives/xorg/2012-October/054996.html

Meanwhile, please check the OpenGL settings and XVideo settings in nvidia-settings, and enable their "Sync To VBlank", see if things changes.

Update:

Ah, I thought about a thing! Probably I have fundamentally misunderstand VSync. Will try to implement later.

@richardgv richardgv closed this in 66e6157 Oct 26, 2012

@richardgv richardgv reopened this Oct 26, 2012

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 26, 2012

Collaborator

Ah, GitHub, you are way too smart again!

Now please clone from richardgv-dev branch and test. I hope this commit could at least have some positive effects. The software VSync does not work as VSync, I believe, so it has been turned into --sw-opti (Software optimization), the syntax of the rest stays the same.

Collaborator

richardgv commented Oct 26, 2012

Ah, GitHub, you are way too smart again!

Now please clone from richardgv-dev branch and test. I hope this commit could at least have some positive effects. The software VSync does not work as VSync, I believe, so it has been turned into --sw-opti (Software optimization), the syntax of the rest stays the same.

@uzvermode

This comment has been minimized.

Show comment
Hide comment
@uzvermode

uzvermode Oct 26, 2012

With --vsync opengl --sw-opti options, even in video players (vdpau, xv) and flash, it's tears only on top of screen where my panel situated ^^. Great work:)
It's interesting the same problem in Kwin(4.8,4.9.1,4.9.2)https://bugs.kde.org/show_bug.cgi?id=307965

uzvermode commented Oct 26, 2012

With --vsync opengl --sw-opti options, even in video players (vdpau, xv) and flash, it's tears only on top of screen where my panel situated ^^. Great work:)
It's interesting the same problem in Kwin(4.8,4.9.1,4.9.2)https://bugs.kde.org/show_bug.cgi?id=307965

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Oct 26, 2012

Collaborator

Thanks for your test, and your link. So all my efforts result in a situation not much better than the Xfce patch? Now I truly have no idea how to get rid of the tearing...

Have you actually tried --dbe after the commit, then? It would be depressing if --dbe --vsync opengl still has the tearing issue. Moving line 1727 in src/compton.c might slightly move the line closer to the top in non-DBE mode, but I want to see how DBE works firstly.

Kwin, when using XRender as backend, does not seem to even have VSync; its OpenGL backend probably uses double buffering (or triple buffering, etc.), which could have better performance than the X DBE double buffering, so if even Kwin with OpenGL backend is doing tearing... Oh, well, let's see what reply my question posted on Xorg mailing list will receive firstly before trying to decide anything.

By the way, haven't I warned that --vsync XXX and --sw-opti shouldn't be used together in the commit log? Effectively it generally causes no additional speed benefits but frame dropping.

By the way 2, have you actually looked into nvidia-settings as I recommended in one of the previous replies?

Collaborator

richardgv commented Oct 26, 2012

Thanks for your test, and your link. So all my efforts result in a situation not much better than the Xfce patch? Now I truly have no idea how to get rid of the tearing...

Have you actually tried --dbe after the commit, then? It would be depressing if --dbe --vsync opengl still has the tearing issue. Moving line 1727 in src/compton.c might slightly move the line closer to the top in non-DBE mode, but I want to see how DBE works firstly.

Kwin, when using XRender as backend, does not seem to even have VSync; its OpenGL backend probably uses double buffering (or triple buffering, etc.), which could have better performance than the X DBE double buffering, so if even Kwin with OpenGL backend is doing tearing... Oh, well, let's see what reply my question posted on Xorg mailing list will receive firstly before trying to decide anything.

By the way, haven't I warned that --vsync XXX and --sw-opti shouldn't be used together in the commit log? Effectively it generally causes no additional speed benefits but frame dropping.

By the way 2, have you actually looked into nvidia-settings as I recommended in one of the previous replies?

@uzvermode

This comment has been minimized.

Show comment
Hide comment
@uzvermode

uzvermode Oct 26, 2012

Oops) nvidia-settings all vsync(xv, opengl)

--sw-opti (with / without dbe)

tearing whole screen

--vsync opengl (with / without dbe)

top of screen trearing, 10...18 px i think

uzvermode commented Oct 26, 2012

Oops) nvidia-settings all vsync(xv, opengl)

--sw-opti (with / without dbe)

tearing whole screen

--vsync opengl (with / without dbe)

top of screen trearing, 10...18 px i think

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 16, 2013

@richardgv:

Thanks for your quick and elaborated answer!
I'm using a GTX 660 with driver 325.15 on openbox standalone.
I now disabled Sync to VBlank in nvidia-settings as it doesn't seem to be needed at all. That didn't change anything at first. Then I replaced --vsync opengl-swc with --vsync opengl and normal videos (around 30fps) don't produce any lagging anymore. Additionally Flash videos in Firefox don't slow down the scrolling anymore.
The odd thing is, 60fps videos work fine at first as well. But after a short time playing, any 60fps video produces heavy window movement lags even though normal videos are still unaffected. I need to kill and restart compton several times to get rid of that but it happens again after playing any 60fps video for a short time.
Very odd. The only "fancy" feature of compton I'm using is shadows (no blur or fade etc.). I've tried turning that off, leaving an empty compton.conf file but that didn't change anything.

Here's a free 60fps video if you want to try reproducing it: http://www.nostro.fr/AMV/Nostromo_-_Distant_Echo_720p@60_8b.mp4

For comparison I tested on an Intel HD 4000 with mplayer -vo=gl and compton: No lagging, not even with 60fps videos. Neither with --vsync opengl-swc nor with --vsync opengl. This setup runs perfect.

M4he commented Sep 16, 2013

@richardgv:

Thanks for your quick and elaborated answer!
I'm using a GTX 660 with driver 325.15 on openbox standalone.
I now disabled Sync to VBlank in nvidia-settings as it doesn't seem to be needed at all. That didn't change anything at first. Then I replaced --vsync opengl-swc with --vsync opengl and normal videos (around 30fps) don't produce any lagging anymore. Additionally Flash videos in Firefox don't slow down the scrolling anymore.
The odd thing is, 60fps videos work fine at first as well. But after a short time playing, any 60fps video produces heavy window movement lags even though normal videos are still unaffected. I need to kill and restart compton several times to get rid of that but it happens again after playing any 60fps video for a short time.
Very odd. The only "fancy" feature of compton I'm using is shadows (no blur or fade etc.). I've tried turning that off, leaving an empty compton.conf file but that didn't change anything.

Here's a free 60fps video if you want to try reproducing it: http://www.nostro.fr/AMV/Nostromo_-_Distant_Echo_720p@60_8b.mp4

For comparison I tested on an Intel HD 4000 with mplayer -vo=gl and compton: No lagging, not even with 60fps videos. Neither with --vsync opengl-swc nor with --vsync opengl. This setup runs perfect.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 17, 2013

Collaborator

@M4he:

I now disabled Sync to VBlank in nvidia-settings as it doesn't seem to be needed at all. That didn't change anything at first. Then I replaced --vsync opengl-swc with --vsync opengl and normal videos (around 30fps) don't produce any lagging anymore. Additionally Flash videos in Firefox don't slow down the scrolling anymore.
The odd thing is, 60fps videos work fine at first as well. But after a short time playing, any 60fps video produces heavy window movement lags even though normal videos are still unaffected. I need to kill and restart compton several times to get rid of that but it happens again after playing any 60fps video for a short time.
Very odd. The only "fancy" feature of compton I'm using is shadows (no blur or fade etc.). I've tried turning that off, leaving an empty compton.conf file but that didn't change anything.

  1. One possibility is compton or something compton calls is slowly leaking resources. If the slowdown issue doesn't occur without --vsync (actually the changes after switching to --vsync=opengl already somehow confirms this), we could mostly exclude the possibility. (Although, the VSync code may leak things, but then the issue is more likely on the driver side.) Typically phenomenons are high CPU usage on X / compton process or high GPU / memory usage.
  2. Another possibility is some sort of delay is gradually accumulating... I have no idea why it would occur. Unless you see high CPU/GPU usage, the issue is more possibly in the driver.
  3. Is the delay longer than 1/60 second?

Here's a free 60fps video if you want to try reproducing it: http://www.nostro.fr/AMV/Nostromo_-_Distant_Echo_720p@60_8b.mp4

160MB! I will test it when I'm back home.

And my recommendations are still: Play with your driver settings (nvidia-settings, .drirc, xorg.conf), and try other video outputs (vdpau, vaapi, x11).

Collaborator

richardgv commented Sep 17, 2013

@M4he:

I now disabled Sync to VBlank in nvidia-settings as it doesn't seem to be needed at all. That didn't change anything at first. Then I replaced --vsync opengl-swc with --vsync opengl and normal videos (around 30fps) don't produce any lagging anymore. Additionally Flash videos in Firefox don't slow down the scrolling anymore.
The odd thing is, 60fps videos work fine at first as well. But after a short time playing, any 60fps video produces heavy window movement lags even though normal videos are still unaffected. I need to kill and restart compton several times to get rid of that but it happens again after playing any 60fps video for a short time.
Very odd. The only "fancy" feature of compton I'm using is shadows (no blur or fade etc.). I've tried turning that off, leaving an empty compton.conf file but that didn't change anything.

  1. One possibility is compton or something compton calls is slowly leaking resources. If the slowdown issue doesn't occur without --vsync (actually the changes after switching to --vsync=opengl already somehow confirms this), we could mostly exclude the possibility. (Although, the VSync code may leak things, but then the issue is more likely on the driver side.) Typically phenomenons are high CPU usage on X / compton process or high GPU / memory usage.
  2. Another possibility is some sort of delay is gradually accumulating... I have no idea why it would occur. Unless you see high CPU/GPU usage, the issue is more possibly in the driver.
  3. Is the delay longer than 1/60 second?

Here's a free 60fps video if you want to try reproducing it: http://www.nostro.fr/AMV/Nostromo_-_Distant_Echo_720p@60_8b.mp4

160MB! I will test it when I'm back home.

And my recommendations are still: Play with your driver settings (nvidia-settings, .drirc, xorg.conf), and try other video outputs (vdpau, vaapi, x11).

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 21, 2013

So, I did some very thorough testing: https://docs.google.com/spreadsheet/ccc?key=0AjhHjzQIZ8LjdDBDU1ZNemJUQ2daUVRFaG00M1BBT0E&usp=sharing
For reference here's my xorg.conf: http://pastebin.com/tS8xCLFm

Although --vsync opengl seemed to do the trick at first, it occasionally shows tearing at the upper screen edge. According to the test results, there seems to be no noticeable difference between compton's opengl-swc VSync and nvidia's VSync.
XV output is a no-go because of its random micro-stutter during playback. GL has issues with 60fps and window movement.
VDPAU seems to be the best choice. Window movement is not entirely smooth but it has no major drawbacks.

The Intel HD 4000 runs perfectly no matter the setting (everything is smooth; much less Xorg cpu load).

M4he commented Sep 21, 2013

So, I did some very thorough testing: https://docs.google.com/spreadsheet/ccc?key=0AjhHjzQIZ8LjdDBDU1ZNemJUQ2daUVRFaG00M1BBT0E&usp=sharing
For reference here's my xorg.conf: http://pastebin.com/tS8xCLFm

Although --vsync opengl seemed to do the trick at first, it occasionally shows tearing at the upper screen edge. According to the test results, there seems to be no noticeable difference between compton's opengl-swc VSync and nvidia's VSync.
XV output is a no-go because of its random micro-stutter during playback. GL has issues with 60fps and window movement.
VDPAU seems to be the best choice. Window movement is not entirely smooth but it has no major drawbacks.

The Intel HD 4000 runs perfectly no matter the setting (everything is smooth; much less Xorg cpu load).

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 21, 2013

Okay, VDPAU isn't a choice either.
When mplayer is playing through VDPAU on openbox's workspace 1 and I switch from workspace 1 to workspace 2 and back, the screen and mplayer freezes. I can get the screen back if I attempt to switch workspaces a few times again (using keyboard) but mplayer stays frozen while only displaying the part of the wallpaper below and needs to be killed.
Now I'm back to square one...

M4he commented Sep 21, 2013

Okay, VDPAU isn't a choice either.
When mplayer is playing through VDPAU on openbox's workspace 1 and I switch from workspace 1 to workspace 2 and back, the screen and mplayer freezes. I can get the screen back if I attempt to switch workspaces a few times again (using keyboard) but mplayer stays frozen while only displaying the part of the wallpaper below and needs to be killed.
Now I'm back to square one...

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 21, 2013

Collaborator

@M4he:

Ah, sorry, I entirely forgot this issue after I got home...

When X starts occupying 100% of a core, disasters will generally start to appear. I would recommend a system-wide profiling in the case to figure out what's wrong.

Flash is a true nightmare. And you may consider it normal to see delay when you scroll a page with Flash -- it typically uses much of your CPU.

I will see what I could do about shadow generation to reduce the cost of window resizing (note, I do not know if it works for moving).

Collaborator

richardgv commented Sep 21, 2013

@M4he:

Ah, sorry, I entirely forgot this issue after I got home...

When X starts occupying 100% of a core, disasters will generally start to appear. I would recommend a system-wide profiling in the case to figure out what's wrong.

Flash is a true nightmare. And you may consider it normal to see delay when you scroll a page with Flash -- it typically uses much of your CPU.

I will see what I could do about shadow generation to reduce the cost of window resizing (note, I do not know if it works for moving).

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 22, 2013

@richardgv:

You don't need to. Even if I drop the shadow option everything behaves the same.
I also tried booting without any xorg.conf - no luck.

I think the problem is, that the GL and compositing synchronization of the nvidia drivers is a complete joke.
For testing I just replaced my nvidia drivers with the intel ones, plugged in my screen at the mainboard and switched to the Intel HD 2500 integrated in my cpu: compton --opengl --paint-on-overlay without any additional options (no VSync option!): everything is so super smooth, no tearing, no lag not even the slightest. Moving mplayer window (vo=gl) with 60fps video: X uses 10% cpu (compare 90 - 100% on nvidia using vo=gl). This is the kind of performance one would expect from modern hardware - the intel chips makes it feel like it's 10 times better than my GTX 660 lol.
Too bad it's such a hassle to reconnect the plug everytime and set the bios option to switch cards.

If I wouldn't need the card on Windows this would be the point where I'd sell it together with my current cpu and get the HD 4000 version of the core i5.

M4he commented Sep 22, 2013

@richardgv:

You don't need to. Even if I drop the shadow option everything behaves the same.
I also tried booting without any xorg.conf - no luck.

I think the problem is, that the GL and compositing synchronization of the nvidia drivers is a complete joke.
For testing I just replaced my nvidia drivers with the intel ones, plugged in my screen at the mainboard and switched to the Intel HD 2500 integrated in my cpu: compton --opengl --paint-on-overlay without any additional options (no VSync option!): everything is so super smooth, no tearing, no lag not even the slightest. Moving mplayer window (vo=gl) with 60fps video: X uses 10% cpu (compare 90 - 100% on nvidia using vo=gl). This is the kind of performance one would expect from modern hardware - the intel chips makes it feel like it's 10 times better than my GTX 660 lol.
Too bad it's such a hassle to reconnect the plug everytime and set the bios option to switch cards.

If I wouldn't need the card on Windows this would be the point where I'd sell it together with my current cpu and get the HD 4000 version of the core i5.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 22, 2013

Collaborator

@M4he:

Let's say that nvidia-drivers performed almost perfectly on GTX 670 (home computer) and GTX 650 (work computer) in my experiences. Performance is superb, the library is stable (unless I write some broken code...), X acceleration is reliable (check the shit in nouveau!), supported GL version is much higher than the open-source ones, power saving is decent (I once burnt my Geforce 8800 GT because of nouveau). If there's anything I could complain, it's lack of KMS support (no wayland & slow to switch between virtual consoles and X) and being closed-source (so it's tricky to debug inside libGL). The fact that I hardly watch videos may affect my impressions, though, but nvidia-drivers never depressed me when I do -- no tearing have I ever seen. (And I've heard far more reports of tearing with Intel chipsets than nVidia cards.)

I found a bit surprising that nvidia-driver-325.15 seemingly causes X to use 100% CPU usage when moving a mpv window with -vo=opengl, because I noticed no lagging whatsoever (well, thus I never thought it happens on my computer!). Further analysis revealed it's probably not entirely true that the CPU is "occupied". System-wide profiling shows delay_tsc and certain other functions in nvidia-drivers are using most of the CPU, but they are supposed to the idling/waiting functions. The output of sar, dstat, and top indicates the CPU is not actually occupied (almost always more than 90% idle) even when conky and pidstat show extreme CPU usage of the X process. I don't know much about how the kernel and CPU works, but I guess the issue perhaps not in how nvidia-drivers occupies CPU, but how it incorrectly synchronizes a compositor and an OpenGL application. (Another evidence is, glxgears running a 60Hz is extremely laggy to move here as well, but my system is capable to paint more than 35,000 frames per second when VSync in driver is turned off. Heh, then why moving a mpv -vo=opengl window here doesn't lag?)

By the way, I tried improving GLX shadow texture generation, but it perhaps performed badly since glTexImage2D() looks very slow on nvidia-drivers-325.15.

Collaborator

richardgv commented Sep 22, 2013

@M4he:

Let's say that nvidia-drivers performed almost perfectly on GTX 670 (home computer) and GTX 650 (work computer) in my experiences. Performance is superb, the library is stable (unless I write some broken code...), X acceleration is reliable (check the shit in nouveau!), supported GL version is much higher than the open-source ones, power saving is decent (I once burnt my Geforce 8800 GT because of nouveau). If there's anything I could complain, it's lack of KMS support (no wayland & slow to switch between virtual consoles and X) and being closed-source (so it's tricky to debug inside libGL). The fact that I hardly watch videos may affect my impressions, though, but nvidia-drivers never depressed me when I do -- no tearing have I ever seen. (And I've heard far more reports of tearing with Intel chipsets than nVidia cards.)

I found a bit surprising that nvidia-driver-325.15 seemingly causes X to use 100% CPU usage when moving a mpv window with -vo=opengl, because I noticed no lagging whatsoever (well, thus I never thought it happens on my computer!). Further analysis revealed it's probably not entirely true that the CPU is "occupied". System-wide profiling shows delay_tsc and certain other functions in nvidia-drivers are using most of the CPU, but they are supposed to the idling/waiting functions. The output of sar, dstat, and top indicates the CPU is not actually occupied (almost always more than 90% idle) even when conky and pidstat show extreme CPU usage of the X process. I don't know much about how the kernel and CPU works, but I guess the issue perhaps not in how nvidia-drivers occupies CPU, but how it incorrectly synchronizes a compositor and an OpenGL application. (Another evidence is, glxgears running a 60Hz is extremely laggy to move here as well, but my system is capable to paint more than 35,000 frames per second when VSync in driver is turned off. Heh, then why moving a mpv -vo=opengl window here doesn't lag?)

By the way, I tried improving GLX shadow texture generation, but it perhaps performed badly since glTexImage2D() looks very slow on nvidia-drivers-325.15.

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 22, 2013

I just tried out mpv 0.1.7 with -vo=opengl but it behaves just the same as mplayer.
And yea, moving the glxgears window does lag as heavy as a 60fps video played in mplayer/mpv with GL output, though it's showing fps values around 60 (using nvidia's VSync and compton without any --vsync option).
When using compton's --vsync opengl-swc without nvidia's vsync however, glxgears window movement doesn't lag as much and glxgears produces much higher fps (~23,000). Without VSync/compositing, glxgears reaches around 30,000.

By the way, is compton's refresh rate locked to 60fps somehow? I recall setting compiz to 120 once because it performed smoother than with 60 during window movement.

M4he commented Sep 22, 2013

I just tried out mpv 0.1.7 with -vo=opengl but it behaves just the same as mplayer.
And yea, moving the glxgears window does lag as heavy as a 60fps video played in mplayer/mpv with GL output, though it's showing fps values around 60 (using nvidia's VSync and compton without any --vsync option).
When using compton's --vsync opengl-swc without nvidia's vsync however, glxgears window movement doesn't lag as much and glxgears produces much higher fps (~23,000). Without VSync/compositing, glxgears reaches around 30,000.

By the way, is compton's refresh rate locked to 60fps somehow? I recall setting compiz to 120 once because it performed smoother than with 60 during window movement.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 23, 2013

Collaborator

@M4he:

Today I reproduced exactly what you reported: It happens here when either "Sync to VBlank" is turned on in nvidia-settings or I used --vsync opengl-swc. --vsync=opengl does limit painting to 60Hz according to --benchmark results but does not cause the issue. A 60 FPS video makes this more severe. Only one point is different: I see tearing in no cases. I have not the slightest idea why during all my previous tests I've never noticed the lagging... How did you manage to affect my computer? :-D

I started using sysbench --test=cpu --num-threads=8 --cpu-max-prime=50000 to measure the occupied CPU percentage. I use compton-git-v0.1_beta1-14-g4bd3db2-2013-09-18 with compton.sample.conf and -b --logpath /tmp/compton.log --backend glx --paint-on-overlay --blur-background --glx-no-stencil --glx-no-rebind-pixmap. "Sync To VBlank" turned on in nvidia-settings. My experiments:

  1. The normal result is around 10.8 seconds;
  2. A paused mpv window alone doesn't bring much changes, with -vo=vdpau or -vo=opengl.
  3. Moving a gVim window around very fast: 11.05s.
  4. Moving a paused mpv window with -vo=vdpau: 11.7s. No lag in video playback or window movement.
  5. A mpv window with -vo=vdpau playing a 1080P movie (resized pretty small): 11.5s, No issue;
  6. Moving a mpv window with -vo=vdpau playing the movie: 12.9s, No issue;
  7. Moving a paused mpv window with -vo=opengl: 11.7s, no issue.
  8. A mpv window with -vo=opengl playing the movie: 11.47s, no issue;
  9. Moving a mpv window with -vo=opengl playing the movie: 12.75s, lag in window movement. Killing sysbench doesn't bring noticeable changes.

Conclusion: It only slows down when both compton and mpv are updating window content with OpenGL. It performs well when all CPUs are completely occupied. There's no evidence indicating -vo=opengl is more CPU-hogging or the CPU usage lead to to the lag whatsoever.

When I dig into the source code of mpv and vlc I discovered a thing: They both try to call glXSwapInterval() for VSync as well. So I patched their sources to disable it:

(Although it says mpv-0.1.6, the patch does work for 0.1.7.)

--- mpv-0.1.6/video/out/vo_opengl.c~    2013-09-14 04:03:30.000000000 +0800
+++ mpv-0.1.6/video/out/vo_opengl.c 2013-09-23 23:06:27.979974201 +0800
@@ -316,9 +316,6 @@

     mpgl_set_context(p->glctx);

-    if (p->gl->SwapInterval)
-        p->gl->SwapInterval(p->swap_interval);
-
     p->renderer = gl_video_init(p->gl, vo->log);
     gl_video_set_output_depth(p->renderer, p->glctx->depth_r, p->glctx->depth_g,
                               p->glctx->depth_b);
--- vlc-2.0.7/modules/video_output/xcb/glx.c~   2013-09-23 23:19:59.789972521 +0800
+++ vlc-2.0.7/modules/video_output/xcb/glx.c    2013-09-23 23:20:05.779972509 +0800
@@ -369,25 +369,6 @@

     const char *glx_extensions = glXQueryExtensionsString (dpy, snum);

-    bool is_swap_interval_set = false;
-#ifdef GLX_SGI_swap_control
-    if (HasExtension (glx_extensions, "GLX_SGI_swap_control")) {
-        PFNGLXSWAPINTERVALSGIPROC SwapIntervalSGI = (PFNGLXSWAPINTERVALSGIPROC)GetProcAddress (NULL, "glXSwapIntervalSGI");
-        if (!is_swap_interval_set && SwapIntervalSGI)
-            is_swap_interval_set = !SwapIntervalSGI (1);
-    }
-#endif
-#ifdef GLX_EXT_swap_control
-    if (HasExtension (glx_extensions, "GLX_EXT_swap_control")) {
-        PFNGLXSWAPINTERVALEXTPROC SwapIntervalEXT = (PFNGLXSWAPINTERVALEXTPROC)GetProcAddress (NULL, "glXSwapIntervalEXT");
-        if (!is_swap_interval_set && SwapIntervalEXT)
-        {
-            SwapIntervalEXT (dpy, sys->glwin, 1);
-            is_swap_interval_set = true;
-        }
-    }
-#endif
-
     /* Initialize common OpenGL video display */
     sys->gl.lock = NULL;
     sys->gl.unlock = NULL;

Then, the problem is gone, at least here, if I disable "Sync To VBlank" in nvidia-drivers but use --vsync=opengl-swc on compton. I have no idea if it would cause tearing on your side, though.

So, probably nvidia-drivers doesn't like a compositor using SGI_swap_control working with a client using SGI_swap_control as well, and handled the synchronization improperly. You may forward the info to the nVidia guys, to see if they could do anything.

By the way, is compton's refresh rate locked to 60fps somehow? I recall setting compiz to 120 once because it performed smoother than with 60 during window movement.

Unless you have VSync set in drivers or --vsync or --sw-opti, compton paints whenever there's a demand, as fast as 4370 full-screen repaints per second here. How much frames compton actively paints per second could be measured with the method describes in Performance guide. However even though compton paints that much a second, when and which frames are sent to video card and to the 60Hz screen is beyond our control, and the GPU may be processing less frames.

Collaborator

richardgv commented Sep 23, 2013

@M4he:

Today I reproduced exactly what you reported: It happens here when either "Sync to VBlank" is turned on in nvidia-settings or I used --vsync opengl-swc. --vsync=opengl does limit painting to 60Hz according to --benchmark results but does not cause the issue. A 60 FPS video makes this more severe. Only one point is different: I see tearing in no cases. I have not the slightest idea why during all my previous tests I've never noticed the lagging... How did you manage to affect my computer? :-D

I started using sysbench --test=cpu --num-threads=8 --cpu-max-prime=50000 to measure the occupied CPU percentage. I use compton-git-v0.1_beta1-14-g4bd3db2-2013-09-18 with compton.sample.conf and -b --logpath /tmp/compton.log --backend glx --paint-on-overlay --blur-background --glx-no-stencil --glx-no-rebind-pixmap. "Sync To VBlank" turned on in nvidia-settings. My experiments:

  1. The normal result is around 10.8 seconds;
  2. A paused mpv window alone doesn't bring much changes, with -vo=vdpau or -vo=opengl.
  3. Moving a gVim window around very fast: 11.05s.
  4. Moving a paused mpv window with -vo=vdpau: 11.7s. No lag in video playback or window movement.
  5. A mpv window with -vo=vdpau playing a 1080P movie (resized pretty small): 11.5s, No issue;
  6. Moving a mpv window with -vo=vdpau playing the movie: 12.9s, No issue;
  7. Moving a paused mpv window with -vo=opengl: 11.7s, no issue.
  8. A mpv window with -vo=opengl playing the movie: 11.47s, no issue;
  9. Moving a mpv window with -vo=opengl playing the movie: 12.75s, lag in window movement. Killing sysbench doesn't bring noticeable changes.

Conclusion: It only slows down when both compton and mpv are updating window content with OpenGL. It performs well when all CPUs are completely occupied. There's no evidence indicating -vo=opengl is more CPU-hogging or the CPU usage lead to to the lag whatsoever.

When I dig into the source code of mpv and vlc I discovered a thing: They both try to call glXSwapInterval() for VSync as well. So I patched their sources to disable it:

(Although it says mpv-0.1.6, the patch does work for 0.1.7.)

--- mpv-0.1.6/video/out/vo_opengl.c~    2013-09-14 04:03:30.000000000 +0800
+++ mpv-0.1.6/video/out/vo_opengl.c 2013-09-23 23:06:27.979974201 +0800
@@ -316,9 +316,6 @@

     mpgl_set_context(p->glctx);

-    if (p->gl->SwapInterval)
-        p->gl->SwapInterval(p->swap_interval);
-
     p->renderer = gl_video_init(p->gl, vo->log);
     gl_video_set_output_depth(p->renderer, p->glctx->depth_r, p->glctx->depth_g,
                               p->glctx->depth_b);
--- vlc-2.0.7/modules/video_output/xcb/glx.c~   2013-09-23 23:19:59.789972521 +0800
+++ vlc-2.0.7/modules/video_output/xcb/glx.c    2013-09-23 23:20:05.779972509 +0800
@@ -369,25 +369,6 @@

     const char *glx_extensions = glXQueryExtensionsString (dpy, snum);

-    bool is_swap_interval_set = false;
-#ifdef GLX_SGI_swap_control
-    if (HasExtension (glx_extensions, "GLX_SGI_swap_control")) {
-        PFNGLXSWAPINTERVALSGIPROC SwapIntervalSGI = (PFNGLXSWAPINTERVALSGIPROC)GetProcAddress (NULL, "glXSwapIntervalSGI");
-        if (!is_swap_interval_set && SwapIntervalSGI)
-            is_swap_interval_set = !SwapIntervalSGI (1);
-    }
-#endif
-#ifdef GLX_EXT_swap_control
-    if (HasExtension (glx_extensions, "GLX_EXT_swap_control")) {
-        PFNGLXSWAPINTERVALEXTPROC SwapIntervalEXT = (PFNGLXSWAPINTERVALEXTPROC)GetProcAddress (NULL, "glXSwapIntervalEXT");
-        if (!is_swap_interval_set && SwapIntervalEXT)
-        {
-            SwapIntervalEXT (dpy, sys->glwin, 1);
-            is_swap_interval_set = true;
-        }
-    }
-#endif
-
     /* Initialize common OpenGL video display */
     sys->gl.lock = NULL;
     sys->gl.unlock = NULL;

Then, the problem is gone, at least here, if I disable "Sync To VBlank" in nvidia-drivers but use --vsync=opengl-swc on compton. I have no idea if it would cause tearing on your side, though.

So, probably nvidia-drivers doesn't like a compositor using SGI_swap_control working with a client using SGI_swap_control as well, and handled the synchronization improperly. You may forward the info to the nVidia guys, to see if they could do anything.

By the way, is compton's refresh rate locked to 60fps somehow? I recall setting compiz to 120 once because it performed smoother than with 60 during window movement.

Unless you have VSync set in drivers or --vsync or --sw-opti, compton paints whenever there's a demand, as fast as 4370 full-screen repaints per second here. How much frames compton actively paints per second could be measured with the method describes in Performance guide. However even though compton paints that much a second, when and which frames are sent to video card and to the 60Hz screen is beyond our control, and the GPU may be processing less frames.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 24, 2013

Collaborator

@M4he:

(In addition to the things above...)

You may wish to check if applying this patch on compton is useful, if patching mpv and vlc doesn't help:

diff --git a/src/compton.c b/src/compton.c
index 511083c..9bd4f87 100644
--- a/src/compton.c
+++ b/src/compton.c
@@ -1890,12 +1890,6 @@ paint_all(session_t *ps, XserverRegion region, XserverRegion region_real, win *t
     // Make sure all previous requests are processed to achieve best
     // effect
     XSync(ps->dpy, False);
-#ifdef CONFIG_VSYNC_OPENGL
-    if (ps->glx_context) {
-      glFlush();
-      glXWaitX();
-    }
-#endif
   }

   // Wait for VBlank. We could do it aggressively (send the painting
@@ -1941,13 +1935,6 @@ paint_all(session_t *ps, XserverRegion region, XserverRegion region_real, win *t

   XFlush(ps->dpy);

-#ifdef CONFIG_VSYNC_OPENGL
-  if (ps->glx_context) {
-    glFlush();
-    glXWaitX();
-  }
-#endif
-
   XFixesDestroyRegion(ps->dpy, region);

 #ifdef DEBUG_REPAINT

Turn off VSync in nvidia-settings but enable it with --vsync opengl-swc may produce the best result.

Collaborator

richardgv commented Sep 24, 2013

@M4he:

(In addition to the things above...)

You may wish to check if applying this patch on compton is useful, if patching mpv and vlc doesn't help:

diff --git a/src/compton.c b/src/compton.c
index 511083c..9bd4f87 100644
--- a/src/compton.c
+++ b/src/compton.c
@@ -1890,12 +1890,6 @@ paint_all(session_t *ps, XserverRegion region, XserverRegion region_real, win *t
     // Make sure all previous requests are processed to achieve best
     // effect
     XSync(ps->dpy, False);
-#ifdef CONFIG_VSYNC_OPENGL
-    if (ps->glx_context) {
-      glFlush();
-      glXWaitX();
-    }
-#endif
   }

   // Wait for VBlank. We could do it aggressively (send the painting
@@ -1941,13 +1935,6 @@ paint_all(session_t *ps, XserverRegion region, XserverRegion region_real, win *t

   XFlush(ps->dpy);

-#ifdef CONFIG_VSYNC_OPENGL
-  if (ps->glx_context) {
-    glFlush();
-    glXWaitX();
-  }
-#endif
-
   XFixesDestroyRegion(ps->dpy, region);

 #ifdef DEBUG_REPAINT

Turn off VSync in nvidia-settings but enable it with --vsync opengl-swc may produce the best result.

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 24, 2013

@richardgv:

Thank you very much for your thorough research and detailed explanations!
I just tested the patched mpv together with compton --opengl --vsync opengl-swc --paint-on-overlay and "Sync to VBlank" turned off in nvidia-settings. I'll still need to conduct further testing when I get back home but from what I've just tested this patch seems to be the salvation! I spotted no tearing or lagging whatsoever playing various 720p and 1080p stuff including 60fps content.

  1. If this proves to be the solution I'll make sure to contact nvidia regarding the SWI_swap_control like you suggested!
  2. Does removing above lines in the code of said players have any drawbacks? I didn't spot anything bad even without any compositor running during some quick tests.
  3. Related to (2.), would it be of any use to contact the devs of said players regarding this?

When I get back, I'll test the patched mpv on Gnome as well and see if it solves the lagging there too while retaining vsync.

Once again, thanks for all your efforts and the hard work!
I take my hat off to you, you really know your stuff.

M4he commented Sep 24, 2013

@richardgv:

Thank you very much for your thorough research and detailed explanations!
I just tested the patched mpv together with compton --opengl --vsync opengl-swc --paint-on-overlay and "Sync to VBlank" turned off in nvidia-settings. I'll still need to conduct further testing when I get back home but from what I've just tested this patch seems to be the salvation! I spotted no tearing or lagging whatsoever playing various 720p and 1080p stuff including 60fps content.

  1. If this proves to be the solution I'll make sure to contact nvidia regarding the SWI_swap_control like you suggested!
  2. Does removing above lines in the code of said players have any drawbacks? I didn't spot anything bad even without any compositor running during some quick tests.
  3. Related to (2.), would it be of any use to contact the devs of said players regarding this?

When I get back, I'll test the patched mpv on Gnome as well and see if it solves the lagging there too while retaining vsync.

Once again, thanks for all your efforts and the hard work!
I take my hat off to you, you really know your stuff.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 24, 2013

Collaborator

@M4he:

If this proves to be the solution I'll make sure to contact nvidia regarding the SWI_swap_control like you suggested!

I would recommend to try patching compton with the the patch in my last reply, to check if it has something to do with my usage of glXWaitX() . Within my current tests it has no effect (I guess I got the wrong result a few hours back because your test video made me feel dizzy... :-D ).

Does removing above lines in the code of said players have any drawbacks? I didn't spot anything bad even without any compositor running during some quick tests.

Huh, I don't know. Theoretically it may lead to certain frames being dropped if the timing is inappropriate.

Related to (2.), would it be of any use to contact the devs of said players regarding this?

They can and should provide an option to switch VSync on/off, although I doubt if they would care about this.

Collaborator

richardgv commented Sep 24, 2013

@M4he:

If this proves to be the solution I'll make sure to contact nvidia regarding the SWI_swap_control like you suggested!

I would recommend to try patching compton with the the patch in my last reply, to check if it has something to do with my usage of glXWaitX() . Within my current tests it has no effect (I guess I got the wrong result a few hours back because your test video made me feel dizzy... :-D ).

Does removing above lines in the code of said players have any drawbacks? I didn't spot anything bad even without any compositor running during some quick tests.

Huh, I don't know. Theoretically it may lead to certain frames being dropped if the timing is inappropriate.

Related to (2.), would it be of any use to contact the devs of said players regarding this?

They can and should provide an option to switch VSync on/off, although I doubt if they would care about this.

@antcodd

This comment has been minimized.

Show comment
Hide comment
@antcodd

antcodd Sep 24, 2013

@richardgv

I also find that vsync on in more than one place of compton/mpv/nvidia tends to cause lots of frame stuttering. This is even with 23.976 fps video at 47.952Hz.

They can and should provide an option to switch VSync on/off, although I doubt if they would care about this.

Note that mpv vo=opengl/opengl-hq has a swapinterval=<n> option which should disable all vsync when set to 0. I find this gets rid of most of the juddering, especially when compton is in opengl-swc mode.

You may wish to check if applying this patch on compton is useful, if patching mpv and vlc doesn't help

I think this patch might be helping a little but it is really hard to tell. The trouble is with vsync off mpv is probably essentially 'freewheeling' so stuttering issues can occur when the first frame start is at an odd point in the refresh cycle. This tends to happen for me every 5-10 seeks and significantly moreso with swapinterval=1.

I notice with compton off, swapinterval=1 (default) in mpv I get tearing only on my second monitor (the 1080p one), contradictory to what nvidia-settings says is the monitor it is vsyncing to. So long as the composite extension is enabled (which I can't disable without hacking gnome-session despite not using gnome shell and obviously can't use compton with) I can't find any combination of vsync settings in nvidia or mpv to make it work. Amazingly compton in opengl/opengl-swc seems to be the one thing that correctly vsyncs on both monitors!

By the way does compton properly support multiple monitors and changing refresh rates? I have a script that automatically changes refresh rate of my second monitor with xrandr to a multiple of the video refresh rate before playback starts. I think it is working but it's hard to tell with the intermittent stuttering problems.

It would be fantastic to get this issue resolved one way or another and finally have stutter and tear free video output. Vsync is such a nightmare on Linux!

antcodd commented Sep 24, 2013

@richardgv

I also find that vsync on in more than one place of compton/mpv/nvidia tends to cause lots of frame stuttering. This is even with 23.976 fps video at 47.952Hz.

They can and should provide an option to switch VSync on/off, although I doubt if they would care about this.

Note that mpv vo=opengl/opengl-hq has a swapinterval=<n> option which should disable all vsync when set to 0. I find this gets rid of most of the juddering, especially when compton is in opengl-swc mode.

You may wish to check if applying this patch on compton is useful, if patching mpv and vlc doesn't help

I think this patch might be helping a little but it is really hard to tell. The trouble is with vsync off mpv is probably essentially 'freewheeling' so stuttering issues can occur when the first frame start is at an odd point in the refresh cycle. This tends to happen for me every 5-10 seeks and significantly moreso with swapinterval=1.

I notice with compton off, swapinterval=1 (default) in mpv I get tearing only on my second monitor (the 1080p one), contradictory to what nvidia-settings says is the monitor it is vsyncing to. So long as the composite extension is enabled (which I can't disable without hacking gnome-session despite not using gnome shell and obviously can't use compton with) I can't find any combination of vsync settings in nvidia or mpv to make it work. Amazingly compton in opengl/opengl-swc seems to be the one thing that correctly vsyncs on both monitors!

By the way does compton properly support multiple monitors and changing refresh rates? I have a script that automatically changes refresh rate of my second monitor with xrandr to a multiple of the video refresh rate before playback starts. I think it is working but it's hard to tell with the intermittent stuttering problems.

It would be fantastic to get this issue resolved one way or another and finally have stutter and tear free video output. Vsync is such a nightmare on Linux!

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 24, 2013

Collaborator

@antcodd:

Note that mpv vo=opengl/opengl-hq has a swapinterval=<n> option which should disable all vsync when set to 0. I find this gets rid of most of the juddering, especially when compton is in opengl-swc mode.

Aha! Apparently it was a bad idea to work at midnight. I should have noticed it.

I think this patch might be helping a little but it is really hard to tell.

So it means my call to glXWaitX() is not the cause, then. Good news!

The trouble is with vsync off mpv is probably essentially 'freewheeling' so stuttering issues can occur when the first frame start is at an odd point in the refresh cycle. This tends to happen for me every 5-10 seeks and significantly moreso with swapinterval=1.

Eee... It could happen theoretically but I've never seen it, and I didn't realize it would be that severe. Unfortunately, I doubt if I could do anything about it. It might be possible to patch mpv to use an alternative VSync method (e.g. SGI_video_sync), though.

I notice with compton off, swapinterval=1 (default) in mpv I get tearing only on my second monitor (the 1080p one), contradictory to what nvidia-settings says is the monitor it is vsyncing to. ... Amazingly compton in opengl/opengl-swc seems to be the one thing that correctly vsyncs on both monitors!

No idea why that would happen.

By the way does compton properly support multiple monitors and changing refresh rates? I have a script that automatically changes refresh rate of my second monitor with xrandr to a multiple of the video refresh rate before playback starts. I think it is working but it's hard to tell with the intermittent stuttering problems.

Compton does not detect refresh rate for VSync itself but relies on the OpenGL VSync extensions. Whether they handle refresh rate changes correctly is up to the driver. (Compton does detect refresh rate for --sw-opti, though.) Many are using compton with multiple monitors.

Collaborator

richardgv commented Sep 24, 2013

@antcodd:

Note that mpv vo=opengl/opengl-hq has a swapinterval=<n> option which should disable all vsync when set to 0. I find this gets rid of most of the juddering, especially when compton is in opengl-swc mode.

Aha! Apparently it was a bad idea to work at midnight. I should have noticed it.

I think this patch might be helping a little but it is really hard to tell.

So it means my call to glXWaitX() is not the cause, then. Good news!

The trouble is with vsync off mpv is probably essentially 'freewheeling' so stuttering issues can occur when the first frame start is at an odd point in the refresh cycle. This tends to happen for me every 5-10 seeks and significantly moreso with swapinterval=1.

Eee... It could happen theoretically but I've never seen it, and I didn't realize it would be that severe. Unfortunately, I doubt if I could do anything about it. It might be possible to patch mpv to use an alternative VSync method (e.g. SGI_video_sync), though.

I notice with compton off, swapinterval=1 (default) in mpv I get tearing only on my second monitor (the 1080p one), contradictory to what nvidia-settings says is the monitor it is vsyncing to. ... Amazingly compton in opengl/opengl-swc seems to be the one thing that correctly vsyncs on both monitors!

No idea why that would happen.

By the way does compton properly support multiple monitors and changing refresh rates? I have a script that automatically changes refresh rate of my second monitor with xrandr to a multiple of the video refresh rate before playback starts. I think it is working but it's hard to tell with the intermittent stuttering problems.

Compton does not detect refresh rate for VSync itself but relies on the OpenGL VSync extensions. Whether they handle refresh rate changes correctly is up to the driver. (Compton does detect refresh rate for --sw-opti, though.) Many are using compton with multiple monitors.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 24, 2013

Collaborator

@antcodd:

(In addition to the previous reply...)

I wrote a patch to add SGI_video_sync to mpv, as a replacement for SGI_swap_control. It does not disable SGI_swap_control automatically. Weirdly enough, I could no longer reproduce the issue after turning "Sync To VBlank" off in nvidia-settings anyhow, even with --vsync opengl-swc.

Collaborator

richardgv commented Sep 24, 2013

@antcodd:

(In addition to the previous reply...)

I wrote a patch to add SGI_video_sync to mpv, as a replacement for SGI_swap_control. It does not disable SGI_swap_control automatically. Weirdly enough, I could no longer reproduce the issue after turning "Sync To VBlank" off in nvidia-settings anyhow, even with --vsync opengl-swc.

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Sep 24, 2013

I wrote a patch to add SGI_video_sync to mpv, as a replacement for SGI_swap_control. It does not disable SGI_swap_control automatically.

So I need to apply both this patch and the one you posted earlier?

M4he commented Sep 24, 2013

I wrote a patch to add SGI_video_sync to mpv, as a replacement for SGI_swap_control. It does not disable SGI_swap_control automatically.

So I need to apply both this patch and the one you posted earlier?

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 24, 2013

Collaborator

@M4he:

So I need to apply both this patch and the one you posted earlier?

The new SGI_video_sync patch is intended to fix the stuttering issue antcodd reported when he has SGI_swap_control in mpv disabled. Unless you experience the same problem, the patch would not be necessary.

By the way, as mpv has an option swapinterval=<n> to control if SGI_swap_control is enabled, pointed out by antcodd, my previous patch on mpv is not needed, either.

Collaborator

richardgv commented Sep 24, 2013

@M4he:

So I need to apply both this patch and the one you posted earlier?

The new SGI_video_sync patch is intended to fix the stuttering issue antcodd reported when he has SGI_swap_control in mpv disabled. Unless you experience the same problem, the patch would not be necessary.

By the way, as mpv has an option swapinterval=<n> to control if SGI_swap_control is enabled, pointed out by antcodd, my previous patch on mpv is not needed, either.

@antcodd

This comment has been minimized.

Show comment
Hide comment
@antcodd

antcodd Sep 25, 2013

@richardgv

Thanks for the SGI_video_sync patch

After some more investigation I've discovered problems only tend to occur when both monitors are on, and only on the second monitor (regardless of how I set primary in xrandr I believe). The first monitor vsyncs the same as if there was a single monitor on.

On my second monitor having both swapinterval=1 and --opengl-swc does pretty much exactly the same jittering as when I apply your patch and forget to set swapinterval=0. Your patch seems to jitter for me even when compton is off, and with a single monitor, and even with swapinterval=0 so I suspect it is a little buggy in its interaction with the rest of mpv (don't think it's really worth worrying about).

I've discovered the composite extension makes no difference for me either - the critical thing is that vsync only ever happens on my first monitor if it is on. Without compton with every combination I've seen I see two tear lines (one at each 3rd of the screen) on the second monitor. With compton --opengl-swc I get vsync on both screens but juddering when vsync is on in more than one place, and occasional frame skips/jumps (less often than I remember yesterday for some reason) if I set swapinterval=0 in normal mpv. I'm pretty sure refresh rate switching is working correctly with compton.

Sometimes I think there is some micro-stuttering (delayed frames or something), but it is hard to tell with 24p video. I'm not yet convinced whether it is my imagination, or in what situations it happens though. It could easily be causee by the lack of Reclock-like functionality in mpv to sync the clocking.

For now I guess I'll just modify my script to turn off the first monitor. I'm still interested in solving this issue. I suspect it is a bug in the NVIDIA driver. It is also possible either mpv or NVIDIA is causing the vsync call blocking to be timed to the other monitor or something (two tearing lines makes me suspicious of something strange happening). One monitor is using DVI and the one I'm trying to use is HDMI by the way (HDMI-0 has it's own entry in xorg.conf with custom modelines, the other one that gets vsynced to is auto configured).

Hope that is intelligible, I got myself rather confused at one point.

antcodd commented Sep 25, 2013

@richardgv

Thanks for the SGI_video_sync patch

After some more investigation I've discovered problems only tend to occur when both monitors are on, and only on the second monitor (regardless of how I set primary in xrandr I believe). The first monitor vsyncs the same as if there was a single monitor on.

On my second monitor having both swapinterval=1 and --opengl-swc does pretty much exactly the same jittering as when I apply your patch and forget to set swapinterval=0. Your patch seems to jitter for me even when compton is off, and with a single monitor, and even with swapinterval=0 so I suspect it is a little buggy in its interaction with the rest of mpv (don't think it's really worth worrying about).

I've discovered the composite extension makes no difference for me either - the critical thing is that vsync only ever happens on my first monitor if it is on. Without compton with every combination I've seen I see two tear lines (one at each 3rd of the screen) on the second monitor. With compton --opengl-swc I get vsync on both screens but juddering when vsync is on in more than one place, and occasional frame skips/jumps (less often than I remember yesterday for some reason) if I set swapinterval=0 in normal mpv. I'm pretty sure refresh rate switching is working correctly with compton.

Sometimes I think there is some micro-stuttering (delayed frames or something), but it is hard to tell with 24p video. I'm not yet convinced whether it is my imagination, or in what situations it happens though. It could easily be causee by the lack of Reclock-like functionality in mpv to sync the clocking.

For now I guess I'll just modify my script to turn off the first monitor. I'm still interested in solving this issue. I suspect it is a bug in the NVIDIA driver. It is also possible either mpv or NVIDIA is causing the vsync call blocking to be timed to the other monitor or something (two tearing lines makes me suspicious of something strange happening). One monitor is using DVI and the one I'm trying to use is HDMI by the way (HDMI-0 has it's own entry in xorg.conf with custom modelines, the other one that gets vsynced to is auto configured).

Hope that is intelligible, I got myself rather confused at one point.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Sep 25, 2013

Collaborator

@antcodd:

Does the methods here help for you? https://wiki.archlinux.org/index.php/NVIDIA#Vertical_sync_using_TwinView

Well, I guess I can't solve your issue. It looks so complicated and it's impossible for me to reproduce it here. (I don't have a second monitor.) Maybe you could contact nVidia directly. And NVIDIA Developer Forums and nV News might be good places to ask your questions.

You are definitely not alone. Some people suggested disabling composite extension as a solution. Eeek!
https://devtalk.nvidia.com/default/topic/540730/again-tearing-problems-with-drivers-gt-300-dual-head-setup/
https://devtalk.nvidia.com/default/topic/540113/linux/video-tears-on-all-screens

My SGI_video_sync patch is intended to be used with swapinterval=0. Applying double VSync most likely will cause troubles. Adding glFlush() and glXWaitX() before VSync might be helpful, but not too likely.

I suppose that probably you overestimated the importance of mpv in this process. As a video player, mpv should not and does not care about refresh rate, as far as I know. I believe its timing is based on video/audio frames, and it calls select() to wait for next frame and other inputs, which has nothing to do with GPU. Look around line 2700, run_playloop(), in mpv-0.1.7/mpvcore/mplayer.c for more details. VSync is to be done by the driver. A video player along cannot know where the VBlank is or wait for VBlank accurately without the driver, and it's only a matter of how mpv cooperates with it.

Are you using separate screens, XRandR, TwinView, or Xinerama? I heard they perform differently for VSync.

You have tried vdpau and other video outputs (x11, xv, sdl, etc.), haven't you? nvidia-settings has a VSync option for xv.

And switching to nouveau might be your last bet. Keep an eye on the temperature of your GPU, though.

Collaborator

richardgv commented Sep 25, 2013

@antcodd:

Does the methods here help for you? https://wiki.archlinux.org/index.php/NVIDIA#Vertical_sync_using_TwinView

Well, I guess I can't solve your issue. It looks so complicated and it's impossible for me to reproduce it here. (I don't have a second monitor.) Maybe you could contact nVidia directly. And NVIDIA Developer Forums and nV News might be good places to ask your questions.

You are definitely not alone. Some people suggested disabling composite extension as a solution. Eeek!
https://devtalk.nvidia.com/default/topic/540730/again-tearing-problems-with-drivers-gt-300-dual-head-setup/
https://devtalk.nvidia.com/default/topic/540113/linux/video-tears-on-all-screens

My SGI_video_sync patch is intended to be used with swapinterval=0. Applying double VSync most likely will cause troubles. Adding glFlush() and glXWaitX() before VSync might be helpful, but not too likely.

I suppose that probably you overestimated the importance of mpv in this process. As a video player, mpv should not and does not care about refresh rate, as far as I know. I believe its timing is based on video/audio frames, and it calls select() to wait for next frame and other inputs, which has nothing to do with GPU. Look around line 2700, run_playloop(), in mpv-0.1.7/mpvcore/mplayer.c for more details. VSync is to be done by the driver. A video player along cannot know where the VBlank is or wait for VBlank accurately without the driver, and it's only a matter of how mpv cooperates with it.

Are you using separate screens, XRandR, TwinView, or Xinerama? I heard they perform differently for VSync.

You have tried vdpau and other video outputs (x11, xv, sdl, etc.), haven't you? nvidia-settings has a VSync option for xv.

And switching to nouveau might be your last bet. Keep an eye on the temperature of your GPU, though.

@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Nov 11, 2013

Sorry for bringing this to attention once again but did anyone ever figure out what is the cause of the player/desktop freezes when switching workspaces back and forth while playing a video via vdpau?
(Compton's GLX backend, any player with vdpau - reproduced on openbox and xfce so far, didn't test others yet)

M4he commented Nov 11, 2013

Sorry for bringing this to attention once again but did anyone ever figure out what is the cause of the player/desktop freezes when switching workspaces back and forth while playing a video via vdpau?
(Compton's GLX backend, any player with vdpau - reproduced on openbox and xfce so far, didn't test others yet)

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Nov 11, 2013

Collaborator

@M4he:

Sorry for bringing this to attention once again but did anyone ever figure out what is the cause of the player/desktop freezes when switching workspaces back and forth while playing a video via vdpau?

  1. VLC has gotten VDPAU support since 2.1.0. Does it exhibit the same problem?
  2. If it occurs on both media players, does it happen on other OpenGL compositors? (Compiz, Kwin) Or is it associated with compton, or a particular compton settings?
  3. If it happens on other compositors as well, you may wish to report this to nVidia.
  4. Using gdb (or a profiling tool, if it's inside a complicated infinite loop?) to break into the compton, X, or video player process and acquire backtraces may provide valuable hints on what is happening.
Collaborator

richardgv commented Nov 11, 2013

@M4he:

Sorry for bringing this to attention once again but did anyone ever figure out what is the cause of the player/desktop freezes when switching workspaces back and forth while playing a video via vdpau?

  1. VLC has gotten VDPAU support since 2.1.0. Does it exhibit the same problem?
  2. If it occurs on both media players, does it happen on other OpenGL compositors? (Compiz, Kwin) Or is it associated with compton, or a particular compton settings?
  3. If it happens on other compositors as well, you may wish to report this to nVidia.
  4. Using gdb (or a profiling tool, if it's inside a complicated infinite loop?) to break into the compton, X, or video player process and acquire backtraces may provide valuable hints on what is happening.
@M4he

This comment has been minimized.

Show comment
Hide comment
@M4he

M4he Nov 12, 2013

Just tried out VLC 2.1.1 using vlc --avcodec-hw=any. (I've read that this parameter forces the usage of VDPAU)

So if vlc's output

libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
[0x7f4484c60ec8] avcodec decoder: Using VA API version 0.34 for hardware decoding.

means that it is using VDPAU, then no - it doesn't happen with VLC.

M4he commented Nov 12, 2013

Just tried out VLC 2.1.1 using vlc --avcodec-hw=any. (I've read that this parameter forces the usage of VDPAU)

So if vlc's output

libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
[0x7f4484c60ec8] avcodec decoder: Using VA API version 0.34 for hardware decoding.

means that it is using VDPAU, then no - it doesn't happen with VLC.

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Nov 13, 2013

Collaborator

@M4he:

Firstly, I'm truly sorry that there is one thing I didn't notice: mpv uses the rendering component of vdpau (VdpOutputSurface) but VLC probably only uses the decoder of vdpau, so... Most likely it isn't the same thing.

Your output seemingly indicates you are using VAAPI. I got the following output when VDPAU is enabled:

[0x7f8268c0dd18] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library  331.20  Wed Oct 30 17:39:35 PDT 2013 for hardware decoding.
[0x7f8268c0dd18] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library  331.20  Wed Oct 30 17:39:35 PDT 2013 for hardware decoding.

I enabled VDPAU support from VLC Preferences -> Codecs -> Hardware-accelerated decoding (Simple view) / Input/Codecs -> Video codecs -> FFmpeg -> Hardware decoding (all view).

Collaborator

richardgv commented Nov 13, 2013

@M4he:

Firstly, I'm truly sorry that there is one thing I didn't notice: mpv uses the rendering component of vdpau (VdpOutputSurface) but VLC probably only uses the decoder of vdpau, so... Most likely it isn't the same thing.

Your output seemingly indicates you are using VAAPI. I got the following output when VDPAU is enabled:

[0x7f8268c0dd18] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library  331.20  Wed Oct 30 17:39:35 PDT 2013 for hardware decoding.
[0x7f8268c0dd18] avcodec decoder: Using NVIDIA VDPAU Driver Shared Library  331.20  Wed Oct 30 17:39:35 PDT 2013 for hardware decoding.

I enabled VDPAU support from VLC Preferences -> Codecs -> Hardware-accelerated decoding (Simple view) / Input/Codecs -> Video codecs -> FFmpeg -> Hardware decoding (all view).

@richardgv

This comment has been minimized.

Show comment
Hide comment
@richardgv

richardgv Dec 10, 2013

Collaborator

ali1234 came with the interesting idea of using X Render for compositing and GLX for the last step of rendering content to screen, and I've implemented it in richardgv-dev branch (fbd70e1). It keeps all the performance weaknesses of X Render backend (slow color inversion and background blur), but it has the same level of VSync GLX backend provides. If for some reason GLX backend is unusable for you (like, sickening driver issues), but you need its VSync, --backend xr_glx_hybird might be useful.

Collaborator

richardgv commented Dec 10, 2013

ali1234 came with the interesting idea of using X Render for compositing and GLX for the last step of rendering content to screen, and I've implemented it in richardgv-dev branch (fbd70e1). It keeps all the performance weaknesses of X Render backend (slow color inversion and background blur), but it has the same level of VSync GLX backend provides. If for some reason GLX backend is unusable for you (like, sickening driver issues), but you need its VSync, --backend xr_glx_hybird might be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment