AMD Is Working On A New VA-API State Tracker For Gallium3D

[phoronix]

Phoronix: AMD Is Working On A New VA-API State Tracker For Gallium3D

Years ago there was a VA-API state tracker within Gallium3D for offering drivers support for the Video Acceleration API. That implementation, however, was dropped back in 2012 as it was largely unmaintained and the VDPAU state tracker proved to be more popular. Now, however, it seems AMD is working to introduce a new VA-API implementation for Gallium3D...

http://www.phoronix.com/vr.php?view=MTc5OTE

[Ericg]

Maybe its because VDPAU only does decode? Currently Radeon does VDPAU for decode, and OpenMAX for encode. VA-API supports encode. Maybe they want to transition to VA-API so they dont have to use two separate API's?

[zanny]

Openmax does decode as well, they could implement that fully, but they probably know that nobody is targeting openmax for decode - at the least, there is no gstreamer openmax the way there is gstreamer vaapi (there is, but it is less developed and stable, for example on Arch the vaapi plugins are in the main repos and omx is stuck in the AUR).

In the end, vdpau is Nvidia, vaapi is Intel, and if they were to all stop being babies they would all use Openmax, or at least standardize on one of the others. At least we have vaapi for vdpau and vice versa libraries. But it is perfectly understandable for the situation to be frustrating to AMD, who have no obvious answer.

[Guest]

I support Ericg 's viewpoint, that's probably the main reason. OpenMax isn't widely used AFAIK, and Intel already uses VAAPI (for both video decode and encode) which is used and supported by some widely used software like XBMC, GStreamer, VLC etc.

[dungeon]

Main reason for me is: things became so stable and so boring, so it is perfect time to broke something again

Because unified driver maybe, hmm.... OK wait, we will see what is planed in about ten days

[liam]

I support Ericg 's viewpoint, that's probably the main reason. OpenMax isn't widely used AFAIK, and Intel already uses VAAPI (for both video decode and encode) which is used and supported by some widely used software like XBMC, GStreamer, VLC etc.

My understanding is that openmax sees the majority of its use in the embedded space. However, I'd imagine that most software is using native solutions nowadays (corevideo, stagefright, etc).
I agree with ericg that supporting vaapi makes more sense than supporting two different state trackers. Vaapi is pretty complicated (though less than openmax, from a quick perusal of the interfaces), but it provides a nice, robust platform for all your accelerated media needs, and is already widely adopted.

[schmidtbag]

In the end, vdpau is Nvidia, vaapi is Intel, and if they were to all stop being babies they would all use Openmax, or at least standardize on one of the others. At least we have vaapi for vdpau and vice versa libraries. But it is perfectly understandable for the situation to be frustrating to AMD, who have no obvious answer.

vdpau was created by nvidia but the open source radeon drivers support it too, though I don't know what Catalyst uses. Based on my experience with the open source drivers, it works fine.

I don't know enough on the subject to know what the pros and cons are between the 3 major APIs, but I get the impression vdpau is more widely accepted.

[nanonyme]

As long as the API's aren't prone to changes, I don't see what's the problem with all of them being supported as G3D state trackers

[eternaleye]

There's also that VA-API supports Wayland, while VDPAU does not.

Sure, OpenMAX can work on Wayland too, but as noted before... pretty much nobody uses OpenMAX for decode if they have other options.

[fritsch]

There's also that VA-API supports Wayland, while VDPAU does not.

Sure, OpenMAX can work on Wayland too, but as noted before... pretty much nobody uses OpenMAX for decode if they have other options.

I don't really have much fear as Christian K?nig is involved. What he has done to VDPAU can happen again with VAAPI.

When I look at the transfer functions, it even seems we can now have the surfaces back without RGB conversion. Let's see if VPP gets also implemented. I will remove the "Intel only" VAAPI patch from xbmc now, so that new adapters will have the chance to get the implemented API stable.