[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 20:11:44 UTC 2019


>     Well how was the stack configured then? Pure software playback?
>
>
> In 19.10, yes the whole stack was told to use software playback and 
> decoding.

I would investigate this way. 1920x1080 is not a high resolution and 
should decode with the CPU just fine.

> Our older Gentoo based setup with the old software stack worked fine

The hardware generally does not support some interlaced frame/field 
features rarely used in todays MPEG2 streams and a software fallback 
isn't easily doable with VA-API/VDPAU and so was never implemented.

Are you sure that the Gentoo based setup isn't software decoding based?

Regards,
Christian.

Am 02.12.19 um 16:02 schrieb Will DeBerry:
>
>     What regression was that? The difference between VDPAU and VA-API
>     is only marginal for codec support.
>
>
> The regression revolved around deinterlacing the content. If we had to 
> deinterlace 1080i for instance, the playback was very choppy and 
> dropped frames.
>
>     Well how was the stack configured then? Pure software playback?
>
>
> In 19.10, yes the whole stack was told to use software playback and 
> decoding.
>
>     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.
>
>
> That's part of the problem. We do have high resolution (1920x1080) 
> mpeg2 at the places we are installed. We have no control over what 
> content is available but have to support it.
>
> Our older Gentoo based setup with the old software stack worked fine 
> but the Ubuntu 16.04 stack does not playback the same content without 
> having to switch to VDPAU and thus introduce the GPU thread lockup 
> issue. Ubuntu 18.04 looks to have the same VDPAU GPU lockup issue as 
> well and cannot use software playback/decoding successfully.
>
> On Mon, Dec 2, 2019 at 9:16 AM Christian König 
> <christian.koenig at amd.com <mailto:christian.koenig at amd.com>> wrote:
>
>>     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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668694432&sdata=MxhJUHvrqs528rPFb5494Hupmu4p6J5P26%2BLq96LDqw%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668694432&sdata=8lEPSbkyareM6vEtG14KWfBFONCiBb%2BtZe%2FD03XboJA%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668704425&sdata=gTvtRkihFmxoYRRSpHRp57b6dhCg7CppyrflhQkHLuY%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668704425&sdata=mXY1rdgqCAnHffUSb%2FN65x1%2B0onKhxEmV%2BEdqLWH1iI%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668714420&sdata=PqSZ%2FP%2BsriKMghh6IwJ4B8PIo2L23wK0RQUUqzWHz3A%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668714420&sdata=1jejG5JV%2Fiz58wgS%2FNWqkSrThgMEoSpTo9%2B3iRQrwRk%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%7Ccf89524d9f8e45b523bf08d77738af7e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637108957668714420&sdata=PqSZ%2FP%2BsriKMghh6IwJ4B8PIo2L23wK0RQUUqzWHz3A%3D&reserved=0>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191202/c19229e0/attachment-0001.html>


More information about the mesa-dev mailing list