Linux offers optimal OpenGL V-sync latency

[silikone]

Many gamers opt to forego V-sync due to the massive latency incurred. A staple workaround spearheaded by Blurbusters has been to cap the framerate below the refresh rate.
But on recent versions of Mesa on Linux (26.x or so), it appears that this isn't really necessary anymore. Despite using triple buffering, OpenGL only lags two frames behind presentation time. For comparison, with triple buffering enabled in NVIDIA's control panel, I count five frames of latency on Windows. From what I can tell, performance isn't negatively affected. I've been able to reliably induce brief peaks of 100% GPU utilization without dropping a single frame.
Despite only running at 60Hz, a game like Minecraft feels both comfortably responsive and fluid to play, all without involving VRR.

One way to verify latency is to install Xonotic and run the GLX/WGL version with "vid_touchscreen" enabled. This will juxtapose the hardware cursor and the game cursor together, making it easy to measure the delay in frames.

[kyube]

Many gamers opt to forego V-sync due to the massive latency incurred. A staple workaround spearheaded by Blurbusters has been to cap the framerate below the refresh rate.
But on recent versions of Mesa on Linux (26.x or so), it appears that this isn't really necessary anymore.
Despite using triple buffering, OpenGL only lags two frames behind presentation time.
For comparison, with triple buffering enabled in NVIDIA's control panel, I count five frames of latency on Windows.
From what I can tell, performance isn't negatively affected. I've been able to reliably induce brief peaks of 100% GPU utilization without dropping a single frame.
Despite only running at 60Hz, a game like Minecraft feels both comfortably responsive and fluid to play, all without involving VRR.

One way to verify latency is to install Xonotic and run the GLX/WGL version with "vid_touchscreen" enabled. This will juxtapose the hardware cursor and the game cursor together, making it easy to measure the delay in frames.

5 frames is a extremely large latency increase... how are you calculating / coming to these values?
It's best to rely on PresentMon (or FrameView) for these type of analysis'
https://www.nvidia.com/en-eu/geforce/te ... frameview/

[silikone]

5 frames is a extremely large latency increase... how are you calculating / coming to these values?

I use a HFR camera and record the cursor as I move it around. It will take X amount of frames for the game's rendering to catch up with the hardware cursor that is updated at scanout. While messy, it's a universal solution that avoids the pitfalls of proprietary software.
Yes, five is a lot, and that explains why V-sync gets a bad reputation.

[kyube]

5 frames is a extremely large latency increase... how are you calculating / coming to these values?

I use a HFR camera and record the cursor as I move it around. It will take X amount of frames for the game's rendering to catch up with the hardware cursor that is updated at scanout. While messy, it's a universal solution that avoids the pitfalls of proprietary software.
Yes, five is a lot, and that explains why V-sync gets a bad reputation.

Interesting, do you have the raw footage? I'd be interested in the data.
What specific hardware (CPU,GPU,monitor,...), software (OS, drivers,..) & tools (camera) were used?
I do think that 5 frames is extremely excessive... could you also verify with FrameView on the Windows side?
I did read claims that OpenGL on Linux is better, but that would be quite a monumental difference

Just to be specific, this only occurs in Xonotic? No other OpenGL game?

[silikone]

Interesting, do you have the raw footage? I'd be interested in the data.
What specific hardware (CPU,GPU,monitor,...), software (OS, drivers,..) & tools (camera) were used?
I do think that 5 frames is extremely excessive... could you also verify with FrameView on the Windows side?
I did read claims that OpenGL on Linux is better, but that would be quite a monumental difference

I'd have to record my Linux tests again, but I do have the pathological case that I recorded yesterday attached in the post.
This is an old computer running Windows 10 with an i5-6600K, GTX 970, on some 60Hz ASUS monitor, recorded with a Pixel 8. Triple buffering is enabled in the control panel. V-sync is enabled in the game.
There's nothing special about Xonotic. This is the behavior of all fullscreen OpenGL games. I picked this because it's a native cross-platform title where this cursor technique is feasible.

[kyube]

I'd have to record my Linux tests again, but I do have the pathological case that I recorded yesterday attached in the post.
This is an old computer running Windows 10 with an
i5-6600K, GTX 970,
on some 60Hz ASUS monitor,
recorded with a Pixel 8.
Triple buffering is enabled in the control panel.
V-sync is enabled in the game.
There's nothing special about Xonotic.
This is the behavior of all fullscreen OpenGL games. I picked this because it's a native cross-platform title where this cursor technique is feasible.

Thank you for the video!
Based on: https://www.pcgamingwiki.com/wiki/List_of_OpenGL_games
We have, in total, 1'661 games (perhaps slightly more) available to the PC market.
A few caveats:
• The most commonly OGL games on the market nowadays would be old Quake games (like Xonotic), Minecraft & some OSU versions
• This latency discrepancy is likely much less pronounced on higher refresh rates.
It's still best to rely on FrameView data, so we have more insight into the intrinsics

Were you using DXGI layer or the native layer for OpenGL?
What exactly made you discover this specific quirk between Linux vs Windows? As in, were you trying to solve problem you're having?
If your goal is to eliminate tearing on your 60Hz display, it's advised that you either go with Nvidia's FastSync or one of the static-tearline solutions such as Special-K's Latent-Sync or RTSS' Scanline-Sync, which are touted (incorrectly) online as "low-lag VSYNC"

[silikone]

Were you using DXGI layer or the native layer for OpenGL?
What exactly made you discover this specific quirk between Linux vs Windows? As in, were you trying to solve problem you're having?

I'm not using any layer.
It started when I gained an interest in Linux (Arch BTW) and its open source graphics drivers to inform my hardware buying decisions. I've since acquired a 9070 XT that I daily-drive, but I also have a laptop worth considering where I play old lightweight games out of necessity without VRR, and OpenGL is especially relevant there. Minecraft also remains a very popular OpenGL title with a native Linux client, so there is certainly a prominent use case.

[kyube]

I'm not using any layer.

I assume you've set this to 'Auto' when you've tested Xonotic then in Windows, which would use the native layer (HW:Legacy Flip)

It started when I gained an interest in Linux (Arch BTW) and its open source graphics drivers to inform my hardware buying decisions. I've since acquired a 9070 XT that I daily-drive, but I also have a laptop worth considering where I play old lightweight games out of necessity without VRR, and OpenGL is especially relevant there.
Minecraft also remains a very popular OpenGL title with a native Linux client, so there is certainly a prominent use case.

Yes I agree, OpenGL games still have a use-case.
I was just curious what you were trying to solve by using Triple Buffering + V-SYNC, as that's somewhat of a "archaic" way (non-optimal way) of eliminating tearing on Windows... which is what I assume you were trying to eliminate?

[silikone]

I was just curious what you were trying to solve by using Triple Buffering + V-SYNC, as that's somewhat of a "archaic" way (non-optimal way) of eliminating tearing on Windows... which is what I assume you were trying to eliminate?

It's the de facto standard on Linux with Mesa. OpenGL is always triple-buffered and never tears when using Wayland, so I wanted to achieve parity.
But more generally, triple buffering drastically reduces microstuttering on low-end hardware when VRR is not an option, and even when it is, frametime variance can still manifest as uneven motion. V-sync throttling usually minimizes frametime variance and leads to the visually smoothest outcome. The video also shows a graph that visualizes frametime variance (r_speeds_graph).
The takeaway is that the OS has a lot to say in what the most optimal path to blur busting is. I can publish some more data tomorrow for comparison.

[silikone]

Here's a recording of a i5-13500H Lenovo Yoga running Arch (Linux 7.0.3) with Openbox on Xorg. I also included some click-to-photon latency tests for good measure. The latency appears to vary around 12-16 camera frames (240 FPS), which divides neatly into the display refresh rate (60Hz).

latencylinux.mp4

(4.84 MiB) Downloaded 29 times