Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[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.leichtzumer...@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
> 
>
> 

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Will DeBerry]

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

Yes 100% confident. We configured VLC to use VA-API decoding with software
based deinterlacing. The VA-API implementation is using the VDPAU backend
shim as shown in the vainfo output: *vainfo: Driver version:
Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4.*

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


We know that software decoding on Ubuntu 16.04 does not produce something
that is watchable in quality. There are frame drops and
noticeable choppiness to the playback. Also since it was brought up
previously, using a different player doesn't result in any different
outcomes. This is specifically the case with mpeg4 playback. No software
based decoding solutions have been suitable here, but it is to be known
that mpeg4 has not shown itself to create the VDPAU GPU lockup. Continuing
to use VDPAU for mpeg4 is fine in this case.

We are totally open to changing the video decoding pipelines to avoid the
VDPAU GPU bug altogether but nothing outside of VDPAU produces the quality
that we could ship and put in front of people. We have the hardware and
available known video snippets that cause the VDPAU GPU lock up if someone
wants to dig in and see what's going on or have a stab at a good work
around.

On Mon, Dec 2, 2019 at 3:11 PM Christian König 
wrote:

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

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[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 
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 

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Christian König]

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 
mailto:christian.koe...@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 

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Alan Swanson]

On Mon, 2019-12-02 at 15:16 +0100, Christian König 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.

Guessing that it'll be the MPEG2 corruption under VA-API which was
fixed by;

st/va: reverse qt matrix back to its original order
https://cgit.freedesktop.org/mesa/mesa/commit/?id=d507bcdcf26b417dea201090165af651253b6b11

-- 
Alan.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Christian König]

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

Re: [Mesa-dev] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup on Radeon HD6320

[Christian König]

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 



___



Join us for GetConnected 2020! REGISTER TODAY 






___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev