Bug 487605 - XWayland Vulkan fifo vsync limits at doubled maximum refresh rate with VRR since KWin 6.1 beta 1
Summary: XWayland Vulkan fifo vsync limits at doubled maximum refresh rate with VRR si...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git-stable-Plasma/6.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 487622 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-05-27 00:41 UTC by tempel.julian
Modified: 2024-06-05 19:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tempel.julian 2024-05-27 00:41:39 UTC
SUMMARY
My display's maximum refresh rate is 165Hz, but fps get capped at 330fps since KWin 6.1 beta 1.

STEPS TO REPRODUCE
1. Leave VRR at auto default
2. Start a game in Proton with e.g. VKD3D-Proton
3. In the game, enable vsync

OBSERVED RESULT
Frame rate gets capped at maximum refresh rate multiplied with 2. With VRR set to "never" in KWin settings, vsync correctly caps the fps at the display's exact maximum refresh rate also with KWin 6.1 beta 1.

EXPECTED RESULT
Like with 6.0, fifo vsync should cap at the exact maximum refresh rate, also with VRR enabled.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.9.2
KDE Plasma Version: 6.1 beta 1
KDE Frameworks Version: 6.2
Qt Version: 6.7.1

ADDITIONAL INFORMATION
Radeon RX 7800 XT
Comment 1 Bug Janitor Service 2024-05-27 12:08:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5779
Comment 2 Zamundaaa 2024-05-27 12:59:14 UTC
*** Bug 487622 has been marked as a duplicate of this bug. ***
Comment 3 Zamundaaa 2024-05-27 23:32:35 UTC
Git commit 97c1d335e5f9b36574f7778a97e9ad4c616f9bf2 by Xaver Hugl.
Committed on 27/05/2024 at 23:23.
Pushed by zamundaaa into branch 'master'.

backends/drm: delay atomic commits until the time they're meant for

Otherwise, if render time prediction and actual render time are very different,
a lot of frames get dropped and in some cases more frames than is useful are
rendered, creating stutter instead of only unnecessary latency

M  +25   -0    src/backends/drm/drm_commit.cpp
M  +4    -0    src/backends/drm/drm_commit.h
M  +22   -18   src/backends/drm/drm_commit_thread.cpp
M  +1    -1    src/backends/drm/drm_commit_thread.h
M  +6    -0    src/core/renderbackend.cpp
M  +3    -0    src/core/renderbackend.h

https://invent.kde.org/plasma/kwin/-/commit/97c1d335e5f9b36574f7778a97e9ad4c616f9bf2
Comment 4 Zamundaaa 2024-05-27 23:46:47 UTC
Git commit ed445ede2abad8f89406163309d56911cb8270f7 by Xaver Hugl.
Committed on 27/05/2024 at 23:36.
Pushed by zamundaaa into branch 'Plasma/6.1'.

backends/drm: delay atomic commits until the time they're meant for

Otherwise, if render time prediction and actual render time are very different,
a lot of frames get dropped and in some cases more frames than is useful are
rendered, creating stutter instead of only unnecessary latency

M  +25   -0    src/backends/drm/drm_commit.cpp
M  +4    -0    src/backends/drm/drm_commit.h
M  +22   -18   src/backends/drm/drm_commit_thread.cpp
M  +1    -1    src/backends/drm/drm_commit_thread.h
M  +6    -0    src/core/renderbackend.cpp
M  +3    -0    src/core/renderbackend.h

https://invent.kde.org/plasma/kwin/-/commit/ed445ede2abad8f89406163309d56911cb8270f7
Comment 5 tempel.julian 2024-05-30 17:03:42 UTC
If I didn't make a mistake applying these commits on top of beta 1, it's not fixed for me. Also mpv with --video-sync=display-resample reports erroneous doubled refresh rate in fullscreen with VRR set to auto in kwin.
Comment 6 tempel.julian 2024-06-02 17:39:39 UTC
Since I can see tearing with !4800 patched in, I think I can safely assume that this issue indeed isn't fixed by the aforementioned commits. I patched in

5e122cb6c0e4b2573ac568b040b9a9187e8d8313
97c1d335e5f9b36574f7778a97e9ad4c616f9bf2
804ecb0e22d77daae06f435060848993567753a2
2cf36e640ff35ca777f989aee43cfbf4300d1ace

on top of beta 1 and vsync still caps at maximum refresh rate x 2 with VRR active.
Comment 7 Bug Janitor Service 2024-06-05 14:41:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5838
Comment 8 Zamundaaa 2024-06-05 19:32:53 UTC
Git commit 76739f1f2fc1abcbf6b7de39215a7de0a74675e3 by Xaver Hugl.
Committed on 05/06/2024 at 19:24.
Pushed by zamundaaa into branch 'master'.

core/renderloop: don't do triple buffering with vrr or tearing

While in theory it could be useful with both, I'm not sure that it makes sense
in practice, and the current triple buffering logic doesn't support it.

M  +4    -2    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/76739f1f2fc1abcbf6b7de39215a7de0a74675e3
Comment 9 Zamundaaa 2024-06-05 19:50:15 UTC
Git commit 8dfcd59361efb20af2ef84f1f1e99aaaeb37844c by Xaver Hugl.
Committed on 05/06/2024 at 19:39.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core/renderloop: don't do triple buffering with vrr or tearing

While in theory it could be useful with both, I'm not sure that it makes sense
in practice, and the current triple buffering logic doesn't support it.


(cherry picked from commit 76739f1f2fc1abcbf6b7de39215a7de0a74675e3)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +4    -2    src/core/renderloop.cpp

https://invent.kde.org/plasma/kwin/-/commit/8dfcd59361efb20af2ef84f1f1e99aaaeb37844c