Frame-perfect Games VRR (Adaptive sync) support

[phaitonican]

will there be VRR support for fullscreen apps?

[vaxerski]

there already is.

If you mean frame-perfect refresh on fullscreen apps, it's planned. I'd need to impl direct scanout first.

[phaitonican]

cool. yea I am talking about variable refresh rate. In my case its called Freesync for amd and G-Sync for nvidia idk. I know swaywm has a variable refresh rate implementation. It basically scales down the refresh rate of the monitor to fit the FPS in the game to avoid input lag and smoother experience

[vaxerski]

oh sway does it the same way as hyprland right now, meaning incorrectly. See https://github.com/swaywm/sway/issues/6832

[phaitonican]

wait is it enabled in hyprland by default or is there a special config line i need?

[veRYANgry]

wait is it enabled in hyprland by default or is there a special config line i need?

I just looked into the code and docs while trying to figure this out. I confirmed this is needed in the config

misc {
    no_vfr=1
}

[GrabbenD]

Workaround

• Launch the game through a dedicated TTY session (not inside Hyprland). Here's a example for Steam on a ultrawide 144Hz monitor:

  $ gamescope -W 3840 -H 1600 -r 144 --adaptive-sync -e -f -- steam -gamepadui
  

• If your display is switching modes when changing TTYs (meaning your having to wait 2-3 seconds), try to:
  1. Supply video kernel parameter (through the bootloader/GRUB), e.g: video=DP-1:3840x1600@144
  2. Make sure you're using the same output mode in Hyprland's config

This way I run Hyprland (in TTY0) and Gamescope (in TTY1) simultaneously and switch between them with ALT+TAB+F1 & ALT+TAB+F2

Gamescope supports VRR only in embedded mode (meaning in a dedicated TTY session). I couldn't get it to work in nested mode (meaning inside Hyprland).

Related:

• Gnome VRR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
• KDE VRR: https://invent.kde.org/plasma/kwin/-/merge_requests/718
• Wlroots VRR: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44
• Kernel

There are two unresolved issues when it comes to VRR: cursor handling and flickering. The first issue manifests itself when the cursor plane is moved while VRR is enabled. Either the cursor is moved at the maximum refresh rate (effectively disabling VRR), either the cursor is moved at the game/video refresh rate (resulting in a very choppy result). We need a new kernel uAPI to move the cursor plane without scheduling a new page-flip somehow. The second issue is that some screens (not all) flicker when the refresh rate is changed abruptly. This is a bit annoying to handle, we need to ensure that refresh rate changes are smoothed over multiple frames for these displays. It would be best for user-space to handle this, because the refresh rate compensation will mess up frame timings. It would be nice to be able to automatically tell apart “good” and “bad” screens, there are some HDMI and DisplayID standards for this but they are not widely supported. More experimentation and testing is required to figure out how much we can do in user-space.

https://emersion.fr/blog/2023/hdr-hackfest-wrap-up/

[GrabbenD]

Here's a patch for Sway which worksaround stuttering caused by the mouse layer in fullscreened VRR apps:

• Original implementation: https://github.com/swaywm/sway/issues/6832#issuecomment-1537300663
• Updated version: https://github.com/swaywm/sway/issues/6832#issuecomment-1612314863

I think this could be a bandaid for stuttering experienced in #2085 if it were to be added as a toggleable option as the issue seems to be triggered by moving the cursor.

Any thoughs @vaxerski?

[vaxerski]

I am holding any patches / work here for when we get tearing tbh

[GrabbenD]

For those who wish to track the progress: https://github.com/hyprwm/Hyprland/pull/1880

[vaxerski]

rather https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3871

[vaxerski]

tearing was merged into wlr and #3441 should enable tearing and fix this issue

[RaphMad]

Now that both settings are in place I'm a bit confused about their interaction - my current understanding is:

• vrr dynamically syncs the monitors refresh to the framerate of the displayed application (therefore eliminating the possibility of tearing, since newly rendered frames will be delivered to the monitor exactly the moment when the previous frame was fully displayed top left to bottom right)

  • Low frame latency + no tearing, but needs hardware support in monitor/graphics hard

• tearing allows to commit newly rendered frames to the monitor as quickly as possible (therefore possibly causing tearing, if that moment happens to be while the monitor is in the mid of displaying a previous frame - top and bottom half of screen will "tear" apart)

  • Low frame latency + tearing, but does not need special hardware support

-> So in my understanding vrr and tearing are mutually exclusive (or at least tearing should not really do anything in a working vrr setup) -> Could somebody elaborate why both features are mentioned in combination in this ticket, and explain their interaction (or non-interaction)? (maybe also add this to the wiki)

[vaxerski]

vrr dynamically syncs the monitors refresh to the framerate of the displayed application (therefore eliminating the possibility of tearing, since newly rendered frames will be delivered to the monitor exactly the moment when the previous frame was fully displayed top left to bottom right)

Incorrect

tearing allows to commit newly rendered frames to the monitor as quickly as possible (therefore possibly causing tearing, if that moment happens to be while the monitor is in the mid of displaying a previous frame - top and bottom half of screen will "tear" apart)

Correct

-> So in my understanding vrr and tearing are mutually exclusive (or at least tearing should not really do anything in a working vrr setup)

No, technically, but most likely the driver will ignore vrr props when tearing. In a low-fps scenario, tearing should work just like vrr.

-> Could somebody elaborate why both features are mentioned in combination in this ticket, and explain their interaction (or non-interaction)? (maybe also add this to the wiki)

Issue was regarding extra frames being scheduled on cursor move, IIRC.

In short, with vrr you can miss the vblank a bit and still have the monitor accept your frame. You cannot submit more frames than your refresh rate.

Even without vrr, you can submit 1fps or 30fps or 60fps.

Tearing will allow you to submit frames immediately which means even in the middle of a scanout (tear!)

vrr makes sense if you have 100fps on a 240hz monitor. It will make no difference if you have >240fps on a 240hz monitor. It will act exactly the same as vsync.

tearing makes sense at any framerate.

[ParetoOptimalDev]

Workaround

Launch the game through a dedicated TTY session (not inside Hyprland). Here's a example for Steam on a ultrawide 120Hz monitor:

gamescope -W 3840 -H 1600 -r 120 --adaptive-sync -e -f -- steam -gamepadui

Gamescope supports VRR only in embedded mode (meaning in a dedicated TTY session). I couldn't get it to work in nested mode (meaning inside Hyprland). I can run Hyprland (TTY0) and Gamescope (TTY1) simultaneously and I switch between them with ALT+TAB+F1 / F2

Related:

* Gnome VRR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154

* KDE VRR: https://invent.kde.org/plasma/kwin/-/merge_requests/718

* Wlroots VRR: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44

* Kernel

There are two unresolved issues when it comes to VRR: cursor handling and flickering. The first issue manifests itself when the cursor plane is moved while VRR is enabled. Either the cursor is moved at the maximum refresh rate (effectively disabling VRR), either the cursor is moved at the game/video refresh rate (resulting in a very choppy result). We need a new kernel uAPI to move the cursor plane without scheduling a new page-flip somehow. The second issue is that some screens (not all) flicker when the refresh rate is changed abruptly. This is a bit annoying to handle, we need to ensure that refresh rate changes are smoothed over multiple frames for these displays. It would be best for user-space to handle this, because the refresh rate compensation will mess up frame timings. It would be nice to be able to automatically tell apart “good” and “bad” screens, there are some HDMI and DisplayID standards for this but they are not widely supported. More experimentation and testing is required to figure out how much we can do in user-space. https://emersion.fr/blog/2023/hdr-hackfest-wrap-up/

This works great and is a much better solution than switching to X11+kde, which was my old workaround.