https://bugs.freedesktop.org/show_bug.cgi?id=89987
Bug ID: 89987 Summary: Slow VDPAU (rv770_restrict_performance_levels_before_switch failed) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: chewi@gentoo.org
Created attachment 115023 --> https://bugs.freedesktop.org/attachment.cgi?id=115023&action=edit dmesg
I have a Radeon HD4670 on a Gentoo Linux system. 1080p playback was working fine under 3.17 but has since slowed to a crawl. I have done back to 3.17 to check that it still works despite numerous updates to userspace and it does. 3.18 flat out refuses to work, with vdpauinfo claiming that H.264 is not supported. I know that Radeon video acceleration was in a transition during this period so best to ignore that. Under 3.19.3 and 4.0-rc7, vdpauinfo reports that H.264 is supported but playback is very slow. How slow? Low quality 1080p is very jumpy. High quality 1080p (Blu-ray) barely moves at all. Probably something like 0.1fps. When attempting playback, though mplayer or VLC, the following error appears in dmesg.
[drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed
This led me to try booting with radeon.dpm=0. Under the high profile, low quality is smooth and high quality improves to just jumpy. Under the dynpm method, both are smooth.
I have two displays connected using Zaphod mode, both normally at 1080p. If I disconnect the second, playback is smooth. If I set the second to some low resolution like 720x480 but play 1080p video on the first, playback is smooth. I'm not sure whether this behaviour is a symptom or a cause.
I tried enabling DRI3 to see if that would help but no. I can't bisect the kernel because UVD acceleration is new. There has probably not been a commit so far where it did work under this setup. Here's some further info.
Card: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] Kernels: 3.19.3 and 4.0-rc7 Mesa: 10.5.2 xorg-server: 1.17.1 xf86-video-ati: 7.5.0 and 5921ba4ca705a0d919515626088f3948cc4848c1 Desktop: XFCE (no compositing)
This has similarities to bug #69120 but I believe that to be a different issue because it involves much older kernel versions and a lot has changed since then, plus it used to work for me until 3.18.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #1 from James Le Cuirot chewi@gentoo.org --- Created attachment 115024 --> https://bugs.freedesktop.org/attachment.cgi?id=115024&action=edit Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #2 from James Le Cuirot chewi@gentoo.org --- Forgot to mention that whatever DPM glitch is going on seems limited to VDPAU. I fired up Portal, which is fairly challenging for this card, and it ran just fine.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #3 from James Le Cuirot chewi@gentoo.org --- Created attachment 115025 --> https://bugs.freedesktop.org/attachment.cgi?id=115025&action=edit vdpauinfo
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #4 from Christian König deathsimple@vodafone.de --- (In reply to James Le Cuirot from comment #0)
This has similarities to bug #69120 but I believe that to be a different issue because it involves much older kernel versions and a lot has changed since then, plus it used to work for me until 3.18.
Yeah, that is indeed a completely different issue, so opening up a new bug report was the right thing to do.
[drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed
This led me to try booting with radeon.dpm=0. Under the high profile, low quality is smooth and high quality improves to just jumpy. Under the dynpm method, both are smooth.
I have two displays connected using Zaphod mode, both normally at 1080p. If I disconnect the second, playback is smooth. If I set the second to some low resolution like 720x480 but play 1080p video on the first, playback is smooth. I'm not sure whether this behaviour is a symptom or a cause.
Thanks for the detailed report, but unfortunately I can't help much and Alex need to take a look at this.
The issue is that the driver send a message to the SMU to raise the clocks for playback and with two connected monitors that fails for some reason.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #5 from James Le Cuirot chewi@gentoo.org --- Still a problem in 4.1-rc5 with Mesa 10.5.6.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #6 from James Le Cuirot chewi@gentoo.org --- I should also add that this isn't limited to Zaphod mode, despite that often being the case with these kinds of bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #7 from James Le Cuirot chewi@gentoo.org --- And still a problem in 4.2.0-rc1. Is there nothing I can do to move this along? It's really irritating. I have tried my best to fix it myself but to no avail.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
--- Comment #8 from Christian König deathsimple@vodafone.de --- (In reply to James Le Cuirot from comment #7)
And still a problem in 4.2.0-rc1. Is there nothing I can do to move this along? It's really irritating. I have tried my best to fix it myself but to no avail.
The only thing which came to my mind we haven't tried so far is if you are sure that it works with the 3.17 release (with UVD acceleration) and not 3.18 you could try to bisect the changes between the two.
But apart from that I unfortunately don't have any idea either.
https://bugs.freedesktop.org/show_bug.cgi?id=89987
James Le Cuirot chewi@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #9 from James Le Cuirot chewi@gentoo.org --- Sincere apologies for this but it looks like this is actually a bug in VLC. Several factors threw me off, namely that mplayer isn't playing ball either (don't know why yet), that I upgraded the kernel around the same time, that UVD was introduced in 3.18, and the error in dmesg, all of which made it look like a kernel problem.
Doesn't that mean it would have still been broken when going back to 3.17? Actually it kinda was but not nearly as badly so I guess I didn't notice when filing this bug. Under that kernel version, it looks as though it drops every other frame in a smooth manner. Under recent kernels, it barely moves at all. I started downgrading various userspace components like libvdpau, Mesa, and xf86-video-ati to see whether any of those made a difference but it wasn't until I downgraded VLC from 2.2 to 2.1 that the problem went away, both under 3.17 and 4.1. I also tried VLC git master under 4.1 and strangely it behaves like 2.2 does under 3.17, dropping every other frame. Very confusing.
I am now bisecting to track down the precise cause.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org