VDPAU slower than software-only?

[ChrisP]

Hi folks,

I'm trying to play back a few different h264 files with VDPAU, and I'm seeing considerably worse performance when VDPAU is enabled - lower CPU usage but many more frames being dropped.

My system:
8800m GTX w/512Mb (180.51 driver)
Core 2 Duo T8300 (2 x 2.4GHz)
Intel HDA Audio
Fedora Core 10 32-bit
mplayer-svn (checked out today).
All files are on the local hard drive.

I've tried a few different files at 720p and 1080p, running them as either:
./mplayer -vo vdpau -vc ffh264vdpau FILE
or
./mplayer FILE

720p files with VDPAU give me the mplayer performance warning, the same file without VDPAU plays back fine with far fewer visible dropped frames. 1080p gives me the performance warning on both, but again enabling VDPAU causes far more frames to be dropped on playback. In both cases I see about 1-10% CPU usage with VDPAU enabled, 80-90% without it.

I've disabled PulseAudio (it was sitting at about 15% CPU) which made no difference, I'm somewhat at a loss what to try next. Any ideas?

[thefirstm]

Can you try executing a 3D program, like GLXGears, while the video is playing? On my card, unless I do this to get it to throttle up, the performance is bad.

[ChrisP]

Originally Posted by thefirstm

Can you try executing a 3D program, like GLXGears, while the video is playing? On my card, unless I do this to get it to throttle up, the performance is bad.

Interesting. Running glxgears while the video is playing does indeed appear to throttle up the card, considerably reducing the problem but not eliminating it. glxgears+mplayer is about on par with software only - still some dropped frames but nowhere near as many. Thankyou for the suggestion

I guess the next question is, how can I do this automatically? Have you found another way to do the same thing (or a way to leave it in high-performance mode) without glxgears?

[thefirstm]

After you start GLXGears, then kill it again. This way, the two apps will not compete for GPU cycles. The card shouldn't throttle back down, though.

[ssnyder]

Just another data point. I'm seeing similar behavior.

Hardware:

8800 512MB (G92)
Core 2 quad @ 2.80GHz
8GB system RAM
4xRE2 in a RAID10 config

Software:

Fedora 10 x86_64 (KDE desktop)
NVidia 180.51 drivers
MPlayer svn (pulled on 26 Apr 2009)

Test files are various H264 720p videos played from the local hard disk (max read STR = ~120MB/sec). For example, this freely-downloadable video (select the 1.4GB HD version):

http://herebedragonsmovie.com/download.php

With VDPAU enabled I don't see explicit MPlayer errors or warnings, just jerky playback, with very brief pauses every couple of seconds. VDPAU does indeed reduce CPU utilization but at the cost of performance.

In my experience, on this hardware:

VDPAU <-- lowest absolute CPU use; sporatically stuttering playback
default <-- middling performance and CPU use
S/W decode in 4 threads <-- highest CPU use; best playback performance

FYI.

[ssnyder]

Some hard numbers to support the experiences described above:

mplayer -quiet -nosound -benchmark -vo vdpau -vc ffh264vdpau movies/HereBeDragons.m4v
(.mplayer/config: nothing)

BENCHMARKs: VC:   4.407s VO: 399.643s A:   0.000s Sys:   6.466s =  410.515s
BENCHMARK%: VC:  1.0734% VO: 97.3515% A:  0.0000% Sys:  1.5751% = 100.0000%

-----

mplayer -quiet -nosound -benchmark movies/HereBeDragons.m4v
(.mplayer/config: nothing)

BENCHMARKs: VC: 236.867s VO:  49.236s A:   0.000s Sys:   2.543s =  288.645s
BENCHMARK%: VC: 82.0615% VO: 17.0575% A:  0.0000% Sys:  0.8810% = 100.0000%

-----

mplayer -quiet -nosound -benchmark movies/HereBeDragons.m4v
(.mplayer/config: lavdopts=fast=1:threads=4)

BENCHMARKs: VC:  92.028s VO:  55.334s A:   0.000s Sys:  10.197s =  157.560s
BENCHMARK%: VC: 58.4084% VO: 35.1195% A:  0.0000% Sys:  6.4721% = 100.0000%

With VDPAU enabled the CPU use is dramatically reduced, yet it takes 160% longer to play the entire video (relative to 4-thread software decode).

[cehoyos]

Originally Posted by ssnyder

mplayer -quiet -nosound -benchmark -vo vdpau -vc ffh264vdpau movies/HereBeDragons.m4v

VDPAU performance can not be measured like this.

Carl Eugen

[ssnyder]

Originally Posted by cehoyos

VDPAU performance can not be measured like this.

Carl Eugen

That's it? No explanation?

Not a confidence-inspiring assertion.

[ChrisP]

Originally Posted by thefirstm

After you start GLXGears, then kill it again. This way, the two apps will not compete for GPU cycles. The card shouldn't throttle back down, though.

Not what I'm seeing - when I kill glxgears the card slows back down and the video starts getting jerky again. Restart glxgears and the video smooths out.

Might it make a difference that this is a mobile chip? Presumably it's throttling down to save power - any way to disable this behavior either temporarily or permanently?

[cehoyos]

Originally Posted by ssnyder

That's it? No explanation?

I'll try to explain:
When playing a moderate-bitrate 1080p sample (like an Apple HD trailer) with -nosound -benchmark, it seems that software decoding is a lot faster (finished earlier) on my computer than VDPAU accelerated decoding (not matter which - useful - vo I use for software decoding).
OTOH, the Samsung (deep ocean) trailer immediately shows heavy desync on my E8400 with software decoding, but decodes fine with VDPAU.
So while there are (many) samples that indicate "VDPAU is slower than software-decoding", it actually isn't for most real-world scenarios that matter.
(Of course you may have a processor that can decode any sample faster than VDPAU, but that is not the case for most people, and it also doesn't contradict what I tried to say when I wrote that benchmark is not useful to test VDPAU's performance.)

Carl Eugen

[Stephen Warren]

I just wanted to note that NVIDIA is aware of the VDPAU/PowerMizer interaction issues on some boards (i.e. the problem where VDPAU is slow unless glxgears is run, thus kicking up the GPU performance level) . We are working on fixing this, and making good progress. A fix should be released in a future 185.xx driver, although it's too early to say exactly which one yet.