Add an adaptive_sync output command

[emersion]

This enables/disables adaptive synchronization on the output.

For now, the default is disabled because it might cause flickering on
some hardware if clients don't submit frames at regular enough
intervals. In the future an "auto" option will only enable adaptive sync
if a fullscreen client opts-in via a Wayland protocol.

Testing:

• Set output * adaptive_sync on to enable VRR on all outputs that support it
• Set up output scheduling parameters so that clients will miss the deadline. On my hardware, output * max_render_time 1 plus max_render_time 1 works well.
• Check that adaptive sync is marked as enabled in swaymsg -t get_outputs (alternatively, "VRR enabled on connector" should appear in the debug logs)
• Run weston-presentation-shm on an output without adaptive sync enabled. The "p2p" (presentation-to-presentation) delay should be twice the refresh period (in my case, I have a 60Hz monitor, so it's 33ms). p2p should be pretty stable.
• Run weston-presentation-shm on an output with adaptive sync enabled. The "p2p" delay should be greater than the refresh period but smaller than twice the period (in my case, between 16 and 20ms). p2p should be pretty unstable.

Alternatively, https://github.com/emersion/drm_monitor can be used instead of weston-presentation-shm.

Depends on swaywm/wlroots#1987

cc @nstickney

[emersion]

Sway users who have a VRR-capable monitor & GPU: I'd be interested if you could try this patch out and report back if you experience flickering.

[Emantor]

Tested on a RX580 with LG 32UD99, the desktop feels more responsive and I haven't observed any flickering so far. I will run this for a while and report back.

Edit: FWIW the monitor is connected via HDMI.

[cirk2]

I've been runing your wlroots branch with the blanket enablement hack for a while and it worked quite well.

Your Test case works fine, I do not notice any flicker.

Vega 64, mesa-git from 03.03.20, LG 27 L 27MU67-B on Display port for the Adaptive Sync test and a second one on HDMI for the test without.

[ms178]

AFAIK there is no Freesync support on Linux with HDMI yet with AMD hardware, just DisplayPort, see https://www.phoronix.com/scan.php?page=news_item&px=AMD-FreeSync-2019-Update for reference. Please re-test with DP to verify that this MR works as intended.

[Emantor]

AFAIK there is no Freesync support on Linux with HDMI yet with AMD hardware, just DisplayPort, see https://www.phoronix.com/scan.php?page=news_item&px=AMD-FreeSync-2019-Update for reference.

Ha, placebo effect at work. I'll check this and switch from HDMI to DP when I'm back home.

[kqzkqz]

went ahead and applied this patch and swaywm/wlroots#1987 last night.

using a vega 64 with AMDGPU, and with my 3440x1440 100hz monitor (with freesync enabled) using DP and an OLED 4k TV using HDMI, then setting adaptive_sync 1 on just the DP output and "output * max_render_time 1", I do notice some mild flickering, which is more easily noticable in fullscreen xwayland games.

the display in general certainly feels more responsive.

also noteworthy imo is that with this patch compared to the other patch that blindly enables VRR on supported outputs in sway, I no longer experience an issue where I drop frames on the other output (i.e when playing a video in firefox on the other monitor)

let me know if any logs could be helpful for looking at the flickering

[emersion]

Thanks for testing. It would be useful to find some monitors which do flicker, as this would justify the need for a Wayland VRR protocol. Basically anything from this list could cause flickering:

https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/util/00-mesa-defaults.conf#L403

I think web browsers are a good test case.

[Nuc1eoN]

When testing adaptive sync functionality you guys should always enable the native fps overlay (frame counter) of the monitor.

This way you can see if the frame rate actually changes (is variable) or if it's just placebo. Most freesync monitors have this kind of an overlay build in.

[cirk2]

Yeah that's why I didn't report before on the earlier patch versions: The LG 27 L 27MU67-B does not have a overlay and the kernel debug reporting for vfr has moved to the vblank reporting, making it really hard to use that.

[kqzkqz]

doing some more testing, following @Nuc1eoN's tip, I can confirm that the refresh rate of the monitor is changing, though unfortunately my monitor doesn't have a native overlay, I have to manually close and re-open the monitors OSD menu to get the current refresh rate at that specific point in time.

the flickering on my monitor can be reproduced even with just a completely blank sway desktop (not even a wallpaper) and by moving the cursor around, looks to me like the flicker coincides with every time the refresh rate changes, as i've noticed scrolling in firefox and basically anything that updates the screen causes it.

for reference, my monitor is a Viotek GN32CB, which is definitely more of a budget freesync monitor.

here's the first few lines of output of weston-presentation-shm from my non-VRR 60hz 4k display

discarded 1
     2: f2c  1 ms, c2p 29 ms, f2p 30 ms, p2p     0 us, t2p  29610, [sce_], seq 1158
     3: f2c  0 ms, c2p 34 ms, f2p 34 ms, p2p 33335 us, t2p  33740, [sce_], seq 1160
     4: f2c  0 ms, c2p 34 ms, f2p 34 ms, p2p 33335 us, t2p  33718, [sce_], seq 1162
     5: f2c  0 ms, c2p 33 ms, f2p 33 ms, p2p 33336 us, t2p  33569, [sce_], seq 1164

and here's the output from my 100hz freesync display

     1: f2c 1694571 ms, c2p  2 ms, f2p 1694573 ms, p2p     0 us, t2p   1970, [sce_], seq 114267
discarded 2
     3: f2c  0 ms, c2p 10 ms, f2p 10 ms, p2p 10001 us, t2p   9718, [sce_], seq 114268
     4: f2c  0 ms, c2p 10 ms, f2p 10 ms, p2p 10209 us, t2p  10206, [sce_], seq 114269
     5: f2c  0 ms, c2p 10 ms, f2p 10 ms, p2p 10190 us, t2p  10244, [sce_], seq 114270
     6: f2c  0 ms, c2p 11 ms, f2p 11 ms, p2p 10169 us, t2p  10164, [sce_], seq 114271

[Nuc1eoN]

Just as a question, is there maybe a software way to display the monitors refresh rate live? I've always wondered about this and it would be much easier for testing, especially for those monitors that don't offer a native feature.

[michaelnew]

Been trying this out. I have a 144hz Acer XFA240 bmjdpr 24 connected to a Vega64 over displayport, and a 60hz 4k monitor (non-freesync) as a second monitor. Even without changing the ouput scheduling parameters there's intermittent but noticeable flicker.

According to the monitor's FPS overlay the refresh rate goes as low as 48 and as high as 144. The flickering seems to happen at lower refresh rates, but not always.

[Emantor]

Note that xwayland will flicker due to https://gitlab.freedesktop.org/xorg/xserver/issues/951 unless built from master, because wlroots removed the pending buffer and the race is more visible now.

[emersion]

Just as a question, is there maybe a software way to display the monitors refresh rate live? I've always wondered about this and it would be much easier for testing, especially for those monitors that don't offer a native feature.

weston-presentation-shm is a way to get the presentation timings, should be easy to deduce the actual FPS from that. I don't know of a way to get directly this information from KMS as a standalone program.

[emersion]

Just as a question, is there maybe a software way to display the monitors refresh rate live? I've always wondered about this and it would be much easier for testing, especially for those monitors that don't offer a native feature.

Actually, I missed drmWaitVBlank and friends. I've put together a simple DRM client that displays frame-rate information: https://github.com/emersion/drm_monitor

[emersion]

Added some notes about what's next here: #5076

This patch can be merged before any of #5076 happens, because it would already allow users with a narrow-enough VRR range to take advantage of the feature.

[ddevault]

Rebase?

[emersion]

Rebased.

[ddevault]

Rebase again? wlr_buffer issues.

[emersion]

Oh right. Rebased again.

[ddevault]

Thanks!

[mcoffin]

Testing this on my side. No flickering so far on amd-staging-drm-next kernel.

This could be a major selling point for sway since as of the time of writing, I believe this is the only support we've seen for multi-monitor setups with VRR since X11 only supports it if you have one monitor.

I'll do some in-game testing, but thanks for the seriously awesome work here @emersion. You should get paid ;)

EDIT0: This even works with DRI_PRIME, yet another thing X11 cannot do. This. Is. Awesome.

[emersion]

Started to write a wiki page to collect a list of VRR setups (and see which ones work fine, which ones don't): https://github.com/swaywm/sway/wiki/VRR-setups

[mcoffin]

@emersion - for your wiki page, I can confirm that the following has no flicker.

• Monitor - Acer XF270HU
• GPU - 5700XT
• VRR range: 40Hz -> 144Hz
• Resolution: 2560x1440

The only gotcha is that for some reason, toggling VRR on/off with a sway hotkey while a fullscreen Xwayland application is open doesn't work; you have to go to a different workspace, do the toggle, then come back. I bet that issue is global and not setup-specific, though, so should be good to add it to the list. I've been running it basically since the day this got merged, and haven't had any issues since about the first month (when there was mouse lag when the refresh rate was low in the range... it's fine now).

[emersion]

Thanks, I've added it to the wiki. (The wiki is editable, feel free to update it.)

The only gotcha is that for some reason, toggling VRR on/off with a sway hotkey while a fullscreen Xwayland application is open doesn't work

Can you open a bug report about it? It sounds related to direct scan-out, it would be nice to confirm with debug logs.

[tomekw]

Wow, just discovered it and it works perfectly :) Dell S2721DGFA 165Hz 1440p monitor with RX6800 and no issues! Thanks! 🙇

[mcoffin]

I don't think I mentioned it before, but somehow, this seems to work completely perfectly with DRI_PRIME offloading as well... yet another bonus over the bogus Xorg implementation(s)

[codebam]

On my AW3821DW with the Radeon VII enabling adaptive_sync with no display mode set results in a black screen (display appears to be off until a reboot). This should be 60Hz I believe.

When mode is set to 144.99Hz the display flickers and the bottom portion of the display is gray and doesn't render.

120Hz works.

100Hz is fine, until it crashes.

The same thing happens in kwin when adaptive sync is enabled.

I'd blame it on the display, but freesync works in Windows 11 at 144Hz.

Logging out with adaptive_sync enabled crashes the display manager. Whether it's sddm or gdm.

[Kommynct]

I get horrible flickering on anything above 60hz with my acer XG270HU

I've tried a 5700xt, and a 6650xt, same result.

It also defaults to 60hz for some reason, and if I set it to 144hz by default in my sway config, it fades to a horrible white mess on boot sometimes, not sure if related.