Mpv: [Question] Why is GPU page- or buffer-flipping bad for mpv?

[mpvOWNZ]

I noticed that @wm4 recommended on multiple occasions to disable 'Allow Flipping' in the Nvidia drivers (on Linux).
Also, this is what the Arch Linux wiki has to say on the "TearFree" option (which is used to enable tearing prevention using the hardware page flipping mechanism):

This option is problematic for applications that are very picky about vsync timing.

So, what is the reason for this? Shouldn't buffer flipping actually increase the performance and be beneficial for mpv, since the data doesn't have to copied back and forth?

PS: Interestingly, I found this in the revision history of the Arch Linux wiki about Nvidia by @lachs0r:

‎Enabling triple buffering: Removed. This option is actively harmful (cripples performance, _causes_ tearing in some cases, weird as it sounds) and generally does not achieve anything good.

[mia-0]

All I can say about the “TearFree” option is that it forces another composition pipeline on top of what you already have, so it adds latency. It’s basically the same thing as NVIDIA’s “ForceFullCompositionPipeline”. This is documented in the intel(4) manpage, but actual behavior seems to differ in that it does not always redirect compositor/fullscreen output.
Needless to say, this really shouldn’t be necessary, and it’s NOT a proper fix for Intel’s driver bugs. VSync should work with or without a compositor; with or without that option (and in fact it does on my Intel systems, but I guess it’s broken on some hardware/distros).

[mpvOWNZ]

@lachs0r
Thanks for the explanation!
But what about Nvidia? Why would it be a good idea to disable "Allow Flipping" there?
(I just remembered that SSR (SimpleScreenRecorder) also prompts for this on startup...)
And shouldn't triple-buffering considered to be generally a good thing? (IIUC, Intel's driver on Linux enables this by default.)

[ghost]

I noticed that enabling this option results in worse vsync timing. You can see by watching the vsync-jitter property. It will be higher with flipping enabled. (Although, when energy saving is disabled, it's low enough not to cause any actual problems for mpv.)

I'm not sure if I should even blame nvidia here though, because OpenGL + vsync timing has no clear solution. While the GPU most likely always does perfect vsync, and the driver knows about the actual vsync timing, there's no good way to communicate it to the OpenGL API user. (Not that I have found one. You can insert timers into the GL command stream, but I'm not sure if this always gets the vsync event itself.) So what mpv tries to do is assume SwapBuffers blocks (which it doesn't always do), and other than that assume that the driver will on average output frames according to the detected framerate. This is a very messy topic and much can go wrong.

[mpvOWNZ]

@wm4
Thank You very much for taking the time to answer! I (and surely many more) really appreciate that!

(Although, when energy saving is disabled, it's low enough not to cause any actual problems for mpv.)

I suppose You mean switching over to 'Prefer Maximum Performance' in nvidia-settings, right?

And about the whole vsync topic:
Please don't take what I'm going to ask You as nagging or begging, but what is Your take on the possible future of Vulkan in mpv? Do You think this could be a viable possibility?

Thanks again!

[mia-0]

That said, whether allowing flipping impacts vsync timing performance apparently depends on more factors, and I cannot determine which ones because I’m unable to reproduce this. For example, I have not observed any problems with it on my system (which uses a GTX 960 with both flipping and power management enabled and an openSUSE default kernel). The vsync-jitter property stays in the range of 0.002-0.005.

There were no problems with my older cards (9800GT, 8400GS, GT210) either, but all of these always run at the same power profile.

[ghost]

The vsync-jitter property stays in the range of 0.002-0.005.

If I enable flipping, it can rise to 0.115, and if I enable power management, it can reach 0.4 or more. With something like 0.5 or more, mpv's heuristic about tolerating imperfect vsync timing will fail.

Vulkan in mpv

Maybe once drivers don't lock up on official demo programs. I'm hoping that it'll provide better vsync timing and better ways to transfer video data to the GPU. But it will remain experimental for a long time and won't have any of vo_opengl's features.

[qmega]

To add some more potentially interesting data points: I've recently started using the waitvsync option, which has greatly reduced my vsync jitter. It seems like disabling flipping gets in the way of that, especially if you're on the edge of your hardware's capability. On one machine I use, with a relatively weak GPU that can barely support my settings, I get these for vsync-jitter (all with power saving disabled):

| settings | vsync-jitter |
| --- | --- |
| defaults (no waitvsync and flipping allowed) | 0.3~0.6, sometimes higher, with noticable stutter occasionally, especially when first starting playback - starts above 1 and takes a few seconds to get down |
| waitvsync + allow flipping | 0.001-0.002 (best configuration for me overall) |
| waitvsync + do not allow flipping | 0.2~0.7, swings up and down constantly, and visible frame drops / judder, worse than with defaults |
| no waitvsync + do not allow flipping | 0.004-0.006 (but fewer dropped frames in the beginning) |

So it seems both waitvsync and no flipping help individually, but in my case, at least, they don't work together, and the former is better.

On my stronger machine, the differences are much smaller and I get visually fine output with pretty much any combination (even with power saving enabled, as long as I use waitvsync), but it seems like the same relative relationships more or less hold. (It's hard to tell because the numbers are so close.)

I'm using Nvidia proprietary drivers.

[NiLuJe]

@qmega: Glad to see that wasn't simply a quirk of my systems ;).

[ghost]

waitvsync is also likely to reduce performance.

[mpvOWNZ]

waitvsync is also likely to reduce performance.

I can attest to that one. In my case, was unable to play back a 60fps video fluently with waitvsync enabled. (Nvidia 750 Ti, 361.42)
@qmega @NiLuJe
Could one of you try a 60fps video out to see if this holds true for you as well?

Thanks!

[NiLuJe]

No issues on my end (both software & hardware decoding), but then I'm on a brand new beefy desktop, so that would have kind of hurt if it did behaved poorly ;p.

That's on fullscreen with fullscreen windows unredirected by the compositor (KWin 5), not that this really changes anything on this system... (It did on my old GTX 275 & x86 Core 2, for instance, where I used a KWin 4 window rule to kill the compositor on mpv).

(x86_64, GTX 960, 364.15, i7 6700K @ 4.4GHz).

[qmega]

I'm not getting any performance hit from waitvsync either (except when combined with no flipping on the weak machine, as I said earlier). On my main machine, I get no problems at all with a 60fps 2880x1620 video. On the weaker one, it lags like crazy, but turning off waitvsync doesn't help at all; it's just not strong enough to scale that fast using my settings. Re-encoding the video to 1280x720 (still at 60fps) makes everything mostly fine, not perfect but again no better with waitvsync off. On both machines, there's no significant difference in dropped frames, or even GPU or CPU usage. Honestly, I was expecting at least a little difference, but there seems to be pretty much none. (If there is any difference at all, it's small enough that it's less than random differences between runs, so I can't really measure it.)

Strong machine: Arch Linux, GTX 980 Ti, Nvidia 361.28 (also using SCHED_ISO from -ck kernel patchset) - I have to try really hard to make mpv lag on this machine, like turning up scale-radius or something.

Weak machine: Debian Jessie, GTX 760, Nvidia 340.96 - This machine's hardware is barely capable of my settings and can go from totally fine to visibly stuttering with a small settings change, so I'm surprised that waitvsync doesn't hurt performance, but that's what my testing showed.

Both are running displays at 3840x2160.

[mpvOWNZ]

@NiLuJe @qmega
Thanks for testing!
On my end, it wasn't that the 60fps video lagged, just that it wasn't as smooth as it should be.
I noticed this only after pausing and then continuing to play, where for the first few seconds the video would be noticeably smoother and then still appear to play normally, just not visually as smooth.
I also could notice the difference more clearly when playing the same video side-by-side with a "low-end" video player (like Totem or VLC ;-]).

Other than that, I agree with what @qmega observed about compositors on another issue:
Having them not disabled (as is the case now with mpv 0.17.0) seems to help with v-sync timing, which also clearly shows on games. (Maybe because the GPU driver knows this way that it doesn't have to produce more frames than can be displayed?)

[ghost]

I think the basic problem with waitvsync is that it will sometimes cause the player to wait for a vsync twice.

[qmega]

I think the basic problem with waitvsync is that it will sometimes cause the player to wait for a vsync twice.

Meaning it would skip a frame? Or just sleep for some time it could be drawing?

[ghost]

Both. The former will cause stuttering, the latter bad performance but might still keep up.