Mesa 20.3 Picks Up New Capabilities To Help With Display Presentation Jitter, Stuttering

[mcoffin]

Just did some testing with this, and it seems that Firefox will try to use this by default, which is unfortunate, as things like videos that render lower than your display's refresh rate will definitely experience some tearing. Obviously, adding a drirc config for vblank_mode=3 is a decent workaround, but unfortunate that users will have to add more config to get a tear-free experience now (or maybe this is an Xorg driver problem... I don't have any experience with the Xorg drivers as I'm (primarily) on Wayland).

[mcoffin]

If anyone wanted to, they could add something to the drivers to allow forcing different modes. Or add it as a drirc option per executable.

Wait, is this already possible? Could you give an example of how to force a given extension (say, this GLX sync one) on? I'm already familiar with drirc, but I didn't know that forcing extension usage like this was possible. I've only really used it for mesa_glthread, a few version overrides, and adaptive_sync.

[mcoffin]

Since these are extensions, they have to be actively used by applications or game engines before we have any benefit...

Luckily, the features have been in OpenGL and Vulkan for a while, so likely there's already support out there, it's just being disabled as the mesa driver previously didn't advertise support for them!

[mcoffin]

Is this effectively "Adaptive V-Sync" as it was commonly called a few years ago?

No. Adaptive sync is different (allowing monitors with FreeSync capability to "adapt" their refresh rate to try and line up with about what a renderer is outputting). These extensions simply deal with how applications with vsync enabled deal with the situation where, for whatever reason, the application is late to deliver a frame. Previously, the "late" frame would have to just wait until the next vblank, which means stuttering. With these extensions in use, the "late" frame will be displayed IMMEDIATELY, potentially causing some screen tearing, but significantly reducing the stuttering that would be seen in the other case. If you then decide that you can't stand the tearing either, then you'll want to use VK_PRESENT_MODE_MAILBOX_KHR, implementing triple buffering. The downside to this approach is potentially introduced input lag. In this approach, there's three images, an always-complete image that the display will display next, an always-complete image that will be pushed to the first image once it's displayed, and a final image that the application keeps replacing with it's newest frame. This way, images are always displayed on vblank, with no tearing, but there will potentially be an extra frame from when the application queued the frame, until the frame is in the first buffer, and is the one being displayed (introducing an extra frame of latency). This matters less on high-refresh rates, as the single-frame of lag is less time overall, but can be annoying for highly-latency-sensitive things, and especially in low refresh rate deployments.

The place these new extensions will likely help the most, in my experience, is running games with a compositor running. Right now, despite sway being far and away my favorite gaming Wayland compositor, it would be completely un-livable without the current adaptive sync support. With this change, I'd expect to see much more livable performance, albeit with some tearing, even when I turn off adaptive sync (which sway's support for is awesome, and supports multi-monitor FreeSync, and I have a keybind to just toggle it when I please. Seriously if you use FreeSync, sway's implementation is super well-done and user friendly compared to ANYTHING I've seen on Xorg).

Sorry for the rambling reply, I was up too late last night.

EDIT: Actually, looks like the merge request only supports the extensions on X11. Bummer.

[smitty3268]

Since these are extensions, they have to be actively used by applications or game engines before we have any benefit...

If anyone wanted to, they could add something to the drivers to allow forcing different modes. Or add it as a drirc option per executable.

[bearoso]

Wasn't Adaptive V-Sync implemented in Mesa for years already? (but more like forced adaptive VSync... like no way to turn it off and block on SwapBuffers)

Definitely not. Mesa used to hard-sync on SwapBuffers, which was exactly the opposite of that. The nvidia drivers do automatic triple-buffering that doesn't allow SwapBuffers to block until there's 1 frame of lag, but you can turn that off now, and that's not quite the same thing.

Since these are extensions, they have to be actively used by applications or game engines before we have any benefit...

Nvidia drivers already supported them, so there's probably stuff out there using them already. I wanted fifo-relaxed for personal development reasons, though.

[ernstp]

Since these are extensions, they have to be actively used by applications or game engines before we have any benefit...

[tildearrow]

Is this effectively "Adaptive V-Sync" as it was commonly called a few years ago?

Wasn't Adaptive V-Sync implemented in Mesa for years already? (but more like forced adaptive VSync... like no way to turn it off and block on SwapBuffers)

[Calinou]

For the uninitiated, here's a nice explanation of the feature (told from the Vulkan perspective, but it's a good writeup and will get you knowing what both are).

It should help with applications that are rendering slower than the native display refresh rate. They may stutter less, but it could introduce some tearing, as the image will be submitted immediately instead of on the next vblank.

https://vulkan-tutorial.com/Drawing_...sentation-mode

Is this effectively "Adaptive V-Sync" as it was commonly called a few years ago?

[bearoso]

I honestly don't think anybody but me cared about these extensions, so kudos to Adam Jackson for doing this so quickly.