Bug 90360

Summary: [RV710/M92] GPU lockup caused by shader based MPEG2 decoding
Product: DRI Reporter: Mohammad AlSaleh <CE.Mohammad.AlSaleh>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output none

Description Mohammad AlSaleh 2015-05-07 10:08:16 UTC

    
Comment 1 Mohammad AlSaleh 2015-05-07 10:21:10 UTC
Hello.

Card:Mobility Radeon HD 4570

I set those at start-up:
echo performance > /sys/class/drm/card0/device/power_dpm_state
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

When trying to use VDPAU/UVD (e.g. with ffmpeg). The GPU soft-locks. X can be killed remotely. But the GPU is not reset properly. GL and VDPAU don't work after I start X again.

This bug was net present in 3.18.2.

dmesg output attached.
Comment 2 Mohammad AlSaleh 2015-05-07 10:22:17 UTC
Created attachment 115621 [details]
dmesg output
Comment 3 Mohammad AlSaleh 2015-05-07 11:17:13 UTC
Looking closer at what's going on. This could be codec related.

I just noticed that the bug is triggered with MPEG2(the particular file is 1080i) but not with H264.

And the bug goes back to at least 3.18.6.
Comment 4 Christian König 2015-05-07 12:33:37 UTC
The UVD block on the RV710 doesn't support MPEG2 in hardware. Because of that we fall back to shader based MPEG2 decoding and that seems to crash the GPU.

IIRC this used to work on RV710, but I'm not 100% sure.

Best solution I can see is to configure your player to not try to use hw acceleration for MPEG2.
Comment 5 Mohammad AlSaleh 2015-05-07 13:40:37 UTC
Yes.

I already have my player configured to only use VDPAU with H264(by default).

However, playback is not the only use-case of hardware acceleration. I actually stumbled upon this bug when a script called "ffmpeg" with "-hwaccel vdpau".

So, this bug can be triggered in scenarios that are not user-visible. Which makes it more severe IMHO.

May I suggest disabling hardware MPEG2 decoding completely for the time being?
Comment 6 no.spam.to.me 2015-07-08 06:56:35 UTC
(In reply to Christian König from comment #4)
> Because of
> that we fall back to shader based MPEG2 decoding and that seems to crash the
> GPU.

Who is responsible for shader based MPEG2 decoding?

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.