|Summary:||UVD accelerated decoding causes hangs (ARUBA - HD 7540D)|
|Component:||Drivers/Gallium/r600||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
|Attachments:||relevant dmesg output|
Description adam 2013-06-10 14:11:12 UTC
Created attachment 80626 [details] relevant dmesg output New UVD VDPAU decoding of VC-1 and MPEG-2 causes some kind of corruption and ultimately hang of driver and whole system on the next try (cursor can be moving for some time, even SysRq can work a few seconds after X totally hangs but then only power off works). Few notes (using mplayer): ffmpeg12vdpau: MPEG1 causes no harm, only decoding is really bad (software decoding works) MPEG2 seems to cause really bad corruption ffvc1vdpau: VC-1 seems to cause problems (like attached dmesg) but not hangs. There have been decoding artifacts too, but it is not the rule. divx and h264 seems to work flawless, unless previous corruption happened. Hardware is ARUBA - A6-5400K Black Edition APU (Radeon HD 7540D). Since this particular hardware seems to be problematic (#65254 #60389) it might be unique to this APU. Test files: VC1 http://samples.mplayerhq.hu/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv MPEG2 http://samples.mplayerhq.hu/MPEG2/vid_0x80.ts MPEG1 http://samples.mplayerhq.hu/MPEG1/
Comment 1 Christian König 2013-09-27 18:50:32 UTC
*** Bug 69889 has been marked as a duplicate of this bug. ***
Comment 2 Pierre Ossman 2013-09-27 19:23:16 UTC
(In reply to bug 65611 comment #1) > Well known problem, only VC-1 advanced profile (as found on Blueray disks) > is supported by the hardware. If that is the case, wouldn't it be an obvious first fix to remove simple and main from the driver's list of supported codecs?
Comment 3 Pierre Ossman 2013-09-27 21:24:25 UTC
I tried this patch: diff -up ./src/gallium/drivers/radeon/radeon_uvd.c.vc1 ./src/gallium/drivers/radeon/radeon_uvd.c --- ./src/gallium/drivers/radeon/radeon_uvd.c.vc1 2013-09-27 23:10:44.292867514 +0200 +++ ./src/gallium/drivers/radeon/radeon_uvd.c 2013-09-27 23:14:45.384398128 +0200 @@ -1094,8 +1094,12 @@ int ruvd_get_video_param(struct pipe_scr case PIPE_VIDEO_CODEC_MPEG12: case PIPE_VIDEO_CODEC_MPEG4: case PIPE_VIDEO_CODEC_MPEG4_AVC: - case PIPE_VIDEO_CODEC_VC1: return true; + case PIPE_VIDEO_CODEC_VC1: + /* Only advanced is supported */ + if (profile == PIPE_VIDEO_PROFILE_VC1_ADVANCED) + return true; + /* fall through... */ default: return false; } Yet my WMV3 file is still going through VDPAU. So either my file is advanced profile and that is broken, or xbmc not fully respecting the list?
Comment 4 Pierre Ossman 2013-09-28 15:49:51 UTC
(In reply to comment #3) > > Yet my WMV3 file is still going through VDPAU. So either my file is advanced > profile and that is broken, or xbmc not fully respecting the list? Turned out that the UVD symbols get duplicated both into the VDPAU driver and the DRI driver. So you have to replace both to get your changes to go through. Still didn't work properly though as XBMC seems to not bother asking the driver what it can do and just blindly assumes that every format is available...
Comment 5 Christian König 2013-10-01 18:34:30 UTC
(In reply to comment #4) > Still didn't work properly though as XBMC seems to not bother asking the > driver what it can do and just blindly assumes that every format is > available... Which is pretty much the reason why I haven't fixed it so far, you also need to fix the applications as well. MPEG1 isn't supported either, but pretty much every application is ignoring the decoder capabilities. Anyway if you want to write a patch to start fixing those issues feel free to do so, any help is always welcome.
Comment 6 GitLab Migration User 2019-09-18 19:03:16 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/442.