VSync #7
Comments
|
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. |
|
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. |
|
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. |
|
Compton with video tearing is kind of unusable. |
|
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. |
|
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. |
- 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.
|
Here you go, guys. Clone When you try the software VSync remember to use If you have the the interest to further investigate if the painting time is correct, compile compton with: make clean; CFLAGS='-DDEBUG_REPAINT' makeAnd compton will print out the detailed time of painting like this: The things in the first bracket is the time passed since last paint, in the format of This feature will not be available as a configuration file option before I'm sure it's working. |
|
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. |
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
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?
There are two problems here that I could not understand:
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. |
|
Device is
In sw mode it is tearing in different place each time I start compton. Same command with debugging mode:
I see tearing With debugging:
I see tearing And with debugging: |
|
Ah, I forgot to say, thanks for your tests. :-) The good thing is I saw under both the 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... |
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.
|
Alright, another attempt: Double buffering, stolen from cairo-compmgr. Please clone from 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? |
|
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. |
|
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:
XdbeSwapBuffers(dpy, &swap_info, 1);Then compile, and run with: ./compton --dbe --vsync sw --refresh-rate 60If 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? |
|
Another update: Please clone from |
|
Latest richardgv-dev, trying all variants: xubuntu 12.10 --vsync opengl --dbe
--vsync sw --refresh-rate 60 --dbe
|
|
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. |
|
Ah, GitHub, you are way too smart again! Now please clone from |
|
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:) |
|
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 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 By the way 2, have you actually looked into nvidia-settings as I recommended in one of the previous replies? |
|
Oops) nvidia-settings all vsync(xv, opengl) --sw-opti (with / without dbe)
--vsync opengl (with / without dbe)
|
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). |
|
So, I did some very thorough testing: https://docs.google.com/spreadsheet/ccc?key=0AjhHjzQIZ8LjdDBDU1ZNemJUQ2daUVRFaG00M1BBT0E&usp=sharing Although The Intel HD 4000 runs perfectly no matter the setting (everything is smooth; much less Xorg cpu load). |
|
Okay, VDPAU isn't a choice either. |
|
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). |
|
You don't need to. Even if I drop the shadow option everything behaves the same. I think the problem is, that the GL and compositing synchronization of the nvidia drivers is a complete joke. 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. |
|
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 By the way, I tried improving GLX shadow texture generation, but it perhaps performed badly since |
|
I just tried out mpv 0.1.7 with 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. |
|
Today I reproduced exactly what you reported: It happens here when either "Sync to VBlank" is turned on in nvidia-settings or I used I started using sysbench
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 When I dig into the source code of mpv and vlc I discovered a thing: They both try to call (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 So, probably nvidia-drivers doesn't like a compositor using
Unless you have VSync set in drivers or |
|
(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 |
|
Thank you very much for your thorough research and detailed explanations!
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 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
Huh, I don't know. Theoretically it may lead to certain frames being dropped if the timing is inappropriate.
They can and should provide an option to switch VSync on/off, although I doubt if they would care about this. |
|
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.
Note that mpv
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 I notice with compton off, 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! |
Aha! Apparently it was a bad idea to work at midnight. I should have noticed it.
So it means my call to
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.
No idea why that would happen.
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 |
|
(In addition to the previous reply...) I wrote a patch to add SGI_video_sync to mpv, as a replacement for |
So I need to apply both this patch and the one you posted earlier? |
The new By the way, as mpv has an option |
|
Thanks for the 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 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 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. |
|
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! My 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 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. |
|
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? |
|
|
Just tried out VLC 2.1.1 using So if vlc's output means that it is using VDPAU, then no - it doesn't happen with VLC. |
|
Firstly, I'm truly sorry that there is one thing I didn't notice: mpv uses the rendering component of vdpau ( Your output seemingly indicates you are using VAAPI. I got the following output when VDPAU is enabled: I enabled VDPAU support from VLC Preferences -> Codecs -> Hardware-accelerated decoding (Simple view) / Input/Codecs -> Video codecs -> FFmpeg -> Hardware decoding (all view). |
|
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 |
More conversion to XCB
Is it possible to implement vsync into compton? I like this compositor very much, but tearing is annoying some time.
The text was updated successfully, but these errors were encountered: