Discussion:
[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
(too old to reply)
b***@freedesktop.org
2015-04-11 22:40:17 UTC
Permalink
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-***@lists.freedesktop.org
Reporter: ***@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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-04-11 22:44:25 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #2 from James Le Cuirot <***@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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-04-11 22:46:13 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #3 from James Le Cuirot <***@gentoo.org> ---
Created attachment 115025
--> https://bugs.freedesktop.org/attachment.cgi?id=115025&action=edit
vdpauinfo
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-04-11 22:40:45 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #1 from James Le Cuirot <***@gentoo.org> ---
Created attachment 115024
--> https://bugs.freedesktop.org/attachment.cgi?id=115024&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-04-13 08:10:04 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #4 from Christian König <***@vodafone.de> ---
(In reply to James Le Cuirot from comment #0)
Post by b***@freedesktop.org
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.
Post by b***@freedesktop.org
[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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-05-26 21:19:46 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #5 from James Le Cuirot <***@gentoo.org> ---
Still a problem in 4.1-rc5 with Mesa 10.5.6.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-05-31 08:13:08 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #6 from James Le Cuirot <***@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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-07-09 22:21:48 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #7 from James Le Cuirot <***@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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-07-10 10:02:11 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #8 from Christian König <***@vodafone.de> ---
(In reply to James Le Cuirot from comment #7)
Post by b***@freedesktop.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.
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.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freedesktop.org
2015-08-09 22:25:34 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=89987

James Le Cuirot <***@gentoo.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |NOTOURBUG

--- Comment #9 from James Le Cuirot <***@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.
--
You are receiving this mail because:
You are the assignee for the bug.
Loading...