SUMMARY I have a 144hz monitor and a 60hz monitor, running plasma wayland the nvidia proprietary driver (through gbm). When there are redraws on one monitor, full screen games on the other monitor are incorrectly vsynced. On my machine, the game's framerate goes up to ~185fps (but fluctuating) when the other monitor is playing a video, both if the game is on the high refresh rate monitor and the video on the low refresh rate one and viceversa. With this going on, I can very distinctly perceive the game constantly stuttering, which i never felt on X11 with vsync disabled and similar framerates. STEPS TO REPRODUCE 1. Run `__GL_SYNC_TO_VBLANK=0 glxgears -fullscreen` on one monitor. 2. Confirm that glxgears is being vsynced by kwin, matching the monitor refresh rate. 2. Make any application redraw on the other monitor. For example, play a video. 3. glxgears is now no longer synced to the monitor refresh rate. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora 35 (available in About System) KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90 Qt Version: 5.15.2
I got some new info: If the video on the other monitor is also fullscreen, then the game is properly vsynced again.
KWin does compositing in a single thread. If two outputs need compositing at the same time and latency is too low, this causes stutter because it can't manage to finish compositing both in time. With NVidia we don't get proper timestamps, which causes the latency to be lower than desired, see bug 409040. Until that is fixed you can work around this problem by setting the latency option in the compositing KCM to "prefer smoother animations". *** This bug has been marked as a duplicate of bug 409040 ***
(In reply to Zamundaaa from comment #2) > KWin does compositing in a single thread. If two outputs need compositing at > the same time and latency is too low, this causes stutter because it can't > manage to finish compositing both in time. > > With NVidia we don't get proper timestamps, which causes the latency to be > lower than desired, see bug 409040. Until that is fixed you can work around > this problem by setting the latency option in the compositing KCM to "prefer > smoother animations". > > *** This bug has been marked as a duplicate of bug 409040 *** I'm not sure this is the same bug. I've tried both smoother/smoothest animations and your open pull request @ https://invent.kde.org/plasma/kwin/-/merge_requests/1861 with the same result. Some terminal output of the reported example: $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen # I launch glxgears on my 60hz monitor 311 frames in 5.0 seconds = 62.187 FPS # at the beginning fps is a bit higher than 60, maybe due to Konsole on the other monitor? 300 frames in 5.0 seconds = 59.936 FPS 302 frames in 5.0 seconds = 60.325 FPS # some fluctuation? 300 frames in 5.0 seconds = 59.930 FPS 300 frames in 5.0 seconds = 59.938 FPS 300 frames in 5.0 seconds = 59.937 FPS 617 frames in 5.0 seconds = 123.314 FPS # at this point i start playing a video on firefox 830 frames in 5.0 seconds = 165.977 FPS 871 frames in 5.0 seconds = 174.174 FPS 897 frames in 5.0 seconds = 179.370 FPS 897 frames in 5.0 seconds = 179.367 FPS 905 frames in 5.0 seconds = 180.971 FPS 895 frames in 5.0 seconds = 178.969 FPS 897 frames in 5.0 seconds = 179.371 FPS 887 frames in 5.0 seconds = 177.373 FPS
When the video is playing on the same monitor as glxgears, this is the result instead: $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen 372 frames in 5.0 seconds = 74.248 FPS 301 frames in 5.0 seconds = 60.141 FPS 302 frames in 5.0 seconds = 60.337 FPS 301 frames in 5.0 seconds = 60.135 FPS 301 frames in 5.0 seconds = 60.136 FPS 303 frames in 5.0 seconds = 60.547 FPS 301 frames in 5.0 seconds = 60.128 FPS 301 frames in 5.0 seconds = 60.136 FPS 303 frames in 5.0 seconds = 60.537 FPS
Wait, sorry, I misread things. So the refresh rate goes higher than the monitors? Can you check if your monitors overlap, even if just by a pixel? That can cause weird things to happen
(In reply to Zamundaaa from comment #5) > Wait, sorry, I misread things. So the refresh rate goes higher than the > monitors? > > Can you check if your monitors overlap, even if just by a pixel? That can > cause weird things to happen Exactly.(In reply to Zamundaaa from comment #5) > Wait, sorry, I misread things. So the refresh rate goes higher than the > monitors? > > Can you check if your monitors overlap, even if just by a pixel? That can > cause weird things to happen Correct, refresh rate goes up. It levels off at the same frame rate regardless of the actual refresh rate of the monitor that it's being rendered in. (roughly 180fps but seems to oscillate easily) Monitors are not overlapping. I've just tried also having a gap between them and same thing happens.
If you set the 144Hz one down to some lower refresh rate, does that change something about the refresh rate of the app?
(In reply to Zamundaaa from comment #7) > If you set the 144Hz one down to some lower refresh rate, does that change > something about the refresh rate of the app? 120HZ / 60HZ $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen 890 frames in 5.0 seconds = 177.917 FPS 709 frames in 5.0 seconds = 141.773 FPS 895 frames in 5.0 seconds = 178.962 FPS 730 frames in 5.0 seconds = 145.974 FPS 899 frames in 5.0 seconds = 179.772 FPS 697 frames in 5.0 seconds = 139.372 FPS 898 frames in 5.0 seconds = 179.571 FPS 100HZ / 100HZ $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen 805 frames in 5.0 seconds = 160.695 FPS 700 frames in 5.0 seconds = 139.874 FPS 736 frames in 5.0 seconds = 147.104 FPS 692 frames in 5.0 seconds = 138.264 FPS 631 frames in 5.0 seconds = 126.113 FPS 654 frames in 5.0 seconds = 130.706 FPS 641 frames in 5.0 seconds = 128.107 FPS 650 frames in 5.0 seconds = 129.904 FPS 85HZ / 60HZ $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen 673 frames in 5.0 seconds = 134.590 FPS 646 frames in 5.0 seconds = 129.174 FPS 642 frames in 5.0 seconds = 128.266 FPS 639 frames in 5.0 seconds = 127.676 FPS 646 frames in 5.0 seconds = 129.193 FPS 633 frames in 5.0 seconds = 126.430 FPS 648 frames in 5.0 seconds = 129.450 FPS 617 frames in 5.0 seconds = 123.261 FPS 60HZ / 60HZ $ __GL_SYNC_TO_VBLANK=0 glxgears -fullscreen 384 frames in 5.0 seconds = 76.791 FPS 562 frames in 5.0 seconds = 112.292 FPS 337 frames in 5.0 seconds = 67.331 FPS 585 frames in 5.0 seconds = 116.996 FPS 601 frames in 5.0 seconds = 119.952 FPS 470 frames in 5.0 seconds = 93.884 FPS 485 frames in 5.0 seconds = 96.984 FPS 601 frames in 5.0 seconds = 119.991 FPS 590 frames in 5.0 seconds = 117.875 FPS 416 frames in 5.0 seconds = 83.149 FPS It's doing something, I'm not quire sure what thing. Video playing is 60fps, fwiw.
Does this also happen with `weston-simple-egl -f`?
(In reply to Vlad Zahorodnii from comment #9) > Does this also happen with `weston-simple-egl -f`? No, seems to work fine.
If native wayland clients are okay, it looks like an issue in Xwayland. Can you report this issue to Xwayland developers? https://gitlab.freedesktop.org/xorg/xserver/
(In reply to Vlad Zahorodnii from comment #11) > If native wayland clients are okay, it looks like an issue in Xwayland. Can > you report this issue to Xwayland developers? > https://gitlab.freedesktop.org/xorg/xserver/ I went to look at what GNOME wayland does, and `__GL_SYNC_TO_VBLANK=0 glxgears -fullscreen` isn't getting vsynced at all. Also on plasma wayland, if glxgears is not fullscren it's not vsynced. I'm not sure what's intended and what's not, to be frank.
> __GL_SYNC_TO_VBLANK=0 That doesn't disable VSync for glxgears. "vblank_mode=0" does that Anyways, the compositor doesn't have much to do with Xwaylands VSync, and has completely nothing to do with Xwaylands not doing VSync.
(In reply to Zamundaaa from comment #13) > > __GL_SYNC_TO_VBLANK=0 > > That doesn't disable VSync for glxgears. "vblank_mode=0" does that > > Anyways, the compositor doesn't have much to do with Xwaylands VSync, and > has completely nothing to do with Xwaylands not doing VSync. From what I could gather online, __GL_SYNC_TO_VBLANK=0 is for nvidia proprietary while vblank_mode=0 is for mesa drivers
sigh, of course there's different env vars for that. Still, Xwayland and/or the driver take care of that, KWin is not directly involved