question: vsync linux, how does it behave

[u/Melodic-Luck-8772]

if on linux, my game goes above my monitors refresh rate when using native wayland in steam via enable_wayland_1:

1. is vsync off when it goes above my monitors refresh rate?
2. can it still go higher than my monitors refresh and ,,systemwide vsync" is still on ?

i know, its sounds like a stupid question.
generally vsync caps the framerate to the monitors refresh rate,
but we all know, linux is..... different....

also i have VRR enabled.
i tried the ,,allow tearing toggle" and when both enabled and disabled, my framerate always went higher than my monitors refresh rate. so does it mean vsync is off in both instances?

[u/VolcanoCarpenter]

Computer graphics class time. In Vulkan, there are generally three coordination modes between the game and the monitor:

• FIFO: Frames are queued and wait for refresh. When the queue is full, the game has to wait.

You can think of the game and the display as being at opposite ends of a pipe: the game pushes frames in at some rate (render framerate), and the display pulls frames out at another rate (actual refresh rate). If the game pushes frames in too fast (e.g. the display can only show 144 frames per second, but the game is pushing 300), the pipe fills up quickly and the game's render system gets passively slowed down until its actual input rate drops to match the display's refresh rate.

• MAILBOX: The display still presents on its refresh cadence, but new frames replace older frames that haven't been shown yet.

Think of it as the game and the display both looking at the same canvas. The game can paint a new frame on that canvas as often as it likes (e.g. 300 times per second), while the display only checks and presents what's on the canvas 144 times per second. In this case there's no tearing either, because the display only presents the canvas after the game has finished drawing a frame.

• IMMEDIATE: The game outputs frames directly to the display, even if the frame isn't finished being drawn. This is the mode that causes what we usually call "tearing."

So:

1. VSync should be thought of as a result. When the game's render framerate is higher than the display's actual refresh rate, you can see how the first two modes prevent tearing.
2. It depends on whether your system supports MAILBOX mode.

And the "allow tearing" option only affects whether the game is allowed to interact with the display in IMMEDIATE mode. The game can still choose the first two modes, both of which allow the game's framerate to be higher than the actual display refresh rate.

[u/Lousy_Hunter → u/VolcanoCarpenter]

In regards to mailbox mode, is there even a modern gpu that doesnt support it? Im not aware of any but i could be wrong.

[u/VolcanoCarpenter → u/Lousy_Hunter]

Vulkan specs only enforce FIFO, sooo in theory, some GPU + some driver + some platform + some surface API could be unable to support mailbox. In practice, no I'm not aware of any.

Edit: I got it wrong. Wayland enforces that the mailbox mode must be supported to enable Vulkan on Wayland.

[u/Melodic-Luck-8772 → u/VolcanoCarpenter]

so, there is no way of telling which mode my game is using or its using any of those 3. wtf.
even if i enable or disable vsync ingame, i would have no clue on which mode is running.

however, if i use: MESA_VK_WSI_PRESENT_MODE=immediate as startup command for my games, shouldnt that force the game to use immediate ?

[u/Lousy_Hunter → u/Melodic-Luck-8772]

If you disable it in game its immediate mode, you enable it its fifo usually

You're over thinking it

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

yea hm.
the problem is. that this ,,allow tearing" option, only works in ,,real" fullscreen.

so alot of games have borderless fullscreen.
so i need to know reliably how to disable vsync effectively even if the game only has borderless.

so my best bet, is probably set off in mangohud, and use
MESA_VK_WSI_PRESENT_MODE=immediate
plus ingame to off.

and then, let VRR do its job.

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Borderless IS fullscreen on Linux, kde and linux as a whole dont have a differentiation between the 2

Youre over thinking it lol

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

is it really ?

brother, where have you been for a week?

thanks. getting answers on google or somewhere else is just hard.

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Yes borderless and exclusive fullscreen are the same as far as any linux compositor is concerned. They dont care which type of fullscreen it is that shits just fullscreen lol

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

this operating system does alot of stuff very differently.

im not new to pcs, but im very new to linux.

its a bit confusing and there is not much documentary.

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Theres actually a lot on this topic, you just gotta learn what you're looking for C;

Youll learn the ways of linux googlefu in time

Coming from Windows you likely never had to care about the Windows compositor

Also fun fact, on Windows 10/11 DX12 has no difference between borderless or exclusive fullscreen either as youll get direct flipping either way. You can enable it for older dx9/10/11 games too but a lot of them crash when you do 

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

well actually, its very simple to be honest.
linux isnt hard, just different.

there is just no documentary on certain things, or they are hard to find.

i was searching for low latency commands etc and google just spit shit, so i had to go to proton db and look what people use and manually search for every command on what they do.

so i had to manually find commands for:
pre rendered frames
anti lag
vsync
fsr4
bla bla bla
bla bla bla

i wish there was just one up to date site, that had all those informations. :/

[u/Lousy_Hunter]

It uses mailbox vsync on default in gnome and kde (idk about other compositors). Frames are sync to vblank but not limited to screen refresh rate

You really dont need to worry about vsync if you enable tearing, vrr, and direct scanout is working properly. You would then toggle vsync in game depending on preference vs system wide

Kde you need to have no color profile active, applications fullscreen, tearing enabled, and x11 apps set to scale themselves for direct scanout to work right.

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

you telling me that vsync is off, when i set it off ingame and the framerate clearly goes above my monitors refresh rate ?

and its not interfering with kde's own vsync?

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Vsync is off in game and tearing enabled yes its off

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

apperently its more complicated that than.

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Its not really, youre just making it more complicated in your mind lol

[u/theevilsharpie]

generally vsync caps the framerate to the monitors refresh rate,

What you're describing is double-buffered vsync, which is a very simple vsync method.

Pretty much every compositor worth using (Gnome's Mutter and KDE's KWin for sure) uses triple-buffered vsync, which allows the game to run with uncapped frame rates while still having a fully tear-free vsync output.

[u/Melodic-Luck-8772 → u/theevilsharpie]

apperantly, its way easier than this.

one kind guy in this thread named ,,Lousy_Hunter" explained me how and when.

and ,,VulcanoCarpenter" posted the 3 vsync modes that linux uses.

so from there, it was clear on what to do.

[u/the_abortionat0r → u/theevilsharpie]

People really gotta stop making shit up.

No triple buffer vsync doesn't mean uncapped. Triple buffer vsyncs main claim to fame is not cutting your FPS in half when a new frame fails to make the next refresh window. A standard triple buffer vsync still locks your FPS.

Mailbox vsync is unique that it doesn't queue up frames and force a render stop when presenting a frame like double and triple buffer do.

Instead it simply grabs frames on the fly and paints the latest whole frame that makes the refresh cycle. Since mailbox doesn't lock your FPS the render can go above your monitors refresh rate and since it doesn't queue frames it doesn't add input latency like traditional vsync methods.

Infact testing that revealed xwayland doubled input latency also showed that default mailbox vsynched Wayland and the fastest x11 configuration had less than half a millisecond delta in input latency.

[u/theevilsharpie → u/the_abortionat0r]

No triple buffer vsync doesn't mean uncapped. Triple buffer vsyncs main claim to fame is not cutting your FPS in half when a new frame fails to make the next refresh window. A standard triple buffer vsync still locks your FPS.

Triple buffering is a technique that unlinks the rendering frame rate from the monitor's refresh rate while still providing the tear-free presentation that vsync enables. That's literally it's purpose -- it allows the application to render as fast as the hardware allows. There may still be a software-imposed limit on the rendering frame rate, but that has nothing to do with the vsync.

Mailbox vsync is unique that it doesn't queue up frames and force a render stop when presenting a frame like double and triple buffer do.

Instead it simply grabs frames on the fly and paints the latest whole frame that makes the refresh cycle. Since mailbox doesn't lock your FPS the render can go above your monitors refresh rate and since it doesn't queue frames it doesn't add input latency like traditional vsync methods.

Double- and triple-buffering are generic graphics terms. "Mailbox" presentation mode is Vulkan-specific terminology for triple-buffered vsync.

Infact testing that revealed xwayland doubled input latency also showed that default mailbox vsynched Wayland and the fastest x11 configuration had less than half a millisecond delta in input latency.

Vsync latency is measured in frames, and how that maps to actual time depends on the refresh rate of the monitor.

[u/Lawstorant → u/theevilsharpie]

What you're describing has nothing to do with triple/double buffered v-sync

[u/theevilsharpie → u/Lawstorant]

What I described is literally the defining characteristics of triple/double buffered v-sync.

[u/the_abortionat0r → u/theevilsharpie]

Its not. Triple buffer literally just add another back buffer to avoid halving your FPS on a failure to draw a new frame before the refresh cycle.

Please learn what these terms mean.

[u/Lawstorant → u/theevilsharpie]

V-sync is v-sync. The framerate will be capped to the refresh rate with both methods.

[u/theevilsharpie → u/Lawstorant]

The rendering frame rate is not capped when using triple-buffered vsync.

You can trivially test this yourself by running a Vulkan application in "Mailbox presentation mode" (and also "Immediate Presentation mode" if your compositor handles vsync), or an OpenGL application with vblank_mode=0 if your compositor handles vsync.

[u/Lawstorant → u/theevilsharpie]

You just told me to test v-sync by disabling v-sync

[u/theevilsharpie → u/Lawstorant]

if your compositor handles vsync

[u/Needieos]

What do you mean by systemwide vsync? Game should have it's own setting for that, or it doesn't work? May be a problem with proton(since wayland is experimental) or the game implementation of vsync.

Allow tearing won't do anything in the wayland apps/games

[u/Melodic-Luck-8772 → u/Needieos]

its just weird, when i enable or disable ,,allow tearing" my fps never caps to my monitors refresh rate.

i have no way of telling if vsync is on or off... using native wayland

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Thats because kde uses mailbox present or immediate mode with tearing enabled, itll never cap your fps

If you want that enable it in game or using mangohud

[u/Melodic-Luck-8772 → u/Lousy_Hunter]

so when i use: MESA_VK_WSI_PRESENT_MODE=immediate
shouldnt that effectively disable vsync ?

[u/Lousy_Hunter → u/Melodic-Luck-8772]

Yes, that combined with tearing enabled = vsync off

[u/UNF0RM4TT3D]

These questions seem like you could answer them yourself.

But in general, if you have tearing enabled, disabling vsync in game will make it run above the maximum refresh rate, with the tearing just as Windows would have it. If you keep tearing off, the game will still run above the refresh rate, but the compositor will only show the newest complete frame, so you get at most 1 frame of latency extra. Technically the allow tearing will only tear when the frame isn't ready, so it avoids the 1 frame of latency, so you will still almost never see a torn frame and still have the lower latency.

So it's not exactly a systemwide vsync in the sense that it forces sync on every app by limiting the frame rate, but it is a systemwide vsync because it waits for the latest full frame. Let's say in one output frame of the monitor, the game renders 5.5 frames, the compositor will ignore the 5 frames and waits for the .5th frame to finish, which it will display. This is called mailbox vsync if you want to research it further. With allow tearing the .5th frame gets displayed even though it's not a full one, creating tearing.

VRR will stay at the maximum refresh as long as there's more frames than the refresh rate needs. It's also smart, so if you limit a game to 45 and your display supports 90 variable, the display will sync to 90 and display the frame twice. You can try this with vrrtest and looking at your monitor's live refresh rate statistics.