AMD Open Sources Their Linux Video API 64
An anonymous reader writes "AMD has open sourced X-Video Bitstream Acceleration, their API by which they expose the Universal Video Decoder 2 GPU under Linux."
They may be a little late with this move, and not everything you could wish is now open source, but it's better than nothing.
VDPAU is already an open standard (Score:4, Informative)
Nvidia's VDPAU is already an open standard that other video drivers can implement in Linux for video acceleration, so I'm not sure what this buys us. VDPAU as implemented by Nvidia is also about the only video acceleration standard that isn't totally broken and that can accelerate videos beyond MPEG-2 as well.
Not open sourced (Score:5, Informative)
This headline is widely misleading. They've now documented their equivalent of nVidia's VDPAU blob, but it's only available when you run the closed source Catalyst driver. TFA says so quite clearly.
Before anyone starts wondering, this won't do much good for those hoping to see AMD's UVD2 engine supported by the open-source Radeon graphics drivers.
Re:Yet Another API (Score:5, Informative)
I figure eventually someone will write the right wrappers so apps only need to deal with one API.
VA-API is the wrapper that you speak of. It has multiple backends [freedesktop.org], including backends for Intel cards, VDPAU and XvBA.
Re:Okaaaaaay... (Score:5, Informative)
Well, there's the proprietary drivers which AMD/ATI does what they want with, dropping support for old chips, etc, and there's the native xorg/kernel/mesa/drm and now KMS drivers, which are open. The open drivers support at least as far back as Mach64 and ATIRage, and while I never used those specific drivers, after I realized what a bad idea the servantware drivers were based on the nVidia card I had when I first switched to Linux, I've stuck with the Radeon native drivers. In fact, I was still using a Radeon 9200 (r2xx chip series) until about 14 months ago, when I upgraded to a Radeon hd4650 (r7xx chip series), so I /know/ how well the freedomware support lasts. =:^)
And why would the free/libre and open source (FLOSS) folks build a shim for the servantware driver? The kernel specifically does NOT maintain an internal kernel stable ABI (the external/userland interface is a different story, they go to great lengths to maintain that stable), and if anyone's building proprietary drivers on it, it's up to them to maintain their shim between the open and closed stuff as necessary. Rather, the FLOSS folks maintain their native FLOSS drivers.
And while for the leading edge it it's arguable that the servantware drivers are better performing and for some months may in fact be the only choice, by the time ATI's dropping driver support, the freedomware drivers tend to be quite stable and mature (altho there was a gap in the r3xx-r5xx time frame after ATI quit cooperating, before AMD bought them and started cooperating with the FLOSS folks again, part of the reason I stuck with the r2xx series so long, but those series are well covered now).
So this /is/ good news, as it should allow the freedomware drivers to better support hardware video accel, as they merge the new information into the freedomware drivers.