Bug 89987 - Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
Summary: Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
Status: RESOLVED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-11 22:40 UTC by James Le Cuirot
Modified: 2015-08-09 22:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg (103.50 KB, text/plain)
2015-04-11 22:40 UTC, James Le Cuirot
no flags Details
Xorg.0.log (47.05 KB, text/plain)
2015-04-11 22:40 UTC, James Le Cuirot
no flags Details
vdpauinfo (3.60 KB, text/plain)
2015-04-11 22:46 UTC, James Le Cuirot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot 2015-04-11 22:40:17 UTC
Created attachment 115023 [details]
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.
Comment 1 James Le Cuirot 2015-04-11 22:40:45 UTC
Created attachment 115024 [details]
Xorg.0.log
Comment 2 James Le Cuirot 2015-04-11 22:44:25 UTC
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.
Comment 3 James Le Cuirot 2015-04-11 22:46:13 UTC
Created attachment 115025 [details]
vdpauinfo
Comment 4 Christian König 2015-04-13 08:10:04 UTC
(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.
Comment 5 James Le Cuirot 2015-05-26 21:19:46 UTC
Still a problem in 4.1-rc5 with Mesa 10.5.6.
Comment 6 James Le Cuirot 2015-05-31 08:13:08 UTC
I should also add that this isn't limited to Zaphod mode, despite that often being the case with these kinds of bugs.
Comment 7 James Le Cuirot 2015-07-09 22:21:48 UTC
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.
Comment 8 Christian König 2015-07-10 10:02:11 UTC
(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.
Comment 9 James Le Cuirot 2015-08-09 22:25:34 UTC
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.


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.