Bug 490876

Summary: Proton games locked to display's refresh rate with kwin 6.1.3
Product: [Plasma] kwin Reporter: d3vilguard <g.ignatov>
Component: xwaylandAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED UPSTREAM    
Severity: normal CC: nate, xaver.hugl
Priority: NOR    
Version First Reported In: 6.1.3   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: drirc for doom eternal

Description d3vilguard 2024-07-27 05:23:30 UTC
SUMMARY
DOOM Eternal launches at 330 FPS (v-sync OFF) but gameplay is choppy. After alt-tabbing and returning to the game, the game gets locked at 165fps (monitor refresh rate). Monitor is set at 165hz and VRR is set to Adaptive.

STEPS TO REPRODUCE
1. Launch DOOM Eternal
2. Alt-tab / press meta and return to the game

OBSERVED RESULT
Gameplay is choppy
FPS in menu should be a bit higher than 330 (around 350 if all was normal)
Game gets locked to monitor refresh rate after minimizing and maximizing it

EXPECTED RESULT
Smooth gameplay and no locked FPS

SOFTWARE/OS VERSIONS
Linux: Arch KDE Wayland
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
AMDVLK : NO
Mesa: Mesa 24.2.0-devel (git-17c12a9924) (mesa-minimal-git compiled in a clean chroot against llvm-minimal-git. This build was used with kwin 6.1.2 with zero framerate issues!)
Kernel: 6.9/6.10

ADDITIONAL INFORMATION
Restarting the game, steam, system does not fix the problem.
Downgrading kwin to 6.1.2 fallowed by a simple logout and login after the downgrade fixes the issue. DOOM opens up with high FPS and stays with high FPS. Actually here is some gameplay with 6.1.2 showing alt-tabbing: https://www.youtube.com/watch?v=BrqG-6d27_w

Now what is strange is that afterwards kwin can be updated back to 6.1.3 and the issue will not be immediately there. 
I can recreate the cycle of 6.1.3 having locked FPS / choppiness problems > downgrading to 6.1.2 to fix > upgrading to 6.1.3 with no problems > 6.1.3 starting to have the problems again > repeat

Video showing the problem on 6.1.3:
https://www.youtube.com/watch?v=P3ohvJDBJfc
Comment 1 Zamundaaa 2024-08-05 19:45:45 UTC
I can confirm some weirdness at least. When I launch Doom Eternal, it launches with direct scanout working and the fps is limited to the refresh rate - the game reports that it's spending a lot of time on the CPU, which is almost certainly vkQueuePresent blocking in the driver.

When I force compositing, for example by showing the volume popups, the game pushes a lot more fps. Do you see the same?
Comment 2 Zamundaaa 2024-08-05 20:01:04 UTC
Created attachment 172320 [details]
drirc for doom eternal

I found a workaround for Doom Eternal in Mesa, which forces it to use more images for immediate mode presentation, because otherwise the game might just allocate two, which would explain this fps limitation. If I manually set this workaround by placing the attached file in my home directory, Doom Eternal always has unlimited fps.

So I think the workaround isn't being applied properly anymore in Mesa. I don't know why KWin 6.1.3 vs 6.1.2 would make a difference, but it might be that direct scanout was suppressed more often in 6.1.2.
Comment 3 d3vilguard 2024-08-08 12:24:57 UTC
(In reply to Zamundaaa from comment #2)

Upgraded to 6.1.3. Changing volume via shortcut does infact make the game render more fps. Can't seem to get the drirc working.
Comment 4 d3vilguard 2024-08-08 12:30:12 UTC
(In reply to Zamundaaa from comment #2)
> Created attachment 172320 [details]
> drirc for doom eternal
> 
> I found a workaround for Doom Eternal in Mesa, which forces it to use more
> images for immediate mode presentation, because otherwise the game might
> just allocate two, which would explain this fps limitation. If I manually
> set this workaround by placing the attached file in my home directory, Doom
> Eternal always has unlimited fps.
> 
> So I think the workaround isn't being applied properly anymore in Mesa. I
> don't know why KWin 6.1.3 vs 6.1.2 would make a difference, but it might be
> that direct scanout was suppressed more often in 6.1.2.

okay, way easier to vk_x11_ensure_min_image_count=true vk_x11_override_min_image_count=4 %command% as a launch option.

Game seems alright now with 6.1.3.
Comment 5 d3vilguard 2024-08-10 16:46:44 UTC
Tried 6.1.4 also with mesa git-1a579552af. Take aside the locking of the FPS upon alt-tabbing. Without the options menu FPS is lower than it should be. When playing around with the volume I am getting 405 in the menu. Without the options I'm around 360. 

I have noticed that vk_x11_override_min_image_count=6 is better than 4. I'm able to stay around 405 in the menu but it constantly fluctuates (400-410). If playing around with the volume it's more stable at around 405. Place advice if I should open a bug at mesa instead of here.
Comment 6 Zamundaaa 2024-08-19 12:23:20 UTC
More than 4 buffers can provide very slightly less time where the app needs to wait for a buffer, that bit's not super surprising.

(In reply to d3vilguard from comment #5)
> Place advice if I should open a bug at mesa instead of here.
I think an issue for Mesa about this might be more actionable than this.