| Bug ID | 94903 |
|---|---|
| Summary | Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays. |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | major |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | johngaltfirstrun@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
When running weston on this hardware with Shimian QHD270 displays, vblanks are skipped resulting in stuttering video playback on any framerate other than 60fps (with multiple players and vo including opengl and wayland (shm)). System: Mesa: git linux: 4.4, 4.5, 4.6 from a drm-next-wip branch wayland: git weston: git A few notes: - This doesn't occur when using amdgpu (for instance building with hawaii amdgpu support. - This bug goes back as far as a year, and another user verified they had this issue on a radeonsi card with a specific monitor. - When utilizing amdgpu, the EDID is correctly read from these monitors. Without, the EDID read fails. I've written the EDID to a file in /lib/firmware/ and successfully loaded with no change however. - Outside of video playback, there are no vblank skips. It was explained that each application affects the entire compositor. - No change on video size. The issue is apparent (with no discernible change) on non-60fps 360p youtube videos on up to high bitrate x265 4K tv shows. - By increasing repaint-window, I'm able to get consistent playback and no vblank skips. However I do run into other issues with it, showing it's clearly not a real solution for wayland support on radeon. - During video playback, weston-presentation-shm shows the missing vblanks just as a timeline does (so including weston-presentation-shm log for readability instead). weston-presentation-shm log with video playback at beginning: https://bpaste.net/show/f8c9b910ddc1. When vblanks are no longer skipped, the video playback has stopped.
Please write 63 to /sys/module/drm/parameters/debug before reproducing the problem and 0 again afterwards, then attach the dmesg output generated in between.
Created attachment 122877 [details]
Dmesg of video playback with skipped vblanks with
/sys/module/drm/parameters/debug set to 63 then 0 afterward.
I've been able to "fix" the issue for tahiti and hawaii (without amdgpu) by forcing an even 60.0hz refresh rate on this display. Despite the workaround, I believe there's still a bug here. So I'm leaving the report open.
I noticed something interesting: mpv was getting a reported refresh rate of 60.0hz in weston which is incorrect, actual display refresh rate is 59.951hz (if I don't force it to 60.0hz as a workaround). In X, it gets the correct refresh rate. I was about to override the reported refresh rate to 59.951hz for mpv and play a video without stutters, and without changing monitor's refresh rate. weston-presentation-shm is also consistent with no vblank skips during playback this way (at least with mpv playback). I suspect other applications are also getting an incorrect reported refresh rate.
(In reply to John Galt from comment #4) > I was about to override the reported refresh rate to 59.951hz for mpv and > play a video without stutters, [...] How exactly did you override it?
In mpv I set display-fps to 59.951. But this only fixes mpv. I ended up creating a custom EDID set to 60.0hz, and loading that at boot to fix other apps as well (no mpv trickery needed this way either). If I switch to amdgpu, mpv (and apparently other apps) get the correct refresh rate (59.951hz), and none of this is needed.
| What | Removed | Added |
|---|---|---|
| Version | git | unspecified |
| Component | Drivers/Gallium/radeonsi | DRM/Radeon |
| QA Contact | dri-devel@lists.freedesktop.org | |
| Product | Mesa | DRI |
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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/amd/issues/706.