This 180.37 driver addresses the "blocked signals" regression or whatever to some extent. On my Gentoo installation, gnome-bluetooth (bluetooth applet) still segfaults, though 180.29 works fine. Still, some of the regressions like ctrl-c in gnome-terminal etc have been fixed. Importantly, after a long time, firefox-trunk 3.2a1 (minefield) binary works after a loong time. It has been an issue in all of 180.xx and was fine in 177 series. Although it could be worked out by setting USE=-glitz for cairo package. Anyway, I am sticking to 180.29 and using the emerged firefox 3.0 which works fine.
Two things. I bought a 260gtx the other day. I've noticed the drivers still lock up my pc when running games for no reason producing "Xid" errors. The drivers also now cause gnome-settings-daemon to crash and gdm is unable to start as a result. I have to manually start X to get into my desktop. I dropped back to the old 180.29 drivers and the issues were fixed so it looks like nvidia have a ton of bugfixing to do.
I think, as already pointed out, that it's great to see some pace in the unix-driver development. Now if they could just release a 64-bit FreeBSD driver...
I think that phoronix misses an inportant point: These are only alpha/beta drivers, and aren't as such offical releases. They can't even be found via nVidias own search for beta-drivers, so perhaps more alpha... Please stick to the facts.
One thing that has never worked with the beta-drivers from nVidia is suspend-to-ram, which is a must-have for me.
I have tried mplayer with VDPAU extension. The power consumption is about 10% on my Quadro FX570M in lowest power mode (33W-35W/38W peak), than on the Core2 Duo T7700 2.4 (30w-33W/35W peak).
Both cores are mostly at 800MHz while playing a fullhd trailer. One core is jumping mostly to 1.2GHz and to 2.4GHz every two seconds.
Where are the benefits in GPU based decryption (besides netbook usage)? I only see disadvantages.
higher power consumption
stops instead of interruption while streaming
higher temperature of cpu and gpu (one cooler)
Sounds like your core jump could be related to file system overhead when it's reading to fill the buffer. Some tweaking to your i/o settings may improve this for you. The other possibility is some disk indexing service is running or you have something like FF running in the background with a flash process going on.
As far as higher temperatures go, vdpau should exhibit much lower temps across the board as the GPU does not have to ramp itself up into "premium" mode and maintains operating at it's lowest, coolest mode. If strictly CPU was used it would be running at it's highest speedstate giving off more heat and working at hit's most power hungry state and GPU consumption stays the same as with vdpau.
Interuption of streaming could be compensated with a larger buffer. This in time should improve in the various projects out there using vdpau (xine-vdpau being the most agressive to address this with it's wide acceptance being used in pvr projects).
Sticking to the facts then. Yeah sure the beta drivers were unstable, cool I can accept that they're beta. But even the "stable" drivers are unstable. I get lockups quite often when using the stable drivers eg 180.29. I was getting those lockups on my 8800gts 320mb and I still get them on my 260 core 216 gtx (when using 180.29). Strangely one of the ways to avoid the lockups seems to be to leave nvidia-settings open on my desktop while I run programs. Annoying but it does seem to help. The errors are all nvrm and Xid error messages. This happens still in the unstable beta drivers as well as in the stable 180.29 drivers so it looks like nvidia still need to bugfix those issues. As for the new beta drivers, well they nuked gnome pretty effectively so I hope they are aware and fix the issue before the next release. Gnome-settings-daemon is the application that seems to die. There may be more core services related that segfault though. Vino also looks like it dies.