Created attachment 146003 [details] dmesg log of the test system Originally reported here, but posting here in case it might be a kernel issue: https://gitlab.freedesktop.org/mesa/mesa/issues/2048 The issue: Stutter free video playback is not possible on Gemini Lake with Wayland compositors. To reproduce, run mpv 0.30 via "mpv --no-config --video-sync=display-resample --hwdec=vaapi http://www.oc-burner.de/ftp/Videos/juddertest/juddertest_60.mp4" on a ~60Hz display in a Weston or Sway Wayland session (mpv automatically uses native Wayland windowing, no xwayland involved). There is stutter each few seconds, thus mpv's statistics recognize vsync jitter spikes and in the wake mistimed or delayed frames (either watch mpv's terminal output or enable LUA stats via Shift + i). There is no stutter with xf86-video-intel DDX on Xserver (also not in fullscreen with pageflipping triggered). There is also no stutter with AMD GPU on Wayland, so the root of the issue should not lie in mpv. modesetting DDX on Xserver shows a very similar (if not exactly the same?) issue as Wayland with Intel graphics, if that's important. Though there probably is xf86-video-intel for a good reason, so perhaps the Wayland situation is more deserving of attention. Issue also ocurs with --hwdec=vaapi-copy, which uses the same windowing context as software decoding. Tested on Arch Linux / Manjaro 5.3.8 xorg 1.20.5-4 from Arch/Manjaro repo Weston 7.0.0 recent sway-git/wlroots-git which supports correct vsync presentation feedback Attaching a dmesg log of the test system.
We need continuous monitoring of frequency, GPU pipelines, and display piplines to correlate the system activity with presentation jitter. We can the former with perf, but we could do with overlaying/interspersing the jitter warnings from mpv. For bonus points, RT graphs in an overlay.
I'd gladly provide any debug output, but you would need to tell me what exactly to do.
Reporter, Can you reproduce this issue using drm-tip (https://cgit.freedesktop.org/drm-tip) with kernel parameters drm.debug=0x1e log_buf_len=4M. If the problem persists attach the full dmesg from boot.
Apart from DRM commits, this kernel branch should be safe to use? The device's filesystem is encrypted and I'd rather not like to experience nasty surprises. :) If that's not to be expected, I'll try it.
(In reply to tempel.julian from comment #4) > Apart from DRM commits, this kernel branch should be safe to use? Fairly safe. Up to linus as of v5.4-rc8, https://intel-gfx-ci.01.org/tree/drm-tip/combined-alt.html? is reasonably happy right now. Fwiw, I don't think we have the means to capture the right debug data for transient issues like this. I keep meaning to spending some time on the tooling so we can, it's just that "minor" issues like this get overlooked when trying to put out fires.
Created attachment 146011 [details] dmesg debug log
I've attached a dmesg debug log which was written by the latest drm-tip kernel after triggering the issue.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/629.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.