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

[Nille]

If I'm not mistaken, the extension has been present in the driver for a while now.

But not Announced by AMD/ATI.

I think they got some money from ATI/AMD ....
They used a totally outdated graphic card versus a rather new one.
According to the NVIDIA documentation (at http://us.download.nvidia.com/XFree8...ppendix-h.html ), VC-1 support on this card is only partial, while most new cards (even cheap ones) has total support.
If the card has total support in VC1, I guess results will be exactly the same as H264: VDPAU will totally beat XvBA

The fanboy has spoken.

[Melcar]

Supported means it can be used, and the driver can technically use it.

[deanjo]

1. XvBA isn't vaporware, because it hasn't even been announced yet. Vaporware requires something to be hyped up first, and AMD hasn't said a word about it yet. And no, it won't be available for the open source drivers, just like Nvidia won't allow VDPAU to be used by open source drivers either..

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.

3. The benchmarks linked to are pretty useless. The systems the 3 cards are running on are completely different, and you can't compare any of the results between them beyond a basic 'yes, it seems to work pretty well' check that all 3 easily passed. If anything, Intel's VAAPI support seemed the most impressive of the 3, because it was running on an Atom CPU.

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

[bridgman]

We did apparently acknowledge its existence once (a marketing guy in Europe IIRC) but for use in embedded systems only.

[MostAwesomeDude]

This thread makes me a sad panda.

XvBA will not be pulled from drivers; there are big-name buyers that use it. However, there are no public headers nor any kind of specification that states its X protocol implementation.

It's discrete, not discreet. You make me want to give kittens to nVidia every time you misspell it.

Out of VA-API, VDPAU, and XvBA, at least three of us (ymanton, marcheu, and I) agree that VDPAU will be the least painful to implement. Haven't talked with anybody else, mostly because at this point very few of the Gallium3D/Tungsten devs actually care about video, and they've got other things to work on anyway.

Supported means it can be used, and the driver can technically use it.

No, it can't. It's only there because they don't build two different versions of the driver, apparently; if they did, then XvBA support would just be compiled out of the publicly available driver.

[mukiex]

Reactions like these are why people keep this sort of information to themselves. In fact, I was really clear when I sent Phoronix the link that these benchmarks were never designed for comparing card A to card B.

What they ARE good at is revealing two exciting pieces of info:

1. The drop in CPU utilization across the board is magnificent for modern GPU's, even on Intel's side with the GMA 500 (sadly, known as "the one with the crappy closed driver").

2. The performance impact of putting XVBA or VDPAU on top of VA-API doesn't seem significant, meaning VA-API could end up a real winner, given that, assuming we get Ati and S3 issues worked out by year's end, we'll have an API for vid accel that supports chips from four major vendors. That's quite impressive. It'll make for an absurd XBMC LiveCD if they ever add support for it.

All things considered, however, I wonder if we're better off putting VA-API on top of VDPAU instead of the other way around. VDPAU already works on Mplayer, FFMPEG, VLC, and XBMC patch-free, and it's somewhat of an open standard. Making Ati's, Intel's, and S3's chips play along means we won't have to wait for patch updates for all the major video playback programs.

[deanjo]

Reactions like these are why people keep this sort of information to themselves. In fact, I was really clear when I sent Phoronix the link that these benchmarks were never designed for comparing card A to card B.

What they ARE good at is revealing two exciting pieces of info:

1. The drop in CPU utilization across the board is magnificent for modern GPU's, even on Intel's side with the GMA 500 (sadly, known as "the one with the crappy closed driver").

2. The performance impact of putting XVBA or VDPAU on top of VA-API doesn't seem significant, meaning VA-API could end up a real winner, given that, assuming we get Ati and S3 issues worked out by year's end, we'll have an API for vid accel that supports chips from four major vendors. That's quite impressive. It'll make for an absurd XBMC LiveCD if they ever add support for it.

All things considered, however, I wonder if we're better off putting VA-API on top of VDPAU instead of the other way around. VDPAU already works on Mplayer, FFMPEG, VLC, and XBMC patch-free, and it's somewhat of an open standard. Making Ati's, Intel's, and S3's chips play along means we won't have to wait for patch updates for all the major video playback programs.

Why even bother with VA-API or XvBA at all? I honestly can't understand why "wrapper love" is so embraced on OS projects that don't need to have a wrapper solution at all. FFS people get pissed off enough when they have to use wrappers for proprietary closed solutions but all of a sudden it's OK to use them on opensource solutions. Fuck supporting 4 damn API's is just plain STUPID. Take the one that is most mature and complete and run with it. Linux was a nice lean OS but this crap is doing nothing but splitting up the talent and adding unnecessary bloat and complexity.

[smitty3268]

Supported means it can be used, and the driver can technically use it.

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.

[smitty3268]

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.

What makes you think the XvBA is any different? I doubt AMD is going to stop anyone from re-implementing the API in other drivers. It's the binary acceleration part that comes with their drivers that you can't simply copy. NVidia is the same, you can re-implement the API if you want, but you can't just copy the code out of their binary drivers. In other words, the Nouvou project is free to implement the VDPAU API by using shaders to accelerate it, but they can't use the dedicated hardware block on the cards, because that's only available with the NVidia binary drivers.

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

What are you talking about? Of course I've heard of ION, and of course VDPAU works with them - I'm just saying that the performance numbers given in this test are more impressive for the Intel parts when you consider that the CPU usage is about the same with them on slower CPU's. Maybe the NVidia numbers would be similar, we really can't tell (and you can't compare to another review, because they use completely different clips/testing methods).

[LavosPhoenix]

Not to mention I don't expect this to ever be supported in a reasonable time considering that fglrx can't even support the newest kernel in a reasonable timeframe.

Maybe AMD needs to take a hint from this economy and hold off from realeasing hardware before they have decent driver support for Windows and Linux. But of course they won't, as the driver is simply free software, while the hardware is where they rape the customers (for money), when the two products should be mutually exclusive.