New Vulkan vsync mode! FIFO latest ready

[BallisticNick]

Just wanted to present a new development in linux/vulkan as of late.
The past couple of months the vulkan devs have added a new function VK_GOOGLE_display_timing which allows for vulkan to take timing from the display to schedule a present to happen at a desired time, according to the docs.

What this boils down to is a mailbox-like vsync mode called FIFO_LATEST_READY that has ZERO stuttering.
Well it seems like it to me playing on viewsonic XG2431 on 60hz with large vertical totals.

I was playing dmc4se and I could not believe how just easy and effortless it was to set up with what felt to me like scanline sync (which isn't on linux just yet) without the hassle or the jankiness of when the tear line drifts down due to loading new areas (dmc4se is particularly a mess in this regard). I was even using the game's own frame-rate limiter, which isn't too great but it still produced super smooth lag-free gameplay!

Regrettably I don't have any way to measure this new tech in some nice graphs to present to everyone but I love to hear everyone’s thoughts!

To set it up you can use the latest mangohud-git with vulkan_present_mode=fifo_latest_ready in the .conf file and the nvidia or mesa beta drivers (not sure what to do for windows), and it should work with any of the latest proton versions or any native linux games with a fairly up to date vulkan.

NOTE AFTER TESTING SOME MORE 12/04/2026: This works best under x11 rather than wayland as overriding wayland's explicit sync is a PITA

[RealNC]

I'll have to try this out at some point. Frame pacing on Linux is a mess. Hope this fixes things.

[netborg]

> Frame pacing on Linux is a mess. Hope this fixes things.

Well, we have great frame pacing for dxvk:
https://github.com/netborg-afps/dxvk-low-latency
https://github.com/CachyOS/proton-cachy ... 260407-slr

FIFO latest ready is largely for VK_EXT_present_timing which is more for fine-tuning the smoothness, it won't magically fix pacing in other areas.

[RealNC]

I gave this a test in RetroArch. It's a bit tricky to get working. You need to disable "audio synchronization", "sync to content frame rate" and vsync in retroarch and make sure you configure a correct FPS cap in mangohud that matches a fraction of your refresh rate exactly. But once you do, it's very smooth. Obviously this won't work well for emulated systems that are not based on near-60Hz displays (like some 55Hz arcade games or 70Hz DOS games) since then the games will run too fast or too slow. But for near-60Hz systems, it's good.

VRR is still better for latency, but since my W-OLED monitor has so much flicker with it, I can't really use it anymore, so this is a nice development.

As for dxvk, I don't use that at all. I still dual boot Windows for Windows games since dxvk for me has a lot more stutter in modern games than native Windows. Which I assume is probably due to shader compilation. Not that Windows doesn't have that problem, of course. It does. But dxvk for me seems to make it even worse. (This is on Nvidia drivers. No idea if it's better on AMD.)

[netborg]

Mangohud has really bad frame pacing capabilities, since it tries to do that purely in the Vulkan domain.

Newer dxvk has much improved shader compilation caching. You'll get a much better pacing and fps-limiter there, especially for VRR too (dxvk-low-latency). Ofc. it can't completely eliminate the need for shader compilation, and can't speed up the slow Nvidia compiler, but it can cache properly now, and probably will further improve upon that until the next major release.

[BallisticNick]

Not sure I agree with mangohud having bad frame-pacing capabilities, testing with my monitor's OSD frame rate display, my hertz stays right around 232-235 with a frame limit set to 233 in mangohud, allowing me to keep very close to my monitor's max refresh rate whilst still keeping within the VRR range. DXVK on the other hand jumps from 212 to 240 (turning off vrr) with a frame limit set to 223.

Testing a bit more with fifo latest ready, It seems to default to standard FIFO behaviour if you have vrr enabled. Was doing some testing and wrote a full reply saying that this vsync mode may not be too great. Then figured out I had vrr enabled...

But it seems this new tech caps the frame rate at double your monitor's hertz, or as the vulkan docs say: (swapchainImageCount - 1) * refreshRate. There is what feels to me like a little small lag penalty to hitting the cap, but it still feels very responsive.

I want desperately to get someone in here who can actually test this out with some proper measurements.

[RealNC]

Not sure I agree with mangohud having bad frame-pacing capabilities, testing with my monitor's OSD frame rate display, my hertz stays right around 232-235 with a frame limit set to 233 in mangohud, allowing me to keep very close to my monitor's max refresh rate whilst still keeping within the VRR range. DXVK on the other hand jumps from 212 to 240 (turning off vrr) with a frame limit set to 223.

There was some discussion in Special K's discord that MangoHUD's FPS limiter can't be as accurate as Special K on Windows, since on Windows the limiter has information about display scanout timing. For example if I enable VRR and cap to 230FPS, the monitor's OSD stays fixed at 230Hz. Not the usual +/- 3Hz jitter you get with limiters that aren't taking display presentation timing into account. As a result, if I use SK's fractional cap without VRR (like a 1/2 Hz cap at 240Hz which caps to 119.996FPS since true refresh is 239.992Hz,) it's perfectly smooth without ever producing even a single hiccup. Same for 1/3 (79.997FPS), 1/4 (59.998FPS), etc. With vsync OFF this translates to a tear line that is perfectly fixed in position and doesn't jitter up/down.

Apparently this wasn't possible on Linux. But now that VK_GOOGLE_display_timing support is finally becoming available in desktop GPU drivers, I hope MangoHUD will implement this into its limiter and get a perfectly stable FPS cap for non-VRR users (I don't use VRR on my W-OLED because of the flicker.)

[BallisticNick]

I'm pretty sure VK_GOOGLE_display_timing isn't becoming available on desktop gpu's any time soon. What is becoming available is VK_EXT_present_timing support, which is inspired by the vulkan extension but is supposedly more granular and designed with the idea of wider adoption, which it has done.
May ask on the discord what the special k dev thinks of the extension.

[netborg]

Not sure I agree with mangohud having bad frame-pacing capabilities, testing with my monitor's OSD frame rate display, my hertz stays right around 232-235 with a frame limit set to 233 in mangohud, allowing me to keep very close to my monitor's max refresh rate whilst still keeping within the VRR range. DXVK on the other hand jumps from 212 to 240 (turning off vrr) with a frame limit set to 223.

This is a very simplified view of frame pacing. If you care about that alone, you could just cap via fixed refresh v-sync and call it a day.
What matters for animation errors too, is when the frame did start, this won't get shown on your monitor's OSD, but you'll experience it as micro-stuttering or video playback speed errors (which correlate with input lag inconsistencies). On top of that MangoHud fps limiting creates one full frame of additional latency!

The technology used in dxvk-low-latency predicts the frame from start to finish and will align it optimally with VRR. The video will be super smooth in most games (those which have a great sync to the render thread), even if the monitor's OSD Hz fluctuates.

[RealNC]

This is a very simplified view of frame pacing. If you care about that alone, you could just cap via fixed refresh v-sync and call it a day.

That has too much lag. And on top of that, vulkan lacks fractional vsync (present interval 2/3/4) so you can't do a 120Hz vsync at 360Hz for example (present interval 3.)

What is needed is being able to, for example, use normal 360Hz vsync with a 1/3 FPS cap and have the frame presentation pacing be so accurate as to perfectly output 120FPS at 360Hz but never miss the correct display scanout for each frame.

Obviously all of this isn't important with VRR, but without VRR it's not looking great right now on Linux.