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

[phoronix]

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

Going back to last year we have exclusively been reporting on AMD's new HD video decoding interface, which is called XvBA. This interface for use with UVD2 GPUs is properly known as X-Video Bitstream Acceleration, which we have already described at length...

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

[thefirstm]

NVIDIA's headstart will definitely help here. Some competition will be nice, though, giving incentive to add performance and features.

[phhusson]

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/XFree86/Linux-x86_64/185.18.14/README/appendix-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

[Ex-Cyber]

I'm not a big fan of competition when it's one vendor-specific API against another; that just means app developers have to either do more work to support both APIs or alienate a big chunk of the user base by choosing one API. Hopefully this will all get unified behind one open API (which seems to be the direction VA API is headed) and they can compete purely on implementation quality.

[monraaf]

Video decode acceleration with XvBA on Linux doesn't work very well over here. It's probably vaporware for anything but embedded solutions anyway.

[Kjella]

[b]Going back to last year we have exclusively been reporting on AMD's new HD video decoding interface, which is called XvBA.

Yes, for over a year you've been hyping the vaporware that we all knew was there (it works on Windows, right?) but that there's no commitment that will ever be released for Linux, and with a snowball's chance in hell for the open source drivers which is IMO the only reason you would want an AMD card under Linux anyway, except dual booting for games.

Of course they picked a card with only partial decoding support for VC1 - the whole idea of full decoding support is that you push it to fixed function hardware and that handles the rest which means you can do it on the lowest of low-end. Like in your own "HD Video Playback With A $20 CPU & $30 GPU On Linux" article. The question of this article is like "What CPU runs notepad faster?"

It's been the same tone now in pretty much every article since nVidia released VDPAU, that "AMD is right behind, XvBA is coming any day now, just stay tuned." And every article about more and more support for nVidia has become a little more desperate, and this one is just approaching embarrasing. nVidia has mature, well supported and excellent acceleration in all video backends that matter and AMD got nothing.

Nothing.

[deanjo]

I'm not a big fan of competition when it's one vendor-specific API against another; that just means app developers have to either do more work to support both APIs or alienate a big chunk of the user base by choosing one API. Hopefully this will all get unified behind one open API (which seems to be the direction VA API is headed) and they can compete purely on implementation quality.

Well vdpau is open. Even Via's chrome now supports it. And ya take the VC-1 comparison with a grain of salt. They are using a old 8600 card vs one of the 8 or 9 series IGP's or cards like the newer 8400 cards which have PureVideo support that does do full VC-1 acceleration. The two vc-1 example's play great at < 1% CPU usage here on a nvidia IGP that has PV Gen 3 support. There is also the fact that while he is using the latest official drivers the recently leaked Cuda drivers have many vdpau improvements as well. Another thing is he could have at least used the two discreet cards in the same system.

[smitty3268]

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.

2. This article kept mentioning that XvBA was supported by the drivers, which is flat out FALSE. It isn't supported at all, it hasn't even been announced yet, as mentioned above in point 1. Phoronix is really doing a disservice to AMD here and riling people up over nothing. An initial post when the library was first added is OK, and maybe 1 more every few months with a quick status update (no new news) is fine, but you shouldn't seem to be putting words in AMD's mouth that they have never said.

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.

[Melcar]

2. This article kept mentioning that XvBA was supported by the drivers, which is flat out FALSE. It isn't supported at all, it hasn't even been announced yet, as mentioned above in point 1. Phoronix is really doing a disservice to AMD here and riling people up over nothing. An initial post when the library was first added is OK, and maybe 1 more every few months with a quick status update (no new news) is fine, but you shouldn't seem to be putting words in AMD's mouth that they have never said.

...

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

[smitty3268]

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

"Supported" is very, very different from "present." I believe Micheal is a native english speaker who should know this. AMD could easily remove XvBA from their next driver like it never existed, because they haven't ever said they would support it. I don't believe they've ever even acknowledged it's existence.

[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/XFree86/Linux-x86_64/185.18.14/README/appendix-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.

[deanjo]

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.

Sure you can use shaders if you wish with vdpau or you can use a chips dedicated hardware, either or can be done so why the hell do we need yet another API that hasn't even seen the light of day yet or one that has hung in utter limbo for the last few years. Vdpau is the most widely accepted API at this time with the most development happening on it, why dupicate efforts when it is not needed?

(BTW: IIRC ATI's solution uses a shader based solution (at least partially) as it is.)


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).

When guys are running things like the killa sampla on a morgan core's and katmai with less then 5% cpu usage you can guarantee that a atom based system wouldn't hiccup. Even then more cpu usage is probably used accessing the disk and processing the audio and other background tasks. One thing the tests also did not reveal is if cpu's stayed in their lowest power state or not, if any frames were dropped. Without a timeline graph the results or at least a frame count and played frame count the results are very incomplete.

[smitty3268]

Sure you can use shaders if you wish with vdpau or you can use a chips dedicated hardware, either or can be done so why the hell do we need yet another API that hasn't even seen the light of day yet or one that has hung in utter limbo for the last few years. Vdpau is the most widely accepted API at this time with the most development happening on it, why dupicate efforts when it is not needed?

(BTW: IIRC ATI's solution uses a shader based solution (at least partially) as it is.)



When guys are running things like the killa sampla on a morgan core's and katmai with less then 5% cpu usage you can guarantee that a atom based system wouldn't hiccup. Even then more cpu usage is probably used accessing the disk and processing the audio and other background tasks. One thing the tests also did not reveal is if cpu's stayed in their lowest power state or not, if any frames were dropped. Without a timeline graph the results or at least a frame count and played frame count the results are very incomplete.

Well, I think we finally agree. :) All the tests really showed was that it's possible to get good acceleration on all 3 cards, but with no way of comparing them or mentioning quality, etc.

I think some of what you say about XvBA could actually be said of VDPAU when it came out - why didn't they just use the existing VA-API stuff? But it seems silly to go from 2 API's up to 3 when it isn't needed.

I think there's a little confusion going on here about what VDPAU actually is. It's an API, which can have any backend implementation you want to give it. So NVidia does it by accessing their custom hardware, and Via does it by accessing their hardware, and Nouveau can do it by using shaders. Or reverse engineering the binary drivers. Likewise AMD could do it by using shaders (open-source) or UVD2 (binary). The XvBA API would be the same type of situation for anyone who wanted to implement it - dedicated hardware for the binary drivers, and shaders or reverse-engineered code for the open source ones.

Regarding the AMD hardware using shaders for acceleration: that's how UVD1 cards did their video acceleration, but UVD2 cards have the same type of custom decoding hardware that NVidia uses. The original r600(HD2900?) card was UVD1, but I think all the other r600 cards and definitely all the r700 cards have dedicated hardware in UVD2.

[MostAwesomeDude]

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.

Arg. If before, I were a sad panda, I am now a morose raccoon.

XvBA can't be implemented by us, because we have no idea what it looks like! Also, the only reason we don't know how to use the video blocks, is because nobody has stepped up and reverse-engineered them; there's no magical keys that can lock us out of the HW.

And no, I don't think anybody on the open-source side wants to do any more split video decoding backends. Let's just do everything on Gallium and be happy with it.

~ C.

[AdrenalineJunky]

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.

if anything its the poor software support they are raping thier customers with.

thier hardware is overall much better priced then nvidia's.

[GreekGeek]

Might as well say, will tea ever taste better than coffee? Except, one can buy tea now and make it....

When it comes to vid-decode and playback, nVidia has done the hard yards of training and has this race won. Period.

DAMMIT/ATI-AMD have dropped the ball and scored an own goal. The troulbe is, I spent $500.00 on DAMMIT hardware, that I am deprived the use of in Linux. Suffice to say, one is not ammused! ;-)

"...he admitted to using an xvba-video package, which is currently not publicly available." This whole issue is playing out like a farce, literally at the expense of those who purchased DAMMIT hardware.

Counter-intuitive way to play, in a economic recession, to give the game to your main business competitor?

For the record, Greeks do prefer coffee. :-)

GreekGeek.

[Kano]

The Benchmarks are really funny. Did somebody notice that he used a "Mobility Radeon HD 4870 - 550 MHz, 1 GB" together with a "Phenom 8450"? Btw. providing some random numbers do not show anything, the actual wrapper has to be freely available.

[bridgman]

Regarding the AMD hardware using shaders for acceleration: that's how UVD1 cards did their video acceleration, but UVD2 cards have the same type of custom decoding hardware that NVidia uses. The original r600(HD2900?) card was UVD1, but I think all the other r600 cards and definitely all the r700 cards have dedicated hardware in UVD2.

Close. The original R600 (HD2900) did not have UVD, so any decode acceleration has to be done with shaders or the legacy IDCT block carried over from earlier GPUs. The rest of the 6xx line (HD2xxx, HD3xxx) has UVD1 and a separate IDCT block for MPEG2.

The 7xx line has UVD2 but no separate IDCT block; MPEG2 decode is done by UVD2.

The rs780 is between UVD1 and UVD2.

Arg. If before, I were a sad panda, I am now a morose raccoon.

AFAIK a sad panda is generally considered to be less happy than a morose racoon. I'm glad you're feeling better :D

[Silent Storm]

I don't know if it's the correct place to tell such things but I don't have a better choice at this time. If anyone can point me to a better place to tell such things, I'll be happy.

To be honest, I hate how ATI develops and incorporates new technologies and features to its drivers and steadily shoots themselves on the foot.

I didn't read all the messages but I've seen a "nVidia's headstart" argument. Unfortunately ATI had it first, literally years ago, in Radeon 8500 era. It was called VideoShaders and VideoSoap. Did anyone hear it? It's unlikely because nobody except ATI tech demos used it. It was a CPU independent video acceleration and post-processing pipeline and worked very well.

I never had a 8500 but had a 9600XT which was a fantastic, cool operating graphics monster and had these features built-in too. It was never marketed with videoshaders and videosoap but, it had them. 8500's and 9500's videoshader tech demos worked exceptionally well and smooth. Some programs were able to render 720P videos with it but nobody, literally nobody from ATI advertised these features even after pureVideo came to life. ATI had it first but were always shy to say so. As a result, videoshaders outdated and died without any major processing history.

ATI's drivers before the big cleanup (the one before the latest one) had built-in support over XV pipeline and it was like having a upscaling video processor onboard. With the Xv re-implementation, it has vaporized and my X1650's video playback has didn't come back for some months (after that my PSU blew up and I switched to nVidia with rage).

Currently as a nVidia user who doesn't feel at home, I eagerly wait the day that ATI will rise from its ashes so I can buy a card with better sharpness and video detail. nVidia incoprorated VDPAU which works well enough but which cannot clean videos and upscale them well. I cannot watch any DVD in my 22" screen with enjoyment.

Today I read that we have XvBA and has it since Q4'08 (I may have missed the first news, it was a hard Q4'08 for me). It's not official, it's not beta, it's not public, it's just an internal code chunk which developers play in their free time.

Let me say what I think about its future. This feature will not be picked up again because it'll be too late when it's finished. Since it'll be too late, ATI will not talk about it. Since it won't be mentioned it's API may not be published or will be in some dark corner in the internet. As a result, it won't be tested, fixed, improved and publicized and as a result many won't be able to buy an ATI card because of its linux drivers and lack of features.

Please don't make this feature obselete on arrival. Show your true potential guys! I really feel sad when I think that ATI cannot deliver.

P.S: I was an ATI user since Rage64 era. With my X1650 burning my power supply because of ATI thinking that I don't need powersaving (shutting down the parts of the processor which I don't use ATM) in Linux, I switched to an nVidia 8800GTS and I'm happy but not content and feel at home.

[Chewi]

I'm confused about where XvMC fits into this. Isn't it already possible to configure mplayer for XvMC using XvBA? I managed to do this myself but I can't get the XvMC output to work. Some people have got this working though. So what's the difference?

[gbeauche]

We can't compare API from benchmarks, an API is a specification. What matters is the actual implementation (driver, HW). I used what I have around me: old 8600 GT and a GTX 280M. Both only do partial VC-1 decoding but people won't care about VC-1 anyway.

If I were to classify APIs by features and/or openess, that would be in this order: VA API, VDPAU, XvBA. The former because it does handle video encode acceleration, which interests most nowadays too, among more codecs. The latter only because it's not public, but has interesting features. VDPAU is very well documented though.

If I were to classify APIs by their implementations, that would be in this order: VA API, VDPAU|XvBA. The latter two at the same level because both only support their respective HW. You can address all HW through VA API. There is now even an Open Source driver for Gen4 Intel GPUs (e.g. i965). Though, this only does MPEG-2 VLD at this time. Also note that the Poulsbo video driver may also be Open Source'd by Q4 2009 (when Moorestown is out?). What other vendor is doing that?

If I were to classify APIs by video player usage, that would be in this order: VDPAU, VA API, XvBA. BTW, if you know how to handle VDPAU through FFmpeg, you will know how to handle VA API through FFmpeg, it works the same way. The reason why VA API is no more widely used is drivers were missing. Now, there are, and people start using it. e.g. VLC.

As a summary, we can have VA API working on the following platforms: AMD, NVIDIA, VIA Chrome, Intel own technologies (G45) or borrowed ones from Imagination Technologies (US15W). That's 5 possible implementations, either directly or indirectly through adaptors.

BTW, if someone could send me a VIA Chrome card, I could write some compat code to support their older libVA drivers that are actually based on DXVA. That way, Linux distributions could trivially support all 5 kinds of HW through a single libVA library.

[thefirstm]

I didn't read all the messages but I've seen a "nVidia's headstart" argument. Unfortunately ATI had it first, literally years ago, in Radeon 8500 era. It was called VideoShaders and VideoSoap. Did anyone hear it? It's unlikely because nobody except ATI tech demos used it. It was a CPU independent video acceleration and post-processing pipeline and worked very well.

I said that. I should have clarified myself more. What I meant was that Nvidia had a headstart when it came to hardware decoding on UNIX-like operating systems.

[Regenwald]

OT:
Am I the only one who read the blog entry and found that: "The Poulsbo (US15W) video driver may be Open Source'd by Q4 2009"??

well that's even better!

[Kano]

@bridgman

When XvBA works so well why didn't ATI ship headers to use it? Also some programming examples would not hurt too...

[Silent Storm]

I said that. I should have clarified myself more. What I meant was that Nvidia had a headstart when it came to hardware decoding on UNIX-like operating systems.

ATI had GPU acceleration before in Linux in 9600 and X1600 era but they dropped it to re-write it from scratch. It was not literally HW decoding but it accelerated most of the video and enabled 720P videos over Xv with reasonable CPUs like high end athlon XPs and first gen Athlon64s

What you are right about is the adoption and marketing side of it, which by no means hinder the truth value of your argument. Even the technical side is different, the real situation is again reflected by your argument.

I wanted to point that the fact of being better and being first doesn't always bring victory but instead of writing it directly, I injected the whole idea to the post.

[gbeauche]

Take the one that is most mature and complete and run with it.

That's exactly why I chose and now stick to VA API.

One thing the tests also did not reveal is if cpu's stayed in their lowest power state or not, if any frames were dropped. Without a timeline graph the results or at least a frame count and played frame count the results are very incomplete.

The initial testing used the -frames 1000 option, but I changed the procedure when I noticed only the Poulsbo dropped a few frames with the Riddick video (and only for this video). Dynamic frequency scaling was also enabled so the CPUs were at their lowest frequency: 800 MHz for the Atom CPU, 1 GHz for the Phenom CPU. Then, I redid the test in "performance" mode to have interesting measures wrt. Xv.

The Benchmarks are really funny. Did somebody notice that he used a "Mobility Radeon HD 4870 - 550 MHz, 1 GB" together with a "Phenom 8450"?

Do you know about MXM-to-PCIe adapters? Yes, I also had tested a GTX 280M in the same box, but the results were not conclusive enough since the GPU was not running at its highest frequency. So, I didn't publish the figures, though you can get them in the tarball. :) They won't represent the real G92 core capabilities though.

[greg]

That's exactly why I chose and now stick to VA API.


I'd rather consider VDPAU to be the most mature API. It is widely supported by applications, works well (on NVidia GPUs) and is very well-documented. Currently it's the only video decoding API which has an implementation that "just works" *now* and without major fuss.

VA-API on the other hand is badly documented, if at all, and seems to be missing out some of the functionality provided by VDPAU.

[gbeauche]

I'd rather consider VDPAU to be the most mature API. It is widely supported by applications, works well (on NVidia GPUs, no idea about S3) and is very well-documented. Currently it's the only video decoding API which has an implementation that "just works" *now* and without major fuss.

VA-API on the other hand is badly documented, if at all, and seems to be missing out some of the functionality provided by VDPAU.

S3 doesn't use VDPAU.

The question was about mature and complete. VA API is just that:
- complete: supports more codecs and video encode acceleration
- mature: well, it has been around for a long time, though implementations were not public. There are at least 4 (if not 5), "native" implementations, i.e. real drivers, not counting my bridges.

Now, as I said, applications support is weaker due to initial lack of drivers, but it's as trivial to add as for VDPAU. So, this can change quite easily.

[timofonic]

GEM vs TTM

XvBA vs X-Video vs VDPAU vs VA-API

...

When will this API/subsystem nightmare end? Please make a unified API for hardware video decoding, this is a pain in the ass...

[deanjo]

S3 doesn't use VDPAU.


Wrong.


RELEASE HISTORY

06/26/2009: Version 14.02.17
- Bug Fixes
- XRandR support
- VDPAU support
- KMS Support

The S3 Graphics Accelerated Linux Driver Set support:

* Linux Kernel 2.6.x
* X.Org X11R7.x with H/W 2D acceleration through XAA or EXA
* SAMM / MAMM / Xinerama with multiple display
* DVI dual-link up to 2560x1600 resolution
* 90/180/270 degree display rotation
* H/W accelerated direct-rendering OpenGL 3.0 API
* H/W accelerated indirect-rendering OpenGL 2.1 API
* Composite Desktop with AIGLX / Compiz
* Full featured RandR 1.2 function
* Kernel mode setting with standalone module
* Full H.264, VC-1, WMV9 and MPEG-2 VLD bitstream H/W decoding
through VDPAU or VA-API driver

This README describes how to install, configure, and use the S3 Graphics
Accelerated Linux Driver Set.


http://drivers.s3graphics.com/en/download/drivers/chrome5x-Linux/RN_Linux_EN.txt

[mendieta]

And no, I don't think anybody on the open-source side wants to do any more split video decoding backends. Let's just do everything on Gallium and be happy with it.

~ C.

Apparently there was a SOC2009 idea for VDPAU via Gallium:
http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas

I don't know if it materialized, but this is _really_ the way to go!

[phhusson]

It was called VideoShaders and VideoSoap. Did anyone hear it? It's unlikely because nobody except ATI tech demos used it. It was a CPU independent video acceleration and post-processing pipeline and worked very well.
Since Geforce FX (maybe even before, not so sure), there was also some hardware video decoding acceleration through XvMC, and has always been here, until Geforce 8, which got VDPAU, and as far as i remember (that was a long time ago), the video decoding was almost totally dischard to the GPU (on a athlon 2500+ i had less than 10% of CPU activity) for MPEG2, others codecs could have been also accelerated if someone ever done some code to use this motion compensation in it, but noone ever did :/

[bulletxt]

Once again Phoronix and its lame AMD articles....

[Silent Storm]

Since Geforce FX (maybe even before, not so sure), there was also some hardware video decoding acceleration through XvMC, and has always been here, until Geforce 8, which got VDPAU, and as far as i remember (that was a long time ago), the video decoding was almost totally dischard to the GPU (on a athlon 2500+ i had less than 10% of CPU activity) for MPEG2, others codecs could have been also accelerated if someone ever done some code to use this motion compensation in it, but noone ever did :/

GeForce FX was the first family that came with the ShaderFX and CinemaFX (or CineFX) engines, you are right, but 8500 family is older than FX family IIRC. Also Rage64Pro had a hardware DVD decoder which Creative made some fortune by selling as an additional card (which was different than ATI's anyway).

Whatever, this is not a flame war. My point was that ATI is consistently the first company to innovate things and to fail since they're unable to market and use it correctly.

[m4rgin4l]

Once again Phoronix and its lame AMD articles....

+1

This "In the future there will be robots" kind of news is getting old. By the time XvBA is oficially published there would be a new X.org version and, guess what? It won't be supported by the Catalyst driver so we'll be stuck with the open source drivers.

[deanjo]

Also Rage64Pro had a hardware DVD decoder which Creative made some fortune by selling as an additional card (which was different than ATI's anyway).

Creative didn't use a Rage64 based card for it's DVD decoder card. It was a clone of the Sigma Designs Hollywood +.

[Silent Storm]

Creative didn't use a Rage64 based card for it's DVD decoder card. It was a clone of the Sigma Designs Hollywood +.

I thought that I said that by saying "which was different than ATI's anyway". =)

[nanonyme]

GEM vs TTMErr, pretty much everyone is using GEM API. ;) Even radeon open drivers which are implementing GEM API with TTM. There is no issue there, seriously...

[Ex-Cyber]

Well vdpau is open. Even Via's chrome now supports it.Sorry, I was thinking of the CUDA SDK license (which has an "only with Nvidia products" clause). Via/S3 supporting VDPAU changes the landscape somewhat, although it would really need to work with Intel IGPs to even have a chance at being a universal standard. Is anyone working on that?

[Kano]

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. There exists a VDPAU to VA-API wrapper which was used for benchmarking too on that site and VA-API patches for mplayer. So when the xvba wrapper to VA-API would be released for everybody that should be enough for now.

[MostAwesomeDude]

GEM vs TTM

XvBA vs X-Video vs VDPAU vs VA-API

...

When will this API/subsystem nightmare end? Please make a unified API for hardware video decoding, this is a pain in the ass...

GEM provides a unified API for kernel MM, which we've agreed is fairly useful. The MM being used is TTM, except for Intel, which uses GEM as their MM since is provides special optimizations for integrated chipsets. This is not a problem.

Xv (Xvideo) is a colorspace conversion and scaling system. It is not really video playback, although it's useful for putting video frames to the screen quickly.

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.

Apparently there was a SOC2009 idea for VDPAU via Gallium:
http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas

I don't know if it materialized, but this is _really_ the way to go!

That one was my suggestion, actually. I dropped it when marcheu declined to mentor, and I found myself in the unenviable position of mentoring. :3

[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.

[Kano]

Well usable is hard to say. It seems only embedded device manufacturers got the needed headers to write apps which support xvba - and the funny one who made those benchmark tests to annoy people because HE can use it but nobody else. If you would get a precompiled binary you could use it, but how to get it?

[The_Monkey_King]

Finally though it looks like AMD may be prepared to launch XvBA formally this summer. - Michael Larabel

US definition of Summer: Begins June 21, summer solstice, and ends with the autumnal equinox on September 22.

Time left in Summer -- 73 days (inl. weekends)

[GreekGeek]

Hi all and Monkey King,

I really do hope that ATI/AMD do finally enable ther world klass video decodes on the HD4xxx cards. Getting what one paid for is always a good thang! :-)

By the end of the USA summer, would be a year later, but better later than never.

To many of these "coming up real soon now," articles, followed by the big nada, does tend to reinforce the notion, that we are all listening to, "the boy who cried wolf...." I do hope that is not the case. But I have been wrong b4.

Crossez fingerz. :-)

GreekGeek.

[popper]

hmm did this news go over everyones heads then?, wasnt the real news here that
there is apparently now a working "UVD" ASIC hardware codebase in the hands of (i assume thats you gbeauche ?) Gwenolé Beauchesne that previously wrote the VA-API support for MPlayer / FFmpeg and even a VDPAU back-end for VA-API. (along with SheepShaver, and adapted many just-in-time (JIT) translation techniques lets not forget :) ) we may get to use the ATI "UVD" hardware decoding and frame accurate editing in some form if it makes it to the likes of FFMPEG patchs and at some point soon, FINALLY ?

why are you already arguing the API points when you cant even currently use or code for the "UVD" hardware right now without Bridgman's help and Gwenolé's currently usable codebases....

rememeber way back in january 8th 2009 Bridgmen said:

Quote:
Bridgmen said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


popper said:thats a shame, we are looking at months at the very least then!


Quote:
Bridgeman said:For open source, yes, but I expect fglrx will have it sooner.

[bridgman]

You didn't miss anything. We didn't make a public announcement because the current implementation is not something we can make available other than in embedded applications under NDA. When we have an implementation which can be made publicly available, trust me you'll know about it :D

[Gamester17]

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.Supporting both would be awesome!

VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.

Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.

If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.

PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
http://xbmc.org

;)

[MostAwesomeDude]

Supporting both would be awesome!

Yes.

VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.

No. That is just more overhead and more silliness.

Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.

The entire point of Gallium is to not need to have universal APIs. Instead, you have frontends for each OS and windowing system, and a single driver in the backend.

Additionally, the media player guys don't get any breaks if the video decoding API is universal; they still have to have GUI stuff broken out. (Well, except for VLC because they use Wx, but you're not talking about VLC.)

If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.

VDPAU is for Unix-likes only.

PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
http://xbmc.org

Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...

http://bugs.freedesktop.org/show_bug.cgi?id=21145
http://xbmc.org/trac/ticket/6382

[TrentZ]

(Well, except for VLC because they use Wx, but you're not talking about VLC.)
http://xbmc.org/trac/ticket/6382

VLC uses Qt4. wxWidgets GUI was deprecated circa 0.9.0.

[Gamester17]

VDPAU is for Unix-likes only.I know, I was refering to that NVIDIA basically got the idea for VDPAU by reverse-engineering the concept behind the DXVA design :p

Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/ ;)

http://bugs.freedesktop.org/show_bug.cgi?id=21145
http://xbmc.org/trac/ticket/6382This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

http://xbmc.org/about/vision/Last but not least, be beautiful to look at, after all, we hope you will be using it a lot!

[MostAwesomeDude]

Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/ ;)

This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

http://xbmc.org/about/vision/

No slight meant.

The bug's in XBMC's GLX setup, and it could be fixed with a bit of code inspection. Maybe I'll fix it someday. Has nothing to do with shaders.

Actually, somebody should really change the GL setup too so that it falls back to ARB programs if available (which do work in current Mesa) and to properly detect GL extensions. Unless I'm out-of-date and somebody's already done it, of course.

[Gamester17]

Actually, somebody should really change the GL setup too so that it falls back to ARB programs if available (which do work in current Mesa) and to properly detect GL extensions. Unless I'm out-of-date and somebody's already done it, of course.Couple of the XBMC developers focusing on graphics are currently working on refactoring the graphic/rendering code in XBMC to make it more abstract (getting rid of SDL dependencies and enabling future XBMC to not only support OpenGL for renders in the future, with XBMC being multi-platform and all), ...however I do not believe that they are specifically looking at that, so a feature request ticket(s) on our trac for tracking purposes would be more than welcomed http://xbmc.org/trac

Else we forget :)

[TrentZ]

(Well, except for VLC because they use Wx, but you're not talking about VLC.)
http://xbmc.org/trac/ticket/6382

VLC uses Qt4. wxWidgets GUI was deprecated circa 0.9.0.