Introduction
Below are the benchmarks I have put together in watching a High Definition video, with VDPAU, the video decoder for Nividia Linux drivers.. There are some surprising, and welcome results….
UPDATE: You can now compiled rpm’s !
As you can read GeForce 9500GT problems, it took me a lot of hassle getting my Nvidia Linux graphics cards up to the 180.** series. Now I’m finally here, I can check it out for size. One of the key features that the Linux community have been crying out for is the implementation of the VDPAU technology. It stands for “Video Decode and Presentation API for Unix”, and can be found on the GeForce 8 series and beyond. It is the equivalent of the Microsoft Windows “Direct X Video acceleration”, and the aim of the technology is to offload most of the video decoding and post-processing to the graphics card on board memory. Below are a few very primitive, non-scientific tests. But it is surely enough evidence to suggest that the VDPAU technology is enormously significant in terms of the potential for multimedia and video playback for Linux.
I have an .mkv video I want to watch. We are fortunate enough to have the Nvidia linux drivers development team provide a plugin to the mplayer project, and this code in now in the svn repositories. I downloaded the latest snapshot (as of 10th February, 2009) of mplayer, and compiled from source. I did not install into my system (I didn’t run “make install”), so that I had the latest official release of mplayer to compare two. The mplayer software is called by: “mplayer [vidio-name]”. To call the svn snapshot version, I have setup a script called: “myMplayer [video-name]”.
First, the “mplayer” latest release, found in the Fedora stable repositories:
> mplayer [video-name].mkv
I observed for a minute or so, and here are the averages:
CPU usage: 28%
Memory: 21%
Shared Memory: 20%
> myMplayer [video-name].mkv
NOW…. for the mplayer version, with the new VDPAU functionality. I did exactly the same, and here are the results:
The averages:
CPU usage: 2% (that’s TWO percent)
Memory: 8%
Shared Memory: 9%
As you can see, a dramatic improvement in performance in terms of system load. Even with my fairly primitive test, it’s obvious that a large chunk of the work load is being done by the graphics card hardware. I am honestly very impressed, particularly with the amount of CPU usage I free up. (it uses less than 10% compared to the current mplayer release).
The only issues I have now with the nvidia driver for Linux:
-
the svn version of mplayer does not work with twinview enabled: “Error at libvo/vo_vdpau.c”
-
It took too long to fix performance issues with the KDE4 releases. The 180.**, which is widely believed to be the first acceptable release for KDE4 adequate performance, came along side KDE4.2, one year after the KDE4.0 release.
-
I haven’t been told (I doubt I will ever be) why I was needing a BIOS upgrade on my graphics card to upgrade to the latest 180.** series. A LOT of people have suffered this problem. See post: GeForce 9500GT problems for more details.



Comments
VDPAU should work fine with TwinView; many people are using it. If you follow the instructions in the sticky post “How to report problems with VDPAU and/or MPlayer/VDPAU” on nvnews.net, we can investigate your issue.
you need the right tools for comparing cpu usage with good statistic result like sysstat… if u like you can give argument that what i have been test for ffh264vdpau library under 2.6.31 kernel in my blog