UVD is an engine on the graphics card while VDPAU is an API to let programs use it. These are two very different things which shouldn't be confused. You need the card's UVD to be supported before VDPAU will ever work as good as in nVidia's implementation.
i thought that VDPAU uses the 3D engine, while UVD was a engine itself...
but if you say that it wont work without UVD...
i really thought that VDPAU can be used on r300g driven cards..
Oh no, as I understand all this theoretically you could implement (expose)vdpau using the 3d engine of the radeon cards. If they are going to do that and if it would be worthwile is something I don't know.
I only care about Video Acceleration. While it works flawlessly under Windows, up to the point where one can easily watch hardware-accelerated YouTube HD videos on even the weakest AMD APU, it is still a huge pain under Linux. There are VDPAU, VA-API and whatnot, every single player has to be patched to use them, every driver exposes a different API, and the open-source drivers don't expose any or offer just half the codecs or it doesn't work. Just today I installed a GT 210 in an HTPC running Ubuntu. I had to manually install VDPAU, libva and smplayer to get acceleration working. All other combinations and players (vlc, xine etc.) didn't work. Great. Sometimes i just wish we had a port of DirectShow.
UVD is indeed the equivalent of PureVideo. There purpose is just to decode video, hence they are special function hardware and extremely efficient.
VDPAU and XvBA are APIs which are mainly meant to take advantage of the above decoders.
This means that they can be implemented even on CPUs but most probably it would not be efficient at all.
The consequence is that either of them could be implemented in a Gallium3D state tracker and any gallium drivers, including r300g, could make use of them.
So yes, the idea is that the VDPAU state tracker tries to create an implementation of said API over gallium. It currently supports r300g, r600g and nouveau.
Now it should be obvious that UVD is not needed for VDPAU on any hardware.
The shortcoming of the Gallium3D state tracker is that it uses the shaders, hence it cannot be as efficient as the UVD would be. This is the main reason why guys at AMD are still battling to provide some sort of support despite the serious legal challenges.
Hope it clarifies a few bits. If I made mistakes hopefully bridgman & co. will fix me.
I wish they'd make power management a bigger priority. Thats the reason I got a new laptop with intel graphics to replace my old laptop that had an hd2600 mobility. Using the OSS drivers on that thing raped my battery life and caused very high temps compared to catalyst, even when I set it to low profile. And on low profile performance wasn't very good for compositing. Dynpm hardly even worked, screen flickered every time it switched clocks. Power management is a total mess right now for those drivers.
This new laptop has less powerful integrated intel graphics, but compositing seems smoother, and I get good temps and battery life. Both catalyst and the oss drivers were too problematic for me in linux to keep using ATI. Catalyst has gotten better, and did give me decent temps, but the fact that it is so broken with gnome-shell was a deal breaker for me.