Should I downgrade nvidia driver, and how?

[dclement]

Hello,

I have followed the guide to set up the Nvidia proprietary driver. It installed the brand new (295.40) version. Apparently the driver is working, but I'm disappointed at the results.

My laptop has a QuadroFX2700M graphics card with 512Mo. glxgears reports about 3200-3500 FPS, whereas on my previous setup (driver version 195.36.24) it was consistently around 7000-7500 FPS. The difference is obvious, you only have to launch Googleearth to see it.

So, I'm wondering if this difference is a matter of setup, or if the older 195.x driver is better for this card. In this case, I'd rather get some help to downgrade correctly.

TIA - regards, Daniel

[Danko8321]

If you feel system performance has decreased, then, yes, you should. As for the second question, I really couldn't know how you would downgrade it if I don't know how you installed it. Please read this before posting.

[melbo]

I have a NVS 4200M on 295.49 which is the same driver for your card.

This may be relevant to some larger nvidia changes that are coming if you look at the beta driver release notes from 5/2. I've actually run latest beta drivers up until a few days ago when they started to fail. Could be my xorg as they are deprecating a bunch of things with the new nvidia driver. Maybe try a beta and see if it works?

Read more on nvidia's direction:
http://www.nvidia.com/object/linux-disp ... river.html

[dclement]

Thanks for the replies. Then you'd say it's not a simple matter of parameter.

@Danko8321: I followed this guide, to the letter, except that the command line for blacklisting Nouveau did not work (had to do it by hand).

@melbo: Thanks for pointing me to the 302.07beta; it appears to support my card. I'll give it a try.

I'm more comfortable installing a newer version over the previous one. In case of a downgrade, I wonder if I am to remove the current 295.40 before: if a reboot is needed, I even might have to reinstall Nouveau in the meantime?

BTW, I came across the Nvidia forum. I was willing to register there, but their register page appears to be unreachable

[rhodry]

Nvidia has released v295.43 which apparently addresses the known performance degradation in v295.40. That may be a better interim step, rather than going all the way to 'beta' version?

I am sorry but I am unsure how to change the driver using "the Debian way". I use Sgfxi exclusively (and no 'meta' packages) for all video driver work on my Debian installs.

BTW, on the one install where I have had time to change, the performance has improved somewhat.

cheers,
rhodry.

[dclement]

Thank you rhodry, I'll surely test 295.43 first. Moreover, maybe it will hit the repos. soon enough, if it's just a fix.

I'm wondering: when you use sfgxi (which I didn't know), what happens in case of a kernel update? Do you have to reinstall, or is the script smart enough to take care of the change in kernel version?

Cheers, Daniel

[rhodry]

I'm wondering: when you use sfgxi (which I didn't know), what happens in case of a kernel update? Do you have to reinstall, or is the script smart enough to take care of the change in kernel version?

Yes you do have to re-install, part of the price of control - and isn't it good!!!!

Let me explain. I remove all 'meta' packages that deal with kernel and/or graphics drivers. I don't want some update process changing my kernel without my permission. I have never understood why people want to do this, particularly on a laptop where the hardware is unlikely to change at all? Surely, once you have a kernel/driver combination that works well for your hardware ( and that is exactly what smxi/sgfxi lets you experiment with to find) why would you want to change that unless the hardware changes or some nasty bug is found that affects you?! Occasionally, things move along to the extent that you might have to change the kernel, but bringing the graphics driver along is a fairly minor maintenance task once you know the procedure.

BTW, that new version number might be 295.49, in any case, there is an intermediate step.

cheers,
rhodry.

[dclement]

Thanks Rhodry for your detailed answer. I guess the first thing I have to do is try and find a driver, either newer or older, that performs well. And I'll try to put sgfxi to good use for that. Then I must lock the kernel version.

Yes, you are right, the correct number is 295.49. It's the first one I'll try. I'll report the results.

Cheers, Daniel

[dclement]

Hi,

I tried the smxi script. It's impressive. I chose the current (295.49) driver. The result is surprising.

I first ran glxgears which reported only 3000- FPS so it was not looking good. But I then started Googleearth, which shows a dramatic improvement. Perhaps as good as the 195.36 under Ubuntu, visually it's hard to tell.

I'd like to test this 195.36 driver, I have not noticed it as an option when smxi was running. I guess that at some point you can provide a Nvidia .run binary file of your choice.

Then, Rhodry, I don't quite get how you lock the kernel version. The only way I know is package > force version in Synaptic, but I've only done that for very minor programs. Does it make sense to do it for such sensitive packages as linux-headers-xxx?

Cheers, Daniel

[rhodry]

Then, Rhodry, I don't quite get how you lock the kernel version. The only way I know is package > force version in Synaptic, but I've only done that for very minor programs. Does it make sense to do it for such sensitive packages as linux-headers-xxx?

Well, I run the Liquorix kernels on most machines. They are obtainable as part of the Smxi script. As well, within those kernel options there is an option to remove "meta" packages. For Debian this is the 'dkms' packages associated with kernels etc. It is these packages that generate the automatic updates. Remove them and the system just has the installed kernel ( & headers) packages (ie is locked/does not try to update).

The trouble with dkms type stuff is, for example, a kernel update will want to update the nvidia driver BUT it will always choose the latest nvidia driver in the repos. When you get a kludge like 295.40 ( nvidia said they knew it was retrograde for many systems) you go backwards performance and/or bug wise. I don't say I never upgrade but I want them under MY control, having read & researched before such an important change to my systems. Also, I never upgrade my kernel without a known working option already installed to fall back on if necessary. The nvidia updates are just "run the script" against the new kernel.

The 3.0 kernels for example simply would not even boot on some of my hardware, yet I have run 3.3 kernels and in fact 2.6.38 kernels on the same hardware just fine.

Also, you can pin specific packages in '/etc/apt/preferences' with a priority of 1001. That will lock the version from command line upgrades - I never do any other sort. Read up on "Apt Pinning" in the Debian wiki & some other threads in these forums. It is a very powerful tool.

I am very tired, I hope this makes sense - basically read & follow the Smxi script very carefully and you too will once again control your system!
cheers,
rhodry.

[dclement]

Many thanks, Rhodry, for your patience and for taking the time to reply in so much detail.

I appreciate your help (and more generally, all help from this very valuable forum).

Regards, Daniel

[melbo]

I tend to run the beta drivers when available and they've never failed to work. As I run multiple kernels, I use this smxi/sgfxi script to update them all (TO BETA):

Code: Select all

sgfxi -B -! 40

You can research the sgfxi options which will apply xx.xxx nvidia driver to all your kernels - it might be -K, not sure.
But, if / when you upgrade your kernel, its a simple smxi/sgfxi upgrade option and you done.

[dclement]

Melbo, your post makes me wonder about the timing: I apply the updates when I get notified (update manager). So I'm using the GUI at this point.

Let's say the kernel gets upgraded (not the Nvidia driver, as it's not in the repos.). Then at the next startup, won't I be left with a non-working X (blinking cursor)? Or should I explicitly restart to a console in this case and run sfgxi first?