AMD Lands AV1 Decode For Radeon RX 6000 Series In Mesa

[OneTimeShot]

Interesting. Does this mean that the PS5 is using OpenMAX? I think it's the Android API too...

It's a shame that Khronos doesn't merge all of their APIs into one set. It would be good to have Compute/Audio/Video/2d/3d in one known defined block. Still I'm sure that VA-API and others can be glued on to this.

[shmerl]

AV1 support was only added to VA-API a few weeks ago. I can be extended to VA-API now, but it didn't exist months ago when we started working on this.

Thanks, I hope VAAPI support will catch up. Firefox is using VAAPI for hardware video acceleration.

[agd5f]

It's a shame that Khronos doesn't merge all of their APIs into one set. It would be good to have Compute/Audio/Video/2d/3d in one known defined block. Still I'm sure that VA-API and others can be glued on to this.

VA-API is an Intel controlled API. It's not part of Khronos. Ideally OpenMAX would have taken off on Linux like OpenGL did, but that ship has sailed I guess.

[piotrj3]

Any kind of support for AV1 is welcome, but it's a bit ironic that the least demanding part (decode) gets hardware acceleration first. Hopefully encoding arrives in next generation.

That is absolutly normal because AV1 is really complex codec that is NOT meant to be encoded by normal users. AV1 is meant to be more for cases of sort you encode once, 1 milion users decode it afterwards. Also it is worth noting that hardware accelation encoding is always significantly less efficient, h264/h265 hardware encoded has by far less efficiency then software encoding on x264/x265 decent preset, only notable exception i think is NVENC for h264 that since turing can somewhat compete with x264.

Edit: when i tried diffrent AV1 codecs in Hybrid (by Selur) only SVT-AV1 seems somewhat reasonable in terms of encoding speed, meanwhile AOM reference codec takes ages to encode even very short video.

[piotrj3]

Interesting. Does this mean that the PS5 is using OpenMAX? I think it's the Android API too...

It's a shame that Khronos doesn't merge all of their APIs into one set. It would be good to have Compute/Audio/Video/2d/3d in one known defined block. Still I'm sure that VA-API and others can be glued on to this.

Well Vulkan for compute/graphics starts to become something of this sort, but true i wish hardware encoding/decoding video on GPU could be managed by Khnosos. That being said, audio probably shouldn't be managed by Khnosos since it has to do very little with graphics/gpus.

[nazar-pc]

That is absolutly normal because AV1 is really complex codec that is NOT meant to be encoded by normal users. AV1 is meant to be more for cases of sort you encode once, 1 milion users decode it afterwards. Also it is worth noting that hardware accelation encoding is always significantly less efficient, h264/h265 hardware encoded has by far less efficiency then software encoding on x264/x265 decent preset, only notable exception i think is NVENC for h264 that since turing can somewhat compete with x264.

Well, this is not 100% true, since AV1 support in WebRTC will appear if not this year then next year for sure and it will make a lot of sense to accelerate that if possible to get higher quality of the video with the same bit rate as H264/VP8 that are mostly used today (VP9 is much less popular it seems).

[OneTimeShot]

Well Vulkan for compute/graphics starts to become something of this sort, but true i wish hardware encoding/decoding video on GPU could be managed by Khnosos. That being said, audio probably shouldn't be managed by Khnosos since it has to do very little with graphics/gpus.

Actually Khronos have quite a few APIs if you look through their website. OpenMAX for video, OpenAL for audio, OpenML for capture, OpenXR for VR/AR, OpenVX for machine learning. All of these fall under "things a GPU card can do". It's beyond me why they don't create a coherent platform with all the bits they have...

[intelfx]

AV1 support was only added to VA-API a few weeks ago. I can be extended to VA-API now, but it didn't exist months ago when we started working on this.

That's exactly what I asked. VA-API is just an abstraction. Why not work with the VA-API upstream to add AV1 support to VA-API itself?

[piotrj3]

Actually Khronos have quite a few APIs if you look through their website. OpenMAX for video, OpenAL for audio, OpenML for capture, OpenXR for VR/AR, OpenVX for machine learning. All of these fall under "things a GPU card can do". It's beyond me why they don't create a coherent platform with all the bits they have...

OpenMAX sure but it is outdated and haven't seen much work I am actually suprised AMD went for OpenMAX here.

OpenAL is more some even older creation and i think doesn't belong to Khnosos but to Creative.

OpenML is for machine learning, that Vulkan does really well.

OpenXR fine it is there is modern and works mostly, just VR didn't became that popular.

OpenVX is for image processing/recognization etc.

Some of those works, some of those suffer hard. Problem in video industry is that as agd5f said, VAAPI is intel managed and Intel dictates everything, VPDAU is Nvidia managed and nvidia mostly dictates everything, NVDEC is propertiary, OpenMAX is old and has no adoption. What would really call for some VulkanVideo or something where NVidia, Intel, AMD, Qualcom and few others can make more standard specification that could be truly multiplatform. I would even say that Vulkan's aproach for "optional" extensions would really work well for video

[MadeUpName]

Why is that ironic? The common use case is media playback, not creation.

If you have this class of hardware you aren't going to have any issues decoding AV1 in software. Once you get to the low end cards next year that people will mate up with lower end CPUs then you might have a point. But it has been so long since any one made a truly bad CPU (Bulldozer) I doubt even that will be the case. Now if you were running some thing crappy like an M1 powered devise you would have a case for HW accelerated decode but then you couldn't run these cards.