Variable refresh rate, is it working ?

[adolfotregosa]

gamescope -h 1440 -f -e --adaptive-sync -- game_bin etc

Indeed my LG built in frame counter is fluctuating but the game presentation / frame pacing is not even close to be working correctly.

Nvidia over here, 525 , latest arch. Am I missing something or is it really not working ?? It works correctly without gamescope.

[MCPO-Spartan-117]

--adaptive-sync is for embedded mode only atm, however i also don't see it working on a RX 6700 XT card but i'm on kernel 5.12.19 still so might just be a DRM driver issue.

[adolfotregosa]

Petty, It would solve so many situations. We could finally use wine/proton without full-screen hack( fshack is not even compatible with latest wine ) and still be able to have scaling fsr/nis available, but, without vrr working it is gamestopper. Hopefully they will give it a shot.

[elovin]

Also does not seem to work in embedded mode with kernel 6.1.4-zen2-1-zen and mesa 22.3.2 (6700XT): This is the command I used: /usr/bin/gamescope --adaptive-sync -U --sharpness 1 -r 117 -W 5120 -H 1440 -f -e -- steam steam://open/bigpicture

[MCPO-Spartan-117]

@elovin Still having the same issue with kernel 6.1.2, mesa 23.1.0_devel.165191.2969850d886 and gamescope 3.11.51.r122.g0c80f65.

Is your monitor able to have that kind of refresh rate with VRR?, mine seems to need both refresh rate and resolution to be maxed out.

[sofakng]

I'm also wondering about this since I'm switching my "console PC" to Linux.

[Samsagax]

Seems that there is a bug that got fixed for VRR in the kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=f3056978934cf809c0ae70a22ac3af2a857e1a93 Is released in 6.1.11. Could that be it?

[sofakng]

It still doesn't appear to be working even with kernel 6.1.11 and gamescope 3.11.51.

Here's my setup:

• AMD Radeon 6700 XT
• Kernel v6.1.11-arch1 (Arch Linux)
• Gamescope v3.11.51
• KDE Plasma v5.26.5
• LG C1 (with "FreeSync Premium" enabled which appears to be required for Freesync support)
• VRRTest (latest from git)

VRRTest works under Xorg (KDE) if I add the "VariableRefresh=true" to my Xorg configuration. VRRTest works under Wayland (KDE).

I've tried launching gamescope in both embedded and non-embedded modes and with the command-line argument (--adaptive-sync) but it doesn't work (ie. LG C1 doesn't report the changing refresh rate).

[MCPO-Spartan-117]

@Samsagax Still isn't working with kernel 6.1.12, mesa 22.3.4 and gamescope 3.11.51.r135.g8a3fa88.

[chardinson]

How do I know that freesync is working?

[MCPO-Spartan-117]

@chardinson If your monitor has a refresh rate counter it should be changing to the fps of the game if it is lower than the monitor's refresh rate.

[GrabbenD]

I can't verify if it works correctly as my monitor's OSD doesn't show the current refresh rate. However, I'm seeing a large reduction in stuttering if I run Gamescope in embedded mode (outside of my window manager/compositor, in other words in a dedicated TTY session) with my GSync Ultimate monitor on a AMD card:

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

(It doesn't work in nested mode in Hyprland)

[MCPO-Spartan-117]

@GrabbenD I don't believe Gsync module monitors work with AMD GPUs.

[GrabbenD]

@MCPO-Spartan-117 From what I've gathered this is true for the old generation of GSYNC modules (v1). However, new monitors have a updated GSYNC implementation (v2 & v3+) which is DRM free and uses the VESA adaptive sync standard (which is what FreeSync is based on). Also, GSYNC Ultimate's specification should be equivalent to FreeSync 2.

My monitor doesn't mention FreeSync support (AW3821DW). Although if I fire up AMD Adrenalin in Windows, my FreeSync Range shows as 1 - 144 hz which is correct for the capability of a GSYNC Ultimate monitor.

However for this to work you need a Display port cable since the standard is open source while HDMI is not and thus Linux drivers lacks support for it.

[mpawlowski7]

Currently it's not working. The monitor refresh rate doesn't change in the information tab. I made a PR to fix this https://github.com/ValveSoftware/gamescope/pull/903

[adolfotregosa]

Currently it's not working. The monitor refresh rate doesn't change in the information tab. I made a PR to fix this #903

Well at least with nvidia, either nested or embedded it isn't working correctly. I mean I can see the frequency counter on the TV jump around but clearly it still isn't working.

[mpawlowski7]

Replying to https://github.com/ValveSoftware/gamescope/issues/721#issuecomment-1613857545

Did you test it with with https://github.com/Nixola/VRRTest ?

This is what I used for testing but I'm using the amd gpu. Could be different a issue with nvidia.

[adolfotregosa]

Replying to https://github.com/ValveSoftware/gamescope/issues/721#issuecomment-1614173633

Yeah, out of gamescope vrr works fine, with gamescope not so much.

[dolandemort]

I have had success enabling vrr within gamescope using one of the available arguments. Here's the relevant line in gamescope --help output:

--adaptive-sync                Enable adaptive sync if available (variable rate refresh)

[adolfotregosa]

Replying to https://github.com/ValveSoftware/gamescope/issues/721#issuecomment-1614228888

with amd it seams to be working

[mpawlowski7]

This could be related https://github.com/NVIDIA/open-gpu-kernel-modules/issues/485

Gamescope starts xwayland/wayland session and this is why the vrr might not work with nvidia.

To summarize the minimum to have it working is to start an gamescope from separate tty and add the --adaptive-sync parameter. That's it

[adolfotregosa]

This could be related NVIDIA/open-gpu-kernel-modules#485

Gamescope starts xwayland/wayland session and this is why the vrr might not work with nvidia.

To summarize the minimum to have it working is to start an gamescope from separate tty and add the --adaptive-sync parameter. That's it

yeah, I vouch for that. G-Sync/vrr is not working on wayland. It seams to be because the TV tricks you when the built-in fps counter changes but everybody with experience with working correctly g-sync/vrr will notice immediately it is not.

AMD is not a solution either because they kinda are refusing to make hdmi 2.1 work in linux so I will GLADLY keep nvidia and my 4k120Hz while hdmi 2.1 is not available from amd. There was a glimpse of hope a few months ago here but they have since become silent.

[MCPO-Spartan-117]

VRR now works on AMD with kernel 6.2.10, mesa 23.1.2.170168.ffdc2d248dc and gamescope 3.12.0.beta8.r13.g1b9b736, though it causes weird behavior such as seemly random display fps fluctuations outside of the TTY it is in.

[elovin]

Hi @MCPO-Spartan-117 could you share the full command with flags you used ? Thanks!

[MCPO-Spartan-117]

@elovin Just --adaptive-sync will do it.

[GrabbenD]

Sway without direct scanout is the only wlroots compositor which highly reduces stuttering when VRR is enabled.

VRR in Gamescope doesn't work: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3721

[misyltoad]

VRR is working for me on Gamescope -- and also we don't use any of the wlroots stuff for scanning out it's completely different.

[GrabbenD]

@Joshua-Ashton Gotcha, I though that was the case since there's multiple references to wlr in the codebase!

I've tested gamescope with --adaptive-sync but it has exactly the same output lag with VRR as wlroots based compositors like Sway (with direct scanout), Hyprland and RiverVM (I updated the link in my previous comment since it pointed to the wrong issue*).

Here's a recording of this problem, it shows how the lag looks on my Alienware AW3821DW and MSI MAG27CQ displays: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3721#note_2063213 I'm wondering if this is potentially an issue in DRM/AMDGPU driver which affects Gamescope and wlroots but isn't triggered by Sway if it's used without direct scanout?

[iguanajuice]

VRR is working for me on Gamescope -- and also we don't use any of the wlroots stuff for scanning out it's completely different.

Same here. This has been something I've been patiently waiting for a while now.

Not sure how long this has been the case, though; since I only found out about it now, and by accident.

No new feature announcement or nothing? This is a pretty big improvement that I'm sure a lot of other people wanted, so it's odd its addition has been silent.

[sharkautarch]

I've tested gamescope with --adaptive-sync but it has exactly the same output lag with VRR as wlroots based compositors like Sway (with direct scanout), Hyprland and RiverVM (I updated the link in my previous comment since it pointed to the wrong issue*).

VRR now works on AMD with kernel 6.2.10, mesa 23.1.2.170168.ffdc2d248dc and gamescope 3.12.0.beta8.r13.g1b9b736, though it causes weird behavior such as seemly random display fps fluctuations outside of the TTY it is in.

Not sure if this is related to whatever lag people are noticing with gamescope VRR, but I think I have found some issues with vblankmanager.cpp/steamcompmgr.cpp that has been observed to at least cause stuttering in non-VRR cases, but may also be relevant here. For reference of one case of the issue I mentioned, see: https://github.com/ValveSoftware/gamescope/issues/995

It seems like some of the changes I made in the branch of my fork, nvidia-fix-and-vblank-debug-extra-experimental-v2, helped mitigate the issue for the issue post mentioned above.

Though the changes I made were aimed for non-VRR cases, there's some issues that I saw which may also be relevant for VRR cases:

• vblankmanager uses sleep_until_nanos()/sleep_for_nanos(), which in turn uses nanosleep() which can run into these issues:

  • nanosleep() can stop sleeping prematurely due to interrupts. sleep_until_nanos()/sleep_for_nanos() does not check if this happens. I think this is a bigger problem than the next problem I'll mention.
  
  
  • nanosleep() may sleep for longer than the duration passed to it.
    • Note: I've heard that the above behavior may be different if running under RT schedule policy. However according to https://man7.org/linux/man-pages/man2/nanosleep.2.html:

   In order to support applications requiring much more precise
   pauses (e.g., in order to control some time-critical hardware),
   nanosleep() would handle pauses of up to 2 milliseconds by busy
   waiting with microsecond precision when called from a thread
   scheduled under a real-time policy like SCHED_FIFO or SCHED_RR.
   This special extension was removed in Linux 2.5.39, and is thus
   not available in Linux 2.6.0 and later kernels.

• On the other hand, nanosleep() sleeping for longer than the duration passed to it may not be as big of an issue, because the amount by which it oversleeps seems to not vary all too much between each successive call to nanosleep().
• The 'solution' I found to the issue of nanosleep() sleeping longer than specified was to sleep for only a fraction of the vblank time, and then (if it's not time for sending vblank yet) busy wait the rest of the time using a combo of pause/tpause/yield (depending on if cpu is x86 vs aarch64) instructions + the instruction to read the cpu clock (specific instruction depends on if cpu is x86 or aarch64). From what I've observed on x86, this allows for total sleep durations (based on measuring the ~~start and end times of the loop~~ EDIT: start time of the loop -> time when the vblank is sent in vblankThreadRun()) which are only around ~~0.6-0.9 ms away from the actual target vblank time~~EDIT EDIT: my latest version of the code I wrote has busy waiting that is now only around .1ms or so away from the actual target vblank time. Unfortunately this isn't that portable and probably doesn't work that well on x86 cpus that don't support invariant tsc.

[Kagukara]

VRR still isn't working for games when using gamescope/gamescope-git, I use gamescope -w 3840 -h 1800 -W 3840 -H 1800 -f -- %command% for my games.

It looks like when there is a frame limit set in the game VRR just stops working, but when left unlimited some games work and some don't. This maybe because the games are capped by default I'm not sure.

I tested this with mangohud gamescope vkcube, when the frame rate was capped using mangohud VRR would stop working and jump around, and not staying at the newly capped frame rate. My monitor is set to 120Hz and when I cap the fps of vkcube to 90 using mangohud, the monitors fps/vrr jumps around from 73 to 120, when vkcube is capped at 60fps it jumps all over the place.

When not using gamescope VRR is working.

• OS: Arch Linux
• Kernel: 6.7.7-arch1-1
• Hyprland Version: v0.36.0-38-g2a08f2ba
• GPU: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 16.0.6, DRM 3.57, 6.7.7-arch1-1)
• Mesa Driver: 4.6 Mesa 24.0.2-arch1.1
• Display(s):
  • Samsung Electric Company Odyssey G7 H1AK500000 (VRR: FreeSync Premium Pro)
    • 3840x2160@120 VRR 10bpc | modeline 1498.25 3840 4192 4616 5392 2160 2163 2168 2316 -HSync +VSync
  • Ancor Communications Inc VG248 DCLMQS078349
    • 1920x1080@60
  • Dell Inc. DELL P2418D MY3ND7B70VLT
    • 1920x1080@60

Tested with:

• gamescope Version: 3.14.0-1
• gamescope-git Version: 3.14.2.r11.ge0c277a-1
  • Not to do with VRR, but the git version didn't go fullscreen and I made it fullscreen in hyprland it was glitching out and the black bars were invisible.