Will AMD's XvBA Beat Out NVIDIA's VDPAU?

[gbeauche]

Intel Poulsbo only supports VA-API, but it seems Intel bought that driver as closed source only it seems and I don't think there will be many updates for it.

I don't think Intel bought that driver as closed source only since they did write it, and even twice (i.e. two different drivers...). There are actually many updates to it, one is dri2 support, another one is video encode acceleration for the Moorestown platform chips, etc. Please check recent VA API spec 0.30 for "news" if you don't have the actual drivers, that's very meaningful as to what is happening. ;-)

http://freedesktop.org/wiki/Software/vaapi

[gbeauche]

Intel Poulsbo only supports VA-API, but it seems Intel bought that driver as closed source only it seems and I don't think there will be many updates for it.

I don't think Intel bought that driver as closed source only since they did write it, and even twice (i.e. two different drivers...). There are actually many updates to it, one is dri2 support, another one is video encode acceleration for the Moorestown platform chips, etc. Please check recent VA API spec 0.30 for "news" if you don't have the actual drivers, that's very meaningful as to what is happening. ;-)

http://freedesktop.org/wiki/Software/vaapi

[grantek]

I haven't been around here in a while, but while we're speculating idly, does anyone have pre-release access to Catalyst 9.10rc1 or whatever to see if it's packaged any differently?

[bridgman]

Our development process is slightly pipelined (development continues on main while release branches are frozen for QA and last-minute fixes) but the mainline doesn't run *that* far ahead

[Yfrwlf]

I am completely okay with XvMC, VDPAU, VAAPI, XvBA, and/or any other video decoding frontend in Gallium. Completely. I'm just not doing it right now.

Their point was though that since they are mere APIs, standardizing on one particular one would be nice instead of each manufacturer backing a particular one. Fragmentation like that defeats the best purpose of having an API which is to implement a common language for everyone to use.

Not directed at you, but at the industries and communities as a whole. It would make everyone's life easier to have one or two APIs gain focus.

[deanjo]

Their point was though that since they are mere APIs, standardizing on one particular one would be nice instead of each manufacturer backing a particular one. Fragmentation like that defeats the best purpose of having an API which is to implement a common language for everyone to use.

Not directed at you, but at the industries and communities as a whole. It would make everyone's life easier to have one or two APIs gain focus.

Glad some one gets it.

[Jorophose]

WTH? VDPAU is free to implement in any driver. Free or closed. It's up to the driver guru's to add support for the API. Nvidia's and Via's drivers have support for it, intel has also considered supporting it and nvidia welcomes all who wish to use the API.



Guess you didn't read the ION reviews, they too are powered by atoms.

Felt the need to reply to this, nowhere does VIA use VDPAU, at least I can't find anything that confirms it.

VIA's chipsets used to use their own xine, now the S3 Chrome discrete cards (NOT VIA at all) use VA-API, and the current VIA Chrome chipsets don't seem to accelerate mpeg4/h.264/vc-1 video under linux. I don't know if they've added VDPAU support.

This is all getting very silly. Why do we have to have three APIs here? Is it because nobody wants to take somebody else's shit?

Why can't we use VA-API as a unified wrapper, and have it work with VDPAU and XvBA? Is that too much wrapping/layering? Maybe something in Gallium instead that just wraps to whatever's available, and if nothing is, then just move on to a shader solution.

[greg]

VA-API shouldn't be used as wrapper for several reasons.

a) It doesn't implement certain features of other APIs, e.g. VDPAU. There is no useful deinterlacing or postprocessing support in VA-API, for example. (And hardware deinterlacing is one of the most interesting features of VDPAU besides decoding). Postprocessing in VA-API basically looks like a stub. Nor does it support blending surfaces together in a way as flexible as with VDPAU.
OTOH it supports video encoding (not really useful yet, no working implementations and I don't see anything happening there either) and H.263/MPEG4 ASP (but that's not really an argument; codecs besides H.264, MPEG2 and VC-1 are not relevant).

b) Writing wrappers is work that is not necessary if we manage to agree on one standard.

c) Like I already said earlier, VA-API isn't well-documented nor is it in widespread usage. VDPAU on the other hand is already supported in a lot of programs and well-documented.
If the VA-API developers want me to use their API, they better document it beyond some headers with comments...

[deanjo]

Felt the need to reply to this, nowhere does VIA use VDPAU, at least I can't find anything that confirms it..

S3 sold off it's graphics core division to VIA some time ago (~2000). While the brand S3 exists the graphics core is done by VIA.

[he_the_great]

No, it doesn't. Supported means supported. And this can't be used, and the drivers can't technically use it - at least for all we know. If you have proof that it can be, please share.

You are correct, but what was said was that the driver supported XvBA, not that ATi supported the XvBA driver. As to weather XvBA is actually usable with the driver I don't know, but if it is then the driver supports it no matter what ATi/AMD says.