https://bugs.kde.org/show_bug.cgi?id=523500
Bug ID: 523500
Summary: VRR has stutter/mistimed frames only under Wayland
Classification: Plasma
Product: kwin
Version First unspecified
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 194607
--> https://bugs.kde.org/attachment.cgi?id=194607&action=edit
VRR pursuit photo with a clean photo and a captured stutter
DESCRIPTION:
I will preface this report with that this is a very difficult to demonstrate
problem. This is partly due to how persistence blur on most monitors hides this
issue. Additionally, your eyes (or camera) will notice the problem most when
following motion onscreen making clear captures difficult.
My current monitor is one of the new Gsync Pulsar screens which are the first
monitors with a proper VRR + strobed backlight implementation. Low persistence
(due to the strobed backlight) makes any problem with VRR very obvious and is
what made me notice this issue in the first place.
STEPS TO REPRODUCE
1. Engage VRR in any application
2. Observe small hitches and stutters when motion should be completely smooth
OBSERVED RESULT
- Motion hitches with consistent timing, about every second or so. The timing
of how fast these stutters occur seems to change with the framerate. For
example 120fps@360hz VRR appears to hitch every 2sec, while 240fps is closer to
a small hitch every second.
- The computer in a controlled VRR test reports near perfect frametimes (Only
varying by ~0.2ms) despite clearly visible stutters
- The Pulsar monitor disengages the strobed backlight and quickly reengages it
after each hitch. The monitor does this to avoid big brightness changes and
flicker if the frametime suddenly spikes. This suggests the computer is
reporting flat frametimes through MangoHUD & in-engine fps counters, but the
monitor somehow does not get the next frame when it should?
- No combination of window rules (Block compositing, Allow tearing, force VRR)
or even experimental Wayland Proton flags for games have any effect on the
issue
- Completely unplugging all other monitors has no effect on the problem
- Setting framerate to be right below refresh rate with a VRR test (i.e
357fps@360hz) shows that the tearline doesn't appear to be steered offscreen
properly like in Windows or X11. In Wayland, the tearline repeatedly and
erratically jumps near the top of the screen and quickly moves downwards off
the screen. On Windows/X11 the tearline stays offscreen.
- Monitor's OSD shows fluctuations around reported framerate
EXPECTED RESULT
- Motion should remain completely smooth when inside the VRR range as it does
on Windows and X11
- Tearline should not have such erratic behavior when close to the top of the
VRR range (when screen tearing is enabled)
- Monitor's reported framerate in the OSD should stay synced with reported
framerate
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.4-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 3080
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B550 AORUS PRO V2
ADDITIONAL INFORMATION
- Please see this Blurbusters article for more information on the sync track
https://blurbusters.com/motion-tests/pursuit-camera/
- SmoothFrog is a great VRR testing tool which I used to try capturing this
issue
https://www.aperturegrille.com/software/
- The pursuit photo attached was taken with a camera following the motion with
the shutter speed set to 1/4th of the VRR framerate. The "clean" photo shows a
grid of vertical lines meaning the camera stayed in sync with the display's
motion for the four frames captured in the photo. The next captured frame is
the "Stutter" photo. Notice how the vertical lines are broken up. Because the
immediate frames before and after the captured stutter were "clean" pursuit
photos, I know that the camera was very likely in sync during the "Stutter"
photo. This means the broken sync lines appear to show one frame during the
camera's capture was mistimed somehow. (One rectangle out of the four is
slightly behind [Motion captured moving right to left], suggests one frame is
late?)
--
You are receiving this mail because:
You are watching all bug changes.
