Bug 89987

Created attachment 115024 [details]
Xorg.0.log

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.

Created attachment 115025 [details]
vdpauinfo

(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.

Still a problem in 4.1-rc5 with Mesa 10.5.6.

I should also add that this isn't limited to Zaphod mode, despite that often being the case with these kinds of bugs.

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.

(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.

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.