Closed ThatOneCalculator closed 1 month ago
sway?
It works fine for me on Steam, did you try it ?
Sway is weird and refuses to launch apps for me, but Wayfire (built as wayfire-git from the aur) gives the sane performance as GNOME, so it does appear to be Hyprland specific.
It works fine for me on Steam, did you try it ?
Lutris just acts as a launcher for Steam games, although I did try Steam directly and got the same results.
Same here but with other games, Games stuttering compared to KDE in my case.
but Wayfire (built as wayfire-git from the aur) gives the sane performance as GNOME, so it does appear to be Hyprland specific.
wf doesn't use wlroots-git. It might be a wlr issue after all.
Can anyone check sway-git?
Apex works well for me through steam. I will say a fresh apex install stutters for me at first until it compiles/caches shaders. Not sure if thatβs what your experiencing or not
Nah, I went into firing range for almost half an hour and it was still constantly stuttering.
Tested sway-git it seems it gave me fluid experience on gaming compared to hyprland, but I had mouse issues on sway.
Any news?
No, idk what's up
Maybe updating to the latest version of wlroots will fix it? I've seen that they've made a lot of changes. Non-git sway seems have for me have some stuttering.
we are not that far behind -git.
we are not that far behind -git.
Still it's a try.
Try to isolate the issue. It runs perfectly fine on my end. Both on Sway and Hyprland.
Does it present on latest -git version wlroots had update
I can test tomorrow
I can confirm. The problem is present on hyprland-git+wlroots-git but not on wlroots+hyprland. The bug is several stuttering and -10 -20 fps
I've noticed this as well.. Sway/GameScope is visibly smoother than Hyprland (GIT). Although according to Mangohud, frametimes and fps are very similar (makes me wonder if it's something else)?
GPU: AMD Radeon RX 6800 XT CPU: Ryzen 9 5950X
I can confirm. The problem is present on hyprland-git+wlroots-git but not on wlroots+hyprland. The bug is several stuttering and -10 -20 fps
Hyprland bundles wlroots, your system wlroots don't matter.
If this is a regression, I'd like a git bisect
to be done.
I can confirm. The problem is present on hyprland-git+wlroots-git but not on wlroots+hyprland. The bug is several stuttering and -10 -20 fps
Could you test with kernel command line parameter gpu_sched.sched_policy=0
@vaxerski I noticed that if I move with just the keyboard, the stuttering isn't visible (Halo Infinite in my instance but it's most likely the same issue as with Apex Legends). The stuttering/jitter is extreme when moving the mouse even though the frametime is low and fps relatively high.
Could this be related? https://gitlab.freedesktop.org/drm/amd/-/issues/2186
This issue was mentioned here as well https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_897546
One thing that hasn't been mentioned here yet might warrant a protocol for VRR: the hardware cursor. When the application controls the refresh rate a hardware cursor will refresh slowly and stutter, when the cursor controls the refresh rate the application content will appear to stutter. There is also the option of refreshing the panel with a multiple of the application refresh rate while the cursor is changing but that has its limits in hardware and might still cause stutter with strongly fluctuating frame times, though the latter could be somewhat alleviated with present-timing.
What I implemented for KWin is to always give the cursor precedence (I think in Sway it's the same?) and we'll give the user the option to disable that (for fullscreen) but that's far from ideal. While apps that explicitly want to control their timing could always draw a software cursor (or with present-timing only when VRR presentation occurs) that's not really a good solution either.
@vaxerski I noticed that if I move with just the keyboard, the game is completely smooth (Halo Infinite in my instance but it's most likely the same issue as with Apex Legends). The stuttering only occurs when I actually move the mouse.
Could this be related?
One thing that hasn't been mentioned here yet might warrant a protocol for VRR: the hardware cursor. When the application controls the refresh rate a hardware cursor will refresh slowly and stutter, when the cursor controls the refresh rate the application content will appear to stutter. There is also the option of refreshing the panel with a multiple of the application refresh rate while the cursor is changing but that has its limits in hardware and might still cause stutter with strongly fluctuating frame times, though the latter could be somewhat alleviated with present-timing. What I implemented for KWin is to always give the cursor precedence (I think in Sway it's the same?) and we'll give the user the option to disable that (for fullscreen) but that's far from ideal. While apps that explicitly want to control their timing could always draw a software cursor (or with present-timing only when VRR presentation occurs) that's not really a good solution either. (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_897546)
Could you test with kernel command line parameter gpu_sched.sched_policy=0
There's no difference with gpu_sched.sched_policy=0
on a RX 6800 XT :/
There's no difference with
gpu_sched.sched_policy=0
on a RX 6800 XT :/
Does enabling vsync fixes stuttering?
Does enabling vsync fixes stuttering?
I've tried enabling/disabling these to no avail:
I may be wrong but it seems like this issue is correlated to the mouse cursor, moving around in game with just the keyboard isn't as jittery/stuttery.
For Sway/wlroots, there's some workarounds (patches) here if it's indeed the mouse cursor causing it (but Hyprland would need to be tweaked to use this patch which is outside of my expertise):
@ThatOneCalculator This is how the stuttering looks on my end. Is it the same as yours?
@ThatOneCalculator This is how the stuttering looks on my end. Is it the same as yours?
Try switching to linux-lts kernel. It should fix.
@GrabbenD mine is a bit more ittermittent
Try switching to linux-lts kernel. It should fix.
Thanks for the idea Certain kernels make the issue less apparent but it's still there π . Here's all I've tried:
Try switching to linux-lts kernel. It should fix.
Thanks for the idea Certain kernels make the issue less apparent but it's still there π . Here's all I've tried:
- 5.15.109-LTS
- 6.1.26-LTS
- 6.1.26-RT
- 6.1.13-rt7-xanmod (smoothest in my opinion)
- 6.2.11-xanmod
- 6.2.13-LQX
- 6.2.13-ZEN
- 6.2.13-TKG
Reason i suggested because 6.2.x has some stuttering issues that was introduced meanwhile 6.1 has less
I've been testing on both hyprland and hyprland-git today and I cannot reproduce now. My kernel is beign josh's 6.0.0-1-hdr-git-02753-gff57328e5784 for all my tests so far. I'll keep an eye on this issue in case I can find something conclusive.
Thanks for the update @Zeioth
I'm in progress of trying OpenSuSE instead of NixOS.
Update: the stuttering in NixOS (hyprland-git https://github.com/hyprwm/Hyprland/commit/2e28e88dfdca3d836c5dbedb916e0f629fc6a540) is worse than with OpenSuSE Tumbleweed (Hyprland v0.24.1). OpenSuSE improves fps by 20-30 & decreases frametime with 3-4ms since they're using x64_86-v3 optimization level with LTO+PGO.
Turns out the stuttering only happens when the game runs below my monitor's refresh rate even with vrr=1
~> hyprctl monitors
Monitor DP-3 (ID 0):
3840x1600@119.982002 at 0x0
description: Dell Inc. Dell AW3821DW #HLAYMxgwABTR (DP-3)
make: Dell Inc.
model: Dell AW3821DW
serial: #HLAYMxgwABTR
active workspace: 2 (2)
reserved: 0 0 0 0
scale: 1.00
transform: 0
focused: yes
dpmsStatus: 1
vrr: 1
My monitor's Freesync range is 1-144 hz and it even has a dedicated GSync Ultimate chip :/
For clarification, I pretty much only installed Hyprland, xdg, MESA, codecs, kernel-firmware, pipewire, steam, mangohud & gamemoded while testing this.
Another update:
Changing power profile for the GPU (/dev/dri/card0
) greatly improved 1% lows and avg fps but the stuttering is still visible when fps falls below monitor's refresh rate:
# /etc/udev/rules.d/30-amdgpu.rules
KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="manual", ATTR{device/pp_power_profile_mode}="1"
(see: https://gitlab.freedesktop.org/drm/amd/-/issues/1500#note_1854170)
Furthermore I tried using async frames (MESA_VK_WSI_PRESENT_MODE
) but it looks like it's not supported by wl-roots yet.
(see: https://docs.mesa3d.org/envvars.html#envvar-MESA_VK_WSI_PRESENT_MODE)
(reference: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/65 & https://patchwork.freedesktop.org/series/107683/)
Does enabling vsync fixes stuttering?
Current conclusion: vsync off (ingame) + vrr=0 (Hyprland)
performs exactly the same as: vsync off (ingame) + vrr=1 (Hyprland)
(it vastly reduces stuttering but it's still there when fps < refresh rate)
It seems like Variable Refresh Rate (VRR) in Hyprland doesn't actually adjust monitor's refresh rate in that case? I have no way of verifying this in my panel unfortunately
@ThatOneCalculator If your intermittent stuttering is actually caused by frame drops and not something else like the old fTPM stutter bug in AMD CPUs, I don't think there is much we can do about it until the VRR implementation gets improved: https://github.com/hyprwm/Hyprland/issues/927
Workaround: https://github.com/hyprwm/Hyprland/issues/927#issuecomment-1556270866
Related issues:
Other/gaming related:
@ThatOneCalculator Isn't that connected?
https://github.com/hyprwm/Hyprland/issues/1919
Check it with hyprctl keyword debug:overlay true
Great find @grappas!
On my end VRR/vsync seems to be the culprit as the compositor's FPS is correct (debug:overlay=1
+ misc:vfr=0
):
Great find @grappas! On my end VRR/vsync seems to be the culprit as the compositor's FPS is correct (
debug:overlay=1
+misc:vfr=0
):
But just to be sure check it CPU bottlenecked (lowest settings possible).
Workaround for VRR stuttering: https://github.com/hyprwm/Hyprland/issues/927#issuecomment-1556270866
But just to be sure check it CPU bottlenecked (lowest settings possible).
Sure @grappas, I can reproduce your issue by forcing my game to be CPU bound. Let's continue the discussion here: https://github.com/hyprwm/Hyprland/issues/1919#issuecomment-1556268402 (since it's unclear if this PR is about stuttering from VRR or resource starvation as the author isn't replying).
Same here on sway. For me is the only way to smooth run Apex is turn screen mode to Windowed and run sway with -Dnoscanout
. Switch to Fullscreen or Borderless causes immediate stuttering. Removing noscanout option completely disables vrr. Really annoying but it works for now. Can someone else check that Windowed mode helps with stuttering?
why not try on -git with tearing?
why not try on -git with tearing?
Can confirm it works but personally not a fan of tearing. Fells pretty stuttery even witn 200+ fps on 144Hz monitor. I'm looking for smooth vrr gameplay, but this game even with regular vsync is kinda of a mess.
I have not found any way to resolve this in Hyprland π It has the worst stuttering in comparison to Sway, KDE (Wayland) and RiverWM. However, I have a really good solution for Sway:
There's 2 parts to this problem
I've tried this with a RX 6800 XT + Ryzen 9 5950X (fTPM off) + 1000Hz mouse and confirmed this issue exists in multiple monitors in Arch Linux, Fedora & OpenSuSE Tumbleweed:
why not try on -git with tearing?
Thanks for the idea but this makes it worse, the stuttering is still there and in-game textures are completely smeared out due to tearing.
no. 1. has no fix for us AFAIK, it requires a wlroots patch.
no. 2. misc:no_direct_scanout
exists and is on by default
@vaxerski My monitor's built-in FPS counter reports 6 HZ in desktop when VRR is enabled with Sway. However, with Hyprland it's stuck at 120Hz all the time, even when playing games at 80 FPS. What's strange is that the monitor claims adaptive sync is enabled when using Hyprland. I'm guessing something in Hyprland is constantly pushing max FPS to the screen - maybe to make the animations buttersmooth?
I've tried isolating this issue with various combinations of settings to no avail:
misc:vrr
2/1misc:vfr
1/0misc:no_direct_scanout
1/0debug:damage_tracking
2/1/0I'm not sure what else to try, I've back revising this issue once in a while since March of this year (when I started using Hyprland)
what if you enable tearing? without that it will push 2x fps of your game most likely
However, with Hyprland it's stuck at 120Hz all the time,
It's actually a gamescope thing. If you want i.e. 240Hz you want to set -r 480.
Thanks for taking a look guys!
what if you enable tearing? without that it will push 2x fps of your game most likely
My games are GPU bounds I'm getting stable 80-90 FPS Enabling tearing gives me the same result as @roman3pm, it's still stuttering since the monitor is stuck at 120 HZ
It's actually a gamescope thing. If you want i.e. 240Hz you want to set -r 480.
I don't use Gamescope since I haven't found any performance difference when it's running in nested mode. Nonetheless I tried gamescope -f -r 120 -- %command%
and gamescope -f -r 240 -- %command%
but the monitor is still stuck at 120 HZ
@vaxerski When I say the monitor is stuck at 120 HZ, I mean it. It never dips below 120 HZ in Hyprland (in desktop / when watching youtube / playing Steam games / switching workspaces). I find it strange that I can reproduce this issue on 3 different monitors I'm currently running Arch Linux with pretty much defaults settings everywhere, I only installed MESA drivers, Pipewire, Wireplumber, Pavucontrol, Steam, Halo Infinite, Brave browser & Foot terminal.
Have you tried forcing fps with mangohud?
Apex Legends stutters immensely when compared to GNOME despite being launched the exact same way (Lutris with gamescope enabled)