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.koe...@amd.com <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 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
<mailto: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
<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@lists.freedesktop.org <mailto:mesa-dev@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>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
