[Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320
Christian König
christian.koenig at amd.com
Mon Dec 2 14:16:00 UTC 2019
> The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw
> a major regression with mpeg2 playback using va-api.
What regression was that? The difference between VDPAU and VA-API is
only marginal for codec support.
> During our testing we put Ubuntu 19.10 on one of these boxes and
> noticed that full software acceleration has improved to the point that
> VA-API nor VDPAU was required for VLC to render the mpeg2 and mpeg4
> streams correctly.
Well how was the stack configured then? Pure software playback?
As long as you don't do any high resolution H264 decoding the CPU in
that package should be capable of decoding both MPEG2 and MPEG4 with
software decode.
In general I would also try with mpv instead of vlc to rule out player
issues.
Regards,
Christian.
Am 02.12.19 um 15:06 schrieb Will DeBerry:
>
> well that's the very first APU generation and unfortunately nobody
> is working on that old hardware any more.
>
>
> Agreed, definitely old hardware. Unfortunately we have 10,000 of these
> things in production and they have been playing hardware accelerated
> mpeg2 fine until we upgraded to Ubuntu 16.04 and the new mesa package.
> Now to be specific, our previous version of linux on these systems we
> were using an older software stack and video acceleration pipeline but
> it worked perfectly, so we know the hardware is capable.
>
> *Old Software Stack:*
>
> * vlc 2.1.5
> * mesa 11.0.6
> * va-api hardware acceleration
> * libva info: VA-API version 0.38.1
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/va/drivers/r600_drv_video.so
> libva info: Found init function __vaDriverInit_0_35
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.38 (libva 1.6.2)
> vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for
> VA-API - 0.7.4
> vainfo: Supported profile and entrypoints
> VAProfileMPEG2Simple : VAEntrypointVLD
> VAProfileMPEG2Main : VAEntrypointVLD
> VAProfileMPEG4Simple : VAEntrypointVLD
> VAProfileMPEG4AdvancedSimple : VAEntrypointVLD
> VAProfileH264Baseline : VAEntrypointVLD
> VAProfileH264Main : VAEntrypointVLD
> VAProfileH264High : VAEntrypointVLD
> VAProfileVC1Simple : VAEntrypointVLD
> VAProfileVC1Main : VAEntrypointVLD
> VAProfileVC1Advanced : VAEntrypointVLD
>
> *New Software Stack:*
>
> * vlc 2.2.2
> * mesa 18.2.8-2~bpo9+1
> * vdpau hardware acceleration
>
> The reason we had to switch to VDPAU with Ubuntu 16.04 is that we saw
> a major regression with mpeg2 playback using va-api. It was capable of
> playing back mpeg4 without any issues. Now that we have switched to
> VDPAU however, we are seeing this GPU thread lockup bug and thus
> causing X and other GUI related programs to crash and requiring a
> reboot to recover.
>
> Changing out hardware for the next best thing is not an option at our
> scale and we know that the hardware is capable due to past
> experiences. We are just in need of assistance with someone or some
> party that knows that stack a lot more than us to help dig to the core
> issue of the lockup or help us get VA-API working for mpeg2 in 16.04.
>
> So the best approach is probably to not use hardware acceleration
> for MPEG2 clips in general.
>
>
> With software decoding, the performance doesn't produce something that
> is watchable. One interesting tidbit to note. During our testing we
> put Ubuntu 19.10 on one of these boxes and noticed that full software
> acceleration has improved to the point that VA-API nor VDPAU was
> required for VLC to render the mpeg2 and mpeg4 streams correctly. Is
> this something that could potentially be backported to Ubuntu 16.04? I
> know this is a much bigger task that the one sentence ask alludes to,
> but figured I'd ask anyway.
>
> We are more than welcome to work together on this, especially since
> the hardware is older and probably hard to find. Just needing to find
> a solution so we can move forward on upgrading the software and on
> these older hardware.
>
> On Thu, Nov 28, 2019 at 7:15 AM Christian König
> <ckoenig.leichtzumerken at gmail.com
> <mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
>
> Hi Will,
>
> well that's the very first APU generation and unfortunately nobody
> is working on that old hardware any more.
>
> MPEG2 is known to not be fully supported by that chipset in
> general. So the best approach is probably to not use hardware
> acceleration for MPEG2 clips in general.
>
> Regards,
> Christian.
>
> Am 27.11.19 um 18:35 schrieb Will DeBerry:
>> Hi all,
>>
>> I am reaching out hoping to get some assistance with resolving a
>> bug/crash that we see with the GPU when using VDPAU hardware
>> acceleration on Ubuntu 16.04. This is specific to the r600
>> drivers interacting with VDPAU when trying to playback certain
>> mpeg2 content.
>>
>> *GPU in question per lscpi: *
>> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc.
>> [AMD/ATI] Wrestler [Radeon HD 6320]
>>
>> We are highly invested in this GPU and would love to get this
>> addressed as soon as possible and are also willing to
>> sponsor this work if needed.
>>
>> *Steps to Recreate:*
>>
>> 1. Launch VLC with VDPAU hardware acceleration and deinterlacing
>> enabled
>> 2. Play the attached piece of known bad content
>> 3. Wait for GPU lockup
>>
>> Per dmesg, the GPU thread gets locked up within the kernel and
>> thus breaks all GUI related activities until the PC is rebooted.
>>
>> *Mesa Version Tested:*
>> 18.0.5-0ubuntu0~16.04.1
>> 18.2.8-2~bpo9+1
>>
>> Let me know if you have any questions or are interested in
>> discussing this further.
>>
>> Thanks,
>>
>> --
>>
>> *Will DeBerry*
>>
>> Manager, Client Devices
>>
>> GetWellNetwork
>>
>> o: 240.482.4237 | m: 813.330.0121 | getwellnetwork.com
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.getwellnetwork.com%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C36f9952a3d504940e82c08d77730d203%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108923906349531&sdata=iS6WwpRpq4rCFVu8mpKuohVVILL%2Biuv7feM66Pmsgo4%3D&reserved=0>
>>
>> _______________________________________________________
>>
>>
>>
>> Join us for GetConnected 2020! REGISTER TODAY
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.getconnected2020.com%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C36f9952a3d504940e82c08d77730d203%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108923906359486&sdata=%2B3e3AgeJMIumIheea5TdTixV4EMNZEoCSAzM5lj33ng%3D&reserved=0>
>>
>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Cchristian.koenig%40amd.com%7C36f9952a3d504940e82c08d77730d203%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108923906359486&sdata=bTEUS8%2FnzkCA7vPyiabYzkjBaGfdK24CDzdFWSrLxOA%3D&reserved=0>
>
>
>
> --
>
> *Will DeBerry*
>
> Manager, Client Devices
>
> GetWellNetwork
>
> o: 240.482.4237 | m: 813.330.0121 | getwellnetwork.com
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.getwellnetwork.com%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C36f9952a3d504940e82c08d77730d203%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108923906369447&sdata=%2BRvmP3vJ4yhskJfQEe1fxXrl9PtiztAuOGhhBL3jNY4%3D&reserved=0>
>
> _______________________________________________________
>
>
>
> Join us for GetConnected 2020! REGISTER TODAY
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.getconnected2020.com%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C36f9952a3d504940e82c08d77730d203%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108923906369447&sdata=MhjxxW1ToOH%2Fuxb%2FbVOxNz2omDLWShFcjwCPV7yeR9g%3D&reserved=0>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191202/7c29670a/attachment-0001.html>
More information about the mesa-dev
mailing list