Step Two - Install The Basic NVIDIA Driver 'NVdriver', Continued
If you have not followed my advice above you might get one of the following two error messages and NVdriver won't load (try it again with '/sbin/insmod NVdriver' if you can't find it in the '/sbin/lsmod' list):
- You get a list of 8 'unresolved symbol agp_... '
This means that the driver is depending on the AGP-driver 'agpgart.o' which isn't loaded. If you can, load it with '/sbin/insmod agpgart' or '/sbin/insmod agpgart agp_try_unsupported=1'. If this doesn't work you need to make your driver again. Erase all AGP stuff out of your /src/include/linux/autoconf.h', clean your make directory for the driver and 'make' again. This time the driver should load, but it won't have AGP GART support and will therefore perform worse.- You get the error message 'unresolved symbol tqueue_lock'
The driver has been compiled as SMP-driver, but your system is not a multi-processor system. Change autoconf.h as described above, clean the make directory and make the driver once more. It should load this time.
You could see above that many AGP-chipsets need the setting 'agp_try_unsupported=1' for the 'agpgart.o'. This driver is officially only supporting Intel's 440BX, 440GX, i810, i810e, VIA Apollo Pro and AMD Irongate chipsets. If you've got a different chipset you will be pleased to hear that the setting 'agp_try_unsupported=1' works in very many cases. I've successfully tried Intel's i815 and i820 chipset, as well as VIA's Apollo Pro133A, Apollo KX133 and Apollo KT133. To make sure that this setting will always be applied when the driver needs to load, you want to modify '/etc/modules.conf'. It should contain the line 'alias char-major-10-175 agpgart'. Include the line 'options agpgart agp_try_unsupported=1' underneath and your AGP driver will load without problems if you've got one of the above-mentioned 'unsupported' chipsets.
There are two options for NVIDIA's driver that you might want to include in 'modules.conf' as well. I found that the i815 chipset requires the setting 'NVreg_UseKernelAGP=1' if you want AGP to be enabled properly. Owners of motherboards with VIA's Apollo Pro133A chipset might want to try 'NVreg_EnableVia4x=1' to enable AGP4x mode. To enable those features permanently find the line 'alias char-major-195 NVdriver' and put the line 'options NVdriver NVreg_UseKernelAGP=1 NVreg_EnableVia4x'. There's additionally the two options 'NVreg_ReqAGPSBA=0/1' (default 1) to toggle AGP side band addressing and 'NVreg_ReqAGPFW=0/1' to toggle Fast Writes. So far so good.
Step Three - Install The XFree/glx Driver
Download either the correct RPM for your system or the source code file. In case of XFree 4.0.1 you will require the source code file by all means, since NVIDIA doesn't supply a RPM for the XFree 4.0.1 driver. The procedure is super easy with the source code file, so there's no reason not to use it. After the download unpack the file in a directory of your choice.
Before you 'make' the driver you need to check a few things. You need to remove or rename several of the possibly installed Mesa files that interfere with NVIDIA's OpenGL driver:
- /usr/X11R6/lib/modules/extensions/libGLcore.a
- /usr/X11R6/lib/modules/extensions/libglx.a
- /usr/lib/libGL.so
- /usr/X11R6/lib/libGL.so.*
- /usr/X11R6/lib/libGLcore.so.*
After you've done that type 'make' and almost all things should be taken care of. In my case there was one problem with the file '/usr/lib/libGL.so.1', being a symbolic link to a Mesa file, although I had renamed it earlier. Best you change the symbolic link to the newly installed NVIDIA OpenGL driver file '/usr/lib/libGL.so.1.0.4' and you should be set.
If you can find any 'libMesaGL.so.*' or 'libMesa.so.*' files in 'usr/lib' or 'usr/X11R6/lib' make symbolic links out of them, pointing to the NVIDIA OpenGL driver file '/usr/lib/libGL.so.1.0.4'.
Finally, you want to modify '/etc/X11/XF86Config '. Replace the line 'Driver "nv" ' in the 'Section "Device" ' to 'Driver "nvidia" '. If it's not already in there, please add 'Load "glx" ' in the 'Section "Module" ', to enable 3D!
Now start Xserver (type 'startx') and you should happily have your desktop back. If you've got 'ssystem', the Star System Simulator installed, open a console and type 'ssystem -bench'. Ssystem should load and you should see a high frame rate. A GeForce2 GTS on an Athlon/Tbird 1000 system scores about 380 fps. If you only see 5-10 fps you have probably forgotten to remove or rename one of the Mesa files or you forgot to make the symbolic links from the Mesa files. Check it again, particularly the symbolic links.
Testing
This is my first major Linux testing, so I hope I got it right for the Linux community out there. I decided to run all the different NVIDIA cards in my lab on one platform and all platforms in my lab with one 3D card. It turned out to be convenient to use my good old and rarely used i820 motherboard, the Asus P3C-L as basic platform for all the cards. I chose the GeForce2 GTS card for the platform tests .
As benchmarks I used the Linux version of Quake 3 Arena, running good old demo001. Then I installed the brand new SPECviewperf 6.1.2 and ran that too. Additionally I did the tiny little Ssystem benchmark too.
For comparison I ran Quake3 and SPECviewperf 6.1.2 under Windows98 on all the cards too. You know that the scores under Windows2000 aren't any better, rather worse.
Problems
Yes, I encountered a couple of problems too.
- Problem No.1 was the fact that my GeForce MX card didn't want to work under Xserver. As soon as Xserver started the screen went black and the system froze completely. I am already working with NVIDIA to find the cause of this failure.
- The second problem was completely crazy. On my VIA Apollo Pro133A platform, the Asus P3V4X, SPECviewperf would simply stop in the middle of an animation and only get back to work as soon as I moved the mouse a bit. So far nobody could explain that to me, but it kept me from generating any SPECviewperf scores with the P3V4X.
- The third and last problem was with my Intel OR840 motherboard, which is based on the i840 chipset. Linux preferred to give me a consistent kernel panic at boot up with several different kernels, so I didn't test this platform.
NVIDIA as well as Asus are aware of the problems and I am working with them to find an urgent fix.
