Repository navigation
Regressed frame pacing on DRM #2527
Description
Is there an existing issue for this?
- I have searched the existing issues
Are you using any gamescope patches or a forked version of gamescope?
- The issue occurs on upstream gamescope without any modifications
Current Behavior
After the awesome fixes from #2412, I moved on to testing the DRM backend. This may be related to that.
Comparing 3.17.0 to 3.16.31 there seems to be a pretty large regression here on high refresh rate monitors.
- The target monitor refresh rate is never reached, and instead a stable value way below it is rendered.
Steps To Reproduce
- This is best reproduced on a 240Hz or 300Hz monitor. I wasn't able to reproduce this on 60Hz, 120Hz or 144Hz.
- Any of these commands will reproduce the issue:
gamescope -O HDMI-A-1 -W 2560 -H 1440 -r 300 -- env MANGOHUD=1 vkcube --wsi xcb --width 2560 --height 1440- Adding
--expose-waylandand--wsi wayland - Disabling the gamescope WSI with
DISABLE_GAMESCOPE_WSI=1- This should force FIFO into the driver, but it makes no difference at all.
While the frametimes are mostly clean this time, it's only doing ~262 fps on my 300Hz monitor, and ~213 fps on my 240Hz monitor.
Hardware information
- Distro: Arch Linux
- CPU: Ryzen 9 9950X3D
- GPU: NVIDIA RTX 5080
- Driver Version: Latest
I am unable to produce more than 120Hz with my laptop, therefore I cannot test whether this issue exists on AMD as well. I would assume so however, as frametimes are fluctuating a little bit even on my laptop.Software information
- Desktop environment: None
- Session type: None
- Gamescope version: 3.17.0 and 3.16.31 (I also tested latest git)
- Gamescope launch command(s): See aboveWhich gamescope backends have the issue you are reporting?
- Wayland (default for nested gamescope)
- DRM (default for embedded gamescope, i.e. gamescope-session)
- SDL
- OpenVR
Logging, screenshots, or anything else
It's hard to take screenshots in DRM mode, but put simply when you request -r 300, MangoHud will show that there's actually only some inconsistent number around ~262 fps being reached. It is relatively stable at that number though.
The same thing happens when requesting -r 240. It does not happen on -r 120 and -r 60 and I don't have any in-between monitors to check this with.
HDR is disabled. This used to work fine one update ago.
Activity
misyltoad commentedon Oct 29, 2026
Can you bisect the issue? I dont have a display above 144Hz to test right now.
PancakeTAS commentedon Oct 29, 2026
I tried bisecting it and experimenting with it a bit more.
It looks like when I start gamescope on the 240Hz monitor, it takes between 1-20s to "adjust" to the 240Hz cycle. It starts out doing some 210-ish fps and eventually starts doing perfectly flat 240 fps. I just didn't wait long enough I guess and incorrectly thought it was a regression in the new version.
On the 300Hz monitor however, regardless of the version, it never hits a smooth 300Hz cycle instead hanging around 260Hz. I tried with realtime scheduling on both vkcube and gamescope, but nothing helped. I only got this 300Hz monitor recently and this was my first time running gamescope on it.
So the weird behavior is instead 1) the random fluctuating until it stabilizes and 2) it never stabilizing on 300Hz and above.
Frame pacing is hard.. lemme know if I can be of any more help.
matte-schwartz commentedon Oct 29, 2026
I have a chungus laptop with a 480hz meme panel somewhere around the house, I'll dig it up when I have a chance.
vblankmanager: keep the fixed-refresh wakeup after the previous vblank
matte-schwartz commentedon Oct 30, 2026
can you try #2528?
PancakeTAS commentedon Oct 31, 2026
Works as expected, both the weird inconsistency at the start is gone and it's reaching 300Hz now as well.
Is the code safe for VRR as well? (I can't test this)
matte-schwartz commentedon Oct 31, 2026
VRR uses a different code path that this PR doesn't change, and it doesn't have the fixed-refresh lead that caused this
vblankmanager: keep the fixed-refresh wakeup after the previous vblank
vblankmanager: keep the fixed-refresh wakeup after the previous vblank