Screen Tearing/VSync Issue in KDE Plasma Wayland, Gnome Wayland #3189
Comments
neatnoise
changed the title
|
Glad to know I'm not the only one: |
|
Could this be it? It says here the issue existed for years but this seems to have appeared just a few months ago at most. |
|
It could be. I'm doing the research too, testing different desktop environments, settings within envs, forcing different driver settings. No success so far. The issue doesn't exist on the physical screen so it might be indeed vaapi, ffmpeg thing. |
|
@DistantThunder great spot. That's the root cause - ffmpeg synchronization during encoding. I compiled the ffmpeg code with the first patch provided in the mesa thread and it fixes tearing issue. They mention that it is a workaround and not real fix, but it does the thing for now so I will use it till the real fix is provided in ffmpeg code. I'm sharing the Linux-x86_64 compiled ffmpeg with the patch that can be used with Sunshine compilation (Sunshine/third-party/build-deps/ffmpeg/Linux-x86_64) |
|
@neatnoise could you submit a PR with the patch to https://github.com/LizardByte/build-deps |
Added FFmpeg Vulkan synchronization fix. Worth to mention that it is a workaround and should be monitored and removed when the real fix is provided in FFmpeg project |
|
@neatnoise Nice! Did you patch your system's ffmpeg? |
|
@DistantThunder Sunshine uses its own built static FFmpeg library, not system's one. It is here https://github.com/LizardByte/build-deps |
|
@neatnoise even when building locally (I'm using Git)? |
|
Yes, when you clone Sunshine repo and its submodule repos (listed in .gitmodules), one of them is build-deps which includes ffmpeg and other libraries already compiled as a static libraries which Sunshine uses during its build process. I included already fixed compiled ffmpeg by me manually in the previous comment which could be just replaced |
|
Ah yes, thanks for the help, I could do this like this on Arch with the Sunshine PKGBUILD : |
|
No, it's not compiled yet. |
Sorry, I meant I compiled my own build with the patch. Will test soon. |
|
You can't use any git commit for build-deps in a PKGBUILD because the patch hasn't been compiled into the |
|
@ReenigneArcher I eventually made my own build: https://github.com/DistantThunder/sunshine-build-deps/actions/runs/11020194305/job/30604435143 It makes things noticeably better but the tearing persists. |
|
Thanks for the update |
|
I restarted my machine and upgraded to Mesa 24.2.3. I could no longer see the tearing with the same Sunshine build but I had stutters in heavy action scenes with the scene sometimes clipping. Getting closer it seems. |
|
@DistantThunder try to use the latest ffmpeg dev code. There is a proper fix already in master ffmpeg branch. It works the best for me. Change in file https://github.com/LizardByte/build-deps/blob/master/.gitmodules reinit git submodules and compile build-deps |
|
@neatnoise Will test. I was afraid Sunshine bindings were not compatible with upstream latest. So I have to remove the patches? |
Yes, I built without any patches and works fine |
|
@neatnoise Current master looks broken: I had to correct cbs imports as well (DistantThunder/sunshine-build-deps@f4d417c) What commit did you use? |
|
FFmpeg/FFmpeg@a577d31 This one. I didn’t have to change anything to build it |
|
Ok, I don't know then I can't compile Sunshine using the dist build with that ffmpeg commit. |
|
Our "dist" build is pre compiled. We haven't compiled that commit into it. You have to compile ffmpeg yourself, as we do in build-deps, then replace the submodule with your precompiled version. |
|
@ReenigneArcher That's what I do, I point the Sunshine build at my own forked repo:
|
|
I use act to simulate github workflow with modified build-ffmpeg.yml a bit:
|
|
@neatnoise Can you zip link your ffmpeg build-deps outputs? I suspect your "copy all build outputs for sunshine tree" may be the key here. |
|
This is FFmpeg/FFmpeg@a577d31 commit build |
|
Thank you! For some reasons, some includes for config.h headers are borked in my build. |
|
We're working on updating ffmpeg to 7.1, which will properly fix this. LizardByte/build-deps#359 |
|
Yes, I just made a build using cgutman repo as a remote and the build worked with latest master this time. |
|
I have similar conclusions. Tearing is fixed, but there is kind of stuttering. The feeling is similar like network lags in games, it backs off and forward a bit when the character is moved. Probably also ffmpeg causes it. |
|
I recorded a video displaying the stuttering issue. Looks like the frames are not displayed in order, or in the right time (delayed). It adds latency unfortunately, it is hard to react for the user in fast games and tiring for the eyes. No screen tearing. The issue is specially visible when the frames are generated close to 60 fps (45-59 fps) with 60 hz monitor. FFMPEG master was used https://www.youtube.com/watch?v=D8LE-SqZV6w |
|
Did the update to ffmpeg 7.1 fix the tearing? I still have tearing issues on v2024.1211.191744 (fedora 41, installed from the beta copr). |
|
Those still experiencing stuttering, do you have VSync enabled or disabled? If enabled, can you try disabling it and report back? |
|
Do you mean in the game? I get tearing with both vsync on and off. |
|
I experience stuttering with latest master of sunshine. There is no tearing with vsync on for me. |
|
Experiencing this exact issue on latest Bazzite. The comment previously about "frames are not outputted in order" rings. Locking in-game fps to 30 on a 60 or 120fps capture makes it more obvious, almost looks like the captured frames loop over each other on the client. Is it possible that instead of dropping off-frames the capture re-use 3-4 frames until sync has been achived? |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
Even with VSync enabled both in KDE desktop environment settings and individual game settings, screen tearing still occurs in most games that I have. I am running the latest version of Arch Linux with KDE Plasma Wayland (ver 6.1.5) installed. I primarily experience the issue in games through DXVK. Some games handle VSync correctly, while others consistently show tearing (e.g., Amnesia The Bunker, The Witcher, Mafia: Definitive Edition). It is a quite aggressive tearing, after a while it is tiring for the eyes.
This issue occurs across devices when using the Moonlight client (MacOS, iOS), but is not a client problem as the same problem is noticeable on different client systems. Games run correctly on a physically connected monitor with VSync enabled, but tearing appears when using the Moonlight client, even though VSync is also enabled in the client. I use the latest Moonlight (ver 6.0.1) for MacOS (11.7).
EDIT: Gnome 46 Wayland (Arch linux) also has the same issue. So it could be Wayland desktops related.
I recorded a short video showing the issue https://www.youtube.com/watch?v=4bVXx2cKRP8
Steps to Reproduce:
Expected Behavior
No tearing with vsync on.
Additional Context
No response
Host Operating System
Linux
Operating System Version
Latest Arch Linux
Architecture
64 bit
Sunshine commit or version
Latest git master
Package
Linux - AUR (Third Party)
GPU Type
AMD
GPU Model
AMD Radeon RX 580
GPU Driver/Mesa Version
Mesa 24.2.2
Capture Method
wlroots (Linux)
Config
channels = 3 nv_rc = auto address_family = both resolutions = [ 1280x720, 1920x1080 ] encoder = vaapi file_state = fps = [60] upnp = enabled nv_preset = default lan_encryption_mode = 2 wan_encryption_mode = 2 external_ip = cert = pkey =Apps
No response
Relevant log output
The text was updated successfully, but these errors were encountered: