Last updated: 9-Jan-2001
2.0 Introduction
2.1 Requirements
2.2 Components
2.3 Package files3.0 The XFree86 X Server
3.1 Acquire the source/binaries
3.2 Installation
3.3 Setup4.0 NVIDIA kernel driver
4.1 Description
4.2 Installation
4.2.1 Default RPM
4.2.2 Build from SRPM
4.2.3 Build from tar file5.0 NVIDIA X/OpenGL (GLX) drivers
5.1 Description
5.2 Installation (02-May-2000)
5.2.1 Install from RPM
5.2.2 Install from tar file (9-Jan-2001)
5.3 Setup6.0 Troubleshooting
6.1 XFree86(30-Aug-2000)
6.2 Kernel driver
6.3 OpenGL (27-Apr-2000)
6.4 Known Bugs (30-Aug-2000)
6.5 Troubleshooting some common applications (30-Aug-2000)7.0 Operating Options(7-Jul-2000)
7.1 X driver
7.2 OpenGL
7.3 Kernel (9-Jan-2001)
7.3.1 PROCFS Support (9-Jan-2001)
7.3.2 AGP Support (9-Jan-2001)
7.3.3 AGP Configuration (9-Jan-2001)
7.3.4 AGP Status via PROCFS (9-Jan-2001)8.0 FAQ (27-Apr-2000)
8.1 Kernel problems (27-Apr-2000)
8.1.1 I can't build the kernel module! There's tons of compile errors! (27-Apr-2000)
8.1.2 I get unresolved refs when I attempt to insmod the kernel module (27-Apr-2000)
8.2 Starting X
8.2.1 X fails to load, and claims there's 0kb of total video memory (27-Apr-2000)
8.3 OpenGL (27-Apr-2000)
8.3.1 OpenGL crashes when I start Quake or other apps (27-Apr-2000)
8.3.2 OpenGL is slow when I run XXX app (27-Apr-2000)9.0 ChangeLog (07-Jun-2000)
The NVIDIA Accelerated Linux Driver Set is the work of three partners: NVIDIA, SGI, and VA Linux Systems.
The NVIDIA Accelerated Linux Driver Set adds improved 2D functionality to the XFree86 X server as well as high performance OpenGL acceleration, AGP support, support for flat panels, support for TwinView, and 2D multiple monitor support (not Xinerama).
Hardware: The NVIDIA Accelerated Linux Driver Set supports the following NVIDIA products: RIVA TNT, RIVA TNT2, RIVA TNT2 (Ultra), RIVA TNT2 (Vanta), RIVA TNT2 (M64), RIVA TNT2 (Integrated), GeForce 256, GeForce DDR, Quadro, GeForce2 MX, GeForce2 MX DDR, GeForce2 Go, GeForce2 MXR, GeForce2 GTS, GeForce2 Ultra, and Quadro2 Pro. The RIVA 128/128ZX chips are supported by the Open Source driver nv available with XFree86, but not by the NVIDIA Accelerated Linux Driver Set.
Software: Linux kernel >= 2.2.12 XFree86 >= 4.0.1
The NVIDIA Accelerated Linux Driver Set is comprised of two major components: a kernel module, and XFree86 modules for 2D and 3D acceleration. The 3D OpenGL acceleration supports both indirect and direct rendering for complete compatibility and performance. The current version of the drivers is 0.9-6.
There are two types of packages supported. The simplest and best supported is the use of RPM packages. For those of you who don't use/like RPMs, gzipped tar files are available as well. If you run the shipping version of RedHat, currently 7, you can simply download the two RPMs that match your hardware configuration. If you have another distribution, you can download the RPMs for the X/OpenGL modules and build your own RPM from an SRPM file. The required downloads will be one of the following pairs:
NVIDIA_GLX-0.9-6.tar.gz and NVIDIA_kernel-0.9-6.tar.gz, or NVIDIA_GLX-0.9-6.src.rpm and NVIDIA_kernel-0.9-6.src.rpm, or NVIDIA_GLX-0.9-6.i386.rpm and one of: NVIDIA_kernel-0.9-6.mdk71.i386.rpm (Mandrake 7.1 uni-processor), or NVIDIA_kernel-0.9-6.mdk71smp.i386.rpm (Mandrake 7.1 multi-processor), or NVIDIA_kernel-0.9-6.rh61.i386.rpm (Red Hat 6.1 uni-processor) or NVIDIA_kernel-0.9-6.rh61.smp.i386.rpm (Red Hat 6.1 multi-processor), or NVIDIA_kernel-0.9-6.rh62.i386.rpm (Red Hat 6.2 uni-processor), or NVIDIA_kernel-0.9-6.rh62.smp.i386.rpm (Red Hat 6.2 multi-processor), or NVIDIA_kernel-0.9-6.rh70-smp.i386.rpm (Red Hat 7.0 multi-processor), or NVIDIA_kernel-0.9-6.rh70-up.i386.rpm (Red Hat 7.0 uni-processor), or NVIDIA_kernel-0.9-6.suse64.i386.rpm (SuSE 6.4 uni-processor), or NVIDIA_kernel-0.9-6.suse64.smp.i386.rpm (SuSE 6.4 multi-processor), or NVIDIA_kernel-0.9-6.suse70.i386.rpm (SuSE 7.0 uni-processor),
The NVIDIA Accelerated Driver Set requires version 4.0.1 or later of the XFree86 X server. To determine the version of your X server, you can check the "vendor release number" value in the output of xdpyinfo.
If your XFree86 X server is older than 4.0.1, you will have to upgrade your X server. Check with your distribution's FTP site for easily installed pre-compiled binaries; RPMs may provide the easiest path for upgrading. Alternatively, you can find pre-compiled binaries at www.xfree86.org or you can compile your own X server from sources available at the same website. Please see the XFree86 documentation for the details of building the X server.
Installation with RPMs is fairly straightforward. Use GnoRPM, Kpackage, or command line rpm to install the RPMs. If using the downloaded binaries from XFree86, use their install script. If you built your own binaries, install with 'make install'. Under all circumstances, you will need to install the files as 'root'.
Difficulties in setting up the XFree86 X server are more often than not related to problems with the configuration file, XF86Config. One technique is to use the program xf86config to generate a basic XF86Config file that can then be tweaked as needed; another approach is to use the -configure option to the XFree86 executable. For additional information, please see the sample XF86Config file included with the NVIDIA Accelerated Driver Set package under the /usr/doc directory structure. When getting started, it is easiest to set up the X server to load the NVIDIA Open Source driver, nv, shipped with XFree86.Note: the Open Source NVIDIA driver available with XFree86 4.0.1 did not support the newer GeForce2 family of NVIDIA cards. This has been resolved in XFree86 4.0.2.
Before proceeding, it is recommended that you have a running X server (XFree86 4.0.1 or later) using the Open Source nv driver. Configuring X to use NVIDIA's officially supported drivers is covered below in section 5.0.
The kernel driver is the NVdriver file. It is tightly coupled to the version and type (SMP vs. non-SMP, 2gig vs non, etc.) of Linux kernel installed on your computer. We hope eventually to provide RPMs for all major Linux distributions. If they are not yet available, it is an easy task to create your own.
Note: this is not the same kernel driver available elsewhere on this website.
The kernel driver is responsible for managing the resources of the NVIDIA graphics accelerator chip. It is a component utilized by all NVIDIA drivers, under different operating systems, that provides a consistent mechanism for hardware initialization, mode set, offscreen memory management, and exception handling. The kernel driver assists the X server module and OpenGL drivers in setup and then steps aside while they render directly to hardware.
Installation always requires that you be logged in as 'root'.
RPMs are available for several Linux distributions for both SMP and uni-processor kernels. Install the correct RPM for your kernel, for example:
rpm -Uvh NVIDIA_kernel-0.9-6.rh62.i386.rpm
or
rpm -Uvh NVIDIA_kernel-0.9-6.rh62.smp.i386.rpm
Building your own custom RPM is quite easy. All that's required is that you have the common build tools installed as well as the correct kernel header files for the kernel on your machine. This is typically the case. To install the buildable files use:
rpm -i NVIDIA_kernel-0.9-6.src.rpm
This will put the buildable files into the default RPM build directory. Something like /usr/src/redhat for RedHat distributions or /usr/src/packages for many others. As 'root', enter this directory and type:
rpm -ba SPECS/NVIDIA_kernel.spec
This will build an RPM for your machine and place the result in RPMS/i386/NVIDIA_kernel-0.9-6.i386.rpm. To install type:
rpm -Uvh RPMS/i386/NVIDIA_kernel-0.9-6.i386.rpm
IMPORTANT note for SMP machines: There is a report that linux kernel spinlocks (which are used by the kernel driver) are not compiled and linked correctly using versions of binutils prior to 2.9.5. Check your binutils version by 'size --version'. Make sure it is at least 2.9.5.
IMPORTANT note for Mandrake users: Under certain installations of Mandrake 7.1, you may not be able to rebuild SRPMS as described above. This is due to an incomplete installation of rpm. To correct this, install the spec-helper RPM from the distribution.
If you think RPMS are for wimps, then you can install from the tar file. Untar the NVIDIA_kernel-0.9-6.tar.gz file and move into the build directory. Simply type 'make' to build the NVdriver kernel module. As 'root', run install.sh to install all the files and modifications. This is automatically done if you install the RPM.
IMPORTANT note for SMP machines: There is a report that linux kernel spinlocks (which are used by the kernel driver) are not compiled and linked correctly using versions of binutils prior to 2.9.5. Check your binutils version by 'size --version'. Make sure it is at least 2.9.5.
The NVIDIA_GLX package contains the NVIDIA XFree86 module, and the OpenGL and GLX drivers.
The XFree86 module, nvidia_drv.o, is similar to the nv_drv.o open source module available with XFree86 but uses the kernel driver and has hooks for interaction with the 3D modules. The 3D modules provide a conformant, direct rendering implementation of OpenGL.This release of the NVIDIA Accelerated Driver Set supports TwinView (only available with certain GeForce2 MX cards) which allows fully accelerated 3D rendering across multiple monitors; please see the TWINVIEW_README file included in the package. Running the X server with 3D acceleration on multiple NVIDIA cards is also supported, though you cannot yet span 3D applications across multiple displays (Xinerama). Specifically, if you don't use Xinerama, both 2D and 3D applications work. If you use Xinerama, only 2D acceleration is operational.
Installation always requires you to be logged in as 'root'.IMPORTANT! This RPM may have some conflicts with some Mesa rpms. Because there are multiple Mesa rpm distributions and there is no standard in naming of the Mesa rpms, libraries, and their location, we are not listing Mesa rpms as incompatible with our rpm. It is your responsibility to remove previously installed Mesa RPMS, or rename Mesa files that conflict with ours. Our rpm, however, will try to notify you that these conflicts exist, on a file-by-file basis.
Specifically, the following files may cause problems:
/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*The installation of the RPM is going to fail if it finds any of the above files, and ask you to rename or remove them. After you've taken care of them, you would have to use the --force option while installing the RPM, because rpm thinks the package is already installed even if the installation failed.
Long-term, this renaming of Mesa files will not be necessary, but for this release, this was the cleanest solution possible. You can verify that the correct XFree86 server modules load by looking at your XFree86.0.log file (typically located in /var/log), and ensuring that the copyright for the glx module is "NVIDIA Corporation".
Using RPMS, install is easy:
rpm -i NVIDIA_GLX_0.9-6.i386.rpm
If you are upgrading from a previous version of the driver, do NOT use the -U option to rpm, since there is a bug in the uninstall section of our older rpms and will remove files that are needed in the current install. Remove the previous rpm using the -e option, and install as above. In detail:
rpm -e NVIDIA_GLX
rpm -i NVIDIA_GLX_0.9-6.i386.rpmAs with Mesa, XFree86 does not have a unique rpm naming convention. Because of that, our rpm may think that you do not have the correct version of XFree installed, even if you do. This will also occur if you couldn't find XFree86 4.0 RPMS and installed binaries or built it from source. To override this dependency, use the --nodeps option of rpm:
rpm -Uvh --nodeps NVIDIA_GLX-0.9-6.i386.rpm
Similarly, for removing the previous rpms using -e option.
Using the tar file simply requires untarring the file, and typing 'make' in the resulting directory. The Makefile will remove conflicting libraries, install the libraries into the correct location for you, then run "ldconfig".
The correct location for each file is:
/usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.1.0.revision /usr/lib/libGL.so.1.0.revision /usr/lib/libGLcore.so.1.0.revisionwhere revision is the revision number of the libraries that exist in the particular distribution.
To use the new XFree86 module, simply modify the Device section of the XF86Config file and replace:Driver "nv"
with
Driver "nvidia"Note: if you have previously installed the GLX module from the 3.3.x version of XFree86, make sure to remove it. Look for glx.so in the /usr/X11R6/lib/modules directory. It will cause conflicts with the new GLX code.
Hopefully your install went without a hitch. However, if something went wrong, the following section may be helpful. If you encounter a problem not listed below, then send us an email at linux-bugs@nvidia.com and we'll see if we can help.
Lots of places can cause problems when upgrading XFree86. Many of the libraries and modules are updated and changed from XFree86 3.3.x that most distributions are shipping. Make sure you have run xf86config to generate a valid XF86Config file. Verify that the X server works properly with the XFree86 nv_drv.o module (unless if you are using a GeForce2 card and the XFree86 driver is version 4.0.1). When performing this verification, make sure the Device section is referencing nv instead of vga or some other driver; you can double check this in the XFree86 log file (usually /var/log/XFree86.0.log). Note that XFree86 3.3.x does not use /var/log/XFree86.0.log as a log file, so if you don't see that file changing, you did not manage to upgrade to XFree 4.0.x.6.1.1 Modelines and monitors
Previous releases sometimes had problems detecting the monitor type, and were therefore unable to set certain resolutions. The current NVIDIA XFree86 driver fully honors Modeline lines that you add to the "Monitor" section of your XF86Config file; see the XF86Config man page and the XFree86-Video-Timings-HOWTO for more on explicitly defining modelines. Note that specifying modelines explicitly can damage your monitor if the monitor was not designed to handle those resolutions or timings. Please be careful.
If you installed the prebuilt RPM, check that you installed the proper type for your kernel -- either SMP or uni-processor. To check that the kernel module is available, type this as 'root':/sbin/insmod NVdriver
The module should load without any problems. If the driver was already loaded, you would get an error message to that effect. Check the driver is loaded by typing:
/sbin/lsmod
One of the drivers listed will be NVdriver if everything is OK. If you got unresolved symbols when loading, you probably have the wrong module type. Try the other type. If you still see unresolved references, it is possible that the kernel you are running does not match the current kernel config as described in /usr/include/linux/autoconfig.h. This would only be true for those of you who are building your own kernel, or for people with multiple kernels installed on their machine.
If the above worked OK, but the X server bails out when starting, make sure the line:
alias char-major-195 NVdriver
exists in /etc/conf.modules or /etc/modules.conf. If the line doesn't exist, you should add it by hand.
If OpenGL apps fail to run because they cannot find libGL.so.1, run/sbin/ldconfig
as 'root'.
If OpenGL apps fail to run because they claim the GLX extension isn't supported, then you may not have the GLX extension loaded. First look at the output of xdpyinfo and look for GLX in the list of supported extensions.
If GLX is not listed make sure the XF86Config file has a glx listed in the modules section:
Section "Module"
...
# This loads the GLX module
Load "glx"EndSection
If GLX apps still don't run, check /var/log/XFree86.0.log to see why the GLX extension did not get loaded.
If OpenGL apps run, but are extremely slow, check for other libGL.so's lurking about the system. Many distributions include a free clone of OpenGL called Mesa. Most apps are built using the Mesa libs and search for libMesaGL.so or libMesa.so. If you want to accelerate these apps, you will need to make a symlink from the Mesa libs to /usr/lib/libGL.so.*. Look for libMesaGL.so.* or libMesa.so.* in /usr/lib or /usr/X11R6/lib. You must then delete or rename libMesaGL.so.3.0 (or whatever version is installed). To make a symbolic link to the accelerated libGL, type:
ln -s /usr/lib/libGL.so.1 libMesa.so.3.0
Use whichever version of the Mesa library you just renamed or deleted as the above target (libMesaGL.so.3.0 in this case).
In addition, the XFree86 4.0 tree includes a libGL.so.1.2 in /usr/X11R6/lib, which is also part of Mesa. You can clean that out with the commands:
mv /usr/X11R6/lib/libGL.so.1.2 /usr/X11R6/lib/libGL.so.1.2.mesa ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so.1.2A method to verify that an application is linking with the correct NVIDIA OpenGL library is to use the command ldd to list the libraries used by that application. Make sure that the libGL and libGLcore libraries used are the ones installed from NVIDIA.
6.4.1 OpenGL + Indirect Rendering
At present, indirect OpenGL rendering (i.e. app is run from a different X server than where it renders to) is not fully supported. We plan to fix this in the near term.
6.4.2 OpenGL + multiple monitors
Currently, OpenGL works in a multiple monitor configuration, though not with Xinerama.
6.4.3 OpenGL + MesaGL
This installation conflicts with some files provided as part of the base XFree86 4.0 package that deal with MesaGL. In particular, the client libraries libGL.so and libGLcore.so, and XFree86 loadable modules libglx.so all cause potential conflicts with Mesa's libraries. We are working with other OpenGL and OpenGL-compatible library providers to establish a common mechanism by which hardware-specific modules such as those we provide can happily co-exist. Our driver is placing files in the agreed-upon place, but there are still conflicts because XFree 4.0 shipped before this standard was finalized. Please see sections 5.2 and 6.3 for information on resolving these conflicts.
6.4.4 AGP support
This software release does contain support for AGP on many common AGP chipsets. However, not all chipsets are currently supported. If your chipset is not yet supported, let us know what kind of chipset you are using and we will try to add support for it in a future driver release.
Currently internally supported chipsets include: Intel 440LX, 440BX, 440GX, 815, 820, and 840. AMD Irongate, VIA Apollo Pro133, KX133 and KT133. More chipsets may be supported through the use of AGPGART.
There are known problems with some Irongate chipsets and Dual CPU BX systems that require disabling of AGP (see next section). If you experience problems with any other AGP chipsets that go away when disabling AGP, please let us know.
6.4.5 X locks up when starting
The most common cause of X locking up on start-up at this point appears to be AGP. Although we have worked hard to provide quality AGP support, problems might still exist due to the amount of variance in motherboards and AGP chipsets. For this reason, we've included an override in the XFree86 Configuration file. The following addition to your XF86Config file will disable AGP:
# your pre-existing screen section Section "Screen" ... # adding this option disables AGP. # a "1" will enable AGP (the default) Option "NvAgp" "0" ... EndSectionTNT Cards
We have gotten some reports that the X Server locks up when starting with some TNT cards. This appears to be due to a wrong bios loaded on the card by the manufacturer. We are working on a more transparent fix for the problem, but in the meantime have provided a user workaround. Please read the file TNT_USERS_README for more information, included in the NVIDIA_GLX package (the NVIDIA_GLX RPM will install the file in /usr/doc/NVIDIA_GLX/).TNT2 M64 Cards
We have also received reports from some users that the X server locks up when starting up, on some TNT2 M64 cards. We are working on a more transparent fix for this problem, but have provided a user workaround for the meantime. Please read the file M64_USERS_README for more information, included in the NVIDIA_GLX package (the NVIDIA_GLX RPM will install the file in /usr/doc/NVIDIA_GLX/).Low Memory
In addition, on systems with 32MB of RAM, it is possible to fail initialization due to some RAM requirements of our kernel-loadable module. If X fails to start up, sometimes it is sufficient to just try running it again. We recommend installing more RAM in your system for better performance, especially when running 3D (OpenGL).6.4.6 Corruption at very high resolutions
Late in the process of testing our driver, we found that it is possible to see some image corruption if your physical screen size is set to 1600x1200. We will fix this in the very near term.
6.4.7 OpenGL + SMP
Some of our internal testing has revealed random lockups on SMP systems when running OpenGL. We are unsure of the exact cause of this, but we will find it and fix it for our next driver release.
6.4.8 OpenGL and dlopen()
The current thought is that there are some bugs in the glibc dynamic library loading and libdl.so that cause problems with apps that use dlopen() to load the OpenGL library. Apps that use dlopen() include Quake3 and the Quake3 level editor Radiant.
A workaround has been implemented for Quake3.
6.4.9 Buffers not getting freed
There are video memory leaks when a window gets destroyed, but the process is not terminated. If you have lots of OpenGL windows created and destoyed, this may cause your process to die. The amount of memory leaked is proportional to the size of the window at the time it got destroyed.
While this section should not be referred to in place of the documentation already provided with your applications, it can help you out with getting these apps going with our new drivers. For any further setup or runtime issues, you should contact the application publisher for technical support.
6.5.1 Quake3
Quake3 should work well out of the box. A fix has been made to our driver which was causing the crashes when vid_restart was called (i.e. changing any graphics settings).
6.5.2 Quake2
Quake2 requires some minor setup to get it going. First, in the Quake2 directory, the install creates a sym link called libGL.so that points at libMesaGL.so. This symlink should be removed or renamed. Then, to run Quake2 in OpenGL mode, you would type:
quake2 +set vid_ref glx +set gl_driver libGL.so
Quake2 does not seem to support any kind of full-screen mode, but you can run your X server at whatever resolution Quake2 runs at to emulate full-screen mode.6.5.3 Heretic II
Heretic II also installs, by default, a symlink called libGL.so in the application directory. You can remove or rename this sym link, since the system will then find the default libGL.so (which our drivers install in /usr/lib). From within Heretic II you can then set your render mode to OpenGL in the video menu.
There is also a patch available to Heretic II from lokigames at:
http://www.lokigames.com/products/heretic2/updates.php36.5.4 Blender
We have heard several reports of Blender not working properly when you render the scene. We are currently looking into this and hope to have a fix shortly.
6.5.5 Heavy Gear 2
Heavy Gear 2 currently crashes when it changes screen resolutions. This, unfortunately, makes the game unplayable, because the crashes occur when switching between a level and save-game mode, or one level and the next. We are working on this problem and hope to have it fixed soon.
6.5.6 Misc
There are several 3D applications available for Linux today, which have statically linked in the MesaGL 3D library. As such, these applications can not run with accelerated 3D until the authors of the apps update their source to use a dynamic link to libGL.so.
NVIDIA has contacted the authors of these applications and asked them to make this change.
This section describes options that affect the operation of the drivers.7.1 X driver
The parameters for the X drivers are described in the Screen section of the XF86Config file. They contain settings that affect operating parameters of the NVIDIA X driver.
SWcursor This boolean option, when set to "TRUE", forces use of the software cursor, rather than the default hardware cursor. HWcursor This boolean option, when set to "TRUE", forces use of the hardware cursor; this is the default. NoAccel This boolean option, when set to "TRUE", disables use of the XAA module for accelerated 2D graphics; note that this is separate from accelerated 3D graphics. ShadowFB This boolean option, when set to "TRUE", enables use of a Shadow framebuffer. Rotate This option takes one of two possible values: "CW" or "CCW" (clockwise and counter clockwise, respectively); use of this option rotates the screen 90 degress in the specified direction. Note that use of this option disables XAA acceleration and the hardware cursor. NvAGP Use this to configure AGP support. Argument is an integer:
- 0 : disable agp
- 1 : [default] use NVIDIA's internal AGP support, if possible
- 2 : use AGPGART, if possible
- 3 : use any agp support (try AGPGART, then NVIDIA's AGP)
IgnoreEDID Use this to ignore monitor EDID values. EDID is the interface that monitors use to communicate their capabilities. Some monitors are known to lie about their own capabilities. Ignoring the values that the monitor gives back to the video card may improve your changes. On the other hand, this may prove dangerous to your monitor. ConnectedMonitor This option allows you to override what the NVIDIA kernel module detects is connected to your video card. This may be useful, for example, if you use a KVM (keyboard, video, mouse) switch and you are switched away when X is started. In such a situation, the NVIDIA kernel module can't detect what display devices are connected, and the NVIDIA X driver assumes you have a single CRT connected. If, however, you use a digital flatpanel instead of a CRT, use this option to explicitly tell the NVIDIA X driver what is connected. Valid values for this option are "CRT" (cathode ray tube) or "DFP" (digital flatpanel); if using TwinView (please the file README_TWINVIEW), this option may be a comma-separated list of display devices; e.g.: "CRT, CRT" or "CRT, DFP". TwinView This boolean option, when set to "TRUE" enables TwinView. Please see the file README_TWINVIEW for details. TwinViewOrientation This option controls the relationship between the two display devices when using TwinView. It takes one of the following values: "RightOf" "LeftOf" "Above" "Below" "Clone". Please see the file README_TWINVIEW for details. SecondMonitorHorizSync This option is like the HorizSync option in the Monitor section, but is for the second monitor when using TwinView. Please see the file README_TWINVIEW for details. SecondMonitorVertRefresh This option is like the VertRefresh option in the Monitor section, but is for the second monitor when using TwinView. Please see the file README_TWINVIEW for details. MetaModes This option describes the combination of modes to use on each monitor when using TwinView. Please see the file README_TWINVIEW for details. 7.2 OpenGL
OpenGL options are set in the form of environment variables before you start your program.The following ones are recognized:
__GL_SYNC_TO_VBLANK Setting this to a non-zero value will force glXSwapBuffers to sync to your monitor's vertical refresh rate (perform the swap only during the vertical blanking period). __GL_ENABLE_FSAA Setting this to a non-zero value will enable full scene antialising. Note that since this is an environment variable, it can be set on a per-process basis. __GL_FSAA_QUALITY This can be either 0, 1 or 2. 0 means 1.5x1.5 oversampling. 1 means 2x2 oversampling with a texture lod bias. 2 means 2x2 oversampling with no texture lod bias. Note that this variable only makes sense when __GL_ENABLE_FSAA is set. 7.3 Kernel
7.3.1 PROCFS Support
Support for obtaining run-time status and information was submitted by a user and added to the driver. This includes such information as which graphics card is detected, what IRQ is used, and AGP information (see below). This information is in the /proc/nv directory, where a file exists for each nvidia card found in your system: card0 ... card#
This information can be obtained by a command similar to this in any shell: "cat /proc/nv/card0"7.3.2 AGP Support
AGP is supported through NVIDIA's internal AGP support (NVAGP), as well as through the Linux kernel's internal support (AGPGART). Currently, support for both methods of agp support are compiled into the kernel module (so long as your kernel includes AGPGART and is configured to use it). The driver is capable of picking which agp support to use dynamically when X starts and is configured via the XF86Config file.
7.3.3 AGP Configuration
AGP support is configured through the XF86Config, via the "NvAgp" option. It is basically a two-bit boolean mask of what AGP support methods to attempt using. The first bit is NVAGP, the second bit is AGPGART. If either bit is set, that method of AGP support will be attempted, if neither bit is set, AGP will not be used.
In plain english, if NvAgp is set to "1", NVAGP will be attempted. If NvAgp is set to "2", AGPGART will be attempted. If NvAgp is set to "3", AGPGART will be attempted, and if that fails NVAGP will be attempted. If NvAGP is set to "0", AGP will not be used. An option of "1" or NVAGP is the default.
Note that AGP support is a delicate feature and can have serious negative impact on your system's stability. For this reason, our driver performs many checks to back off on AGP support to maintain system stability, but this is not always guaranteed to work. Switching between NVAGP and AGPGART in a single session is extremely dangerous and not recommended. If you decide to switch between using NVAGP and AGPGART, it is recommended that you reboot between attempts (you may need to modify system scripts to not load AGPGART if you desire to use NVAGP).7.3.4 AGP Status via PROCFS
The current AGP status can be queried via the PROCFS interface. This interface can tell you many things about the AGP status on your system. Some of the details reported include whether AGP is enabled, which AGP driver is being used, what AGP options are supported by your motherboard/graphics card and which AGP options are currently enabled.
This status can be obtained via the command "cat /proc/nv/card0" in any shell.
note that many AGP options are disabled or lowered by the driver to achieve stability. Please do not email NVIDIA with complaints that "fast writes," "sideband" is not enabled, or AGP is dropped to 1x on your machine. All of these settings are faster than a hung machine.
8.1 Kernel problems
8.1.1 I can't build the kernel module! There's tons of compile errors!
So far, this seems to be caused by one of two issues:
- You need to change our kernel Makefile DEFINE= line to include the symbol -D_LOOSE_KERNEL_NAMES
- Have you patched your kernel? If so, the patch may be incomplete. It's really important that the headers be consistent when doing a build, otherwise these kinds of problems can happen.
8.1.2 I get unresolved references when I attempt to insmod the kernel module
This problem comes from having a mis-configured system. The problem is most likely that the currently-running kernel does not match the headers describing it in /usr/include/linux/config.h (which runs through a symlink)
8.2 Starting X
8.2.1 X fails to load, and claims there's 0kb of total video memory
There's several things that can be causing this. First, did you install our kernel module properly? Instructions on installing the kernel module are above, and must be followed closely. To diagnose the problem somewhat, you should see output similar to this:
root@system:# lsmod | grep NV NVdriver0 (autoclean) root@system:# cat /proc/devices | grep nvidia 195 nvidia root@system:# ls -l /dev/nvidia* crw-rw-rw- 1 root root 195, 0 Apr 24 18:46 /dev/nvidia0 crw-rw-rw- 1 root root 195, 1 Apr 24 18:46 /dev/nvidia1 crw-rw-rw- 1 root root 195, 2 Apr 24 18:46 /dev/nvidia2 crw-rw-rw- 1 root root 195, 3 Apr 24 18:46 /dev/nvidia3 crw-rw-rw- 1 root root 195, 255 Apr 24 18:46 /dev/nvidiactl root@system:# cat /proc/pci Note that in this section, many of the numbers will be different than this example, but the important thing is that there's an IRQ assigned to the device. Ideally, nothing else is sharing this IRQ. ... Bus 1, device 0, function 0: VGA compatible controller: NVidia Unknown device (rev 16). Vendor id=10de. Device id=101. Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=248. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xe9000000 [0xe9000000]. Prefetchable 32 bit memory at 0xf0000000 [0xf0000008]. ... If any of these commands return no output, or an error, then you should re-run our kernel module's install.sh and watch closely for errors.
If all of this seems correct, then it's possible you're hitting a problem that we've been getting reports of from users. If you would like, you can send us email with details of your system (RAM, CPU, motherboard, graphics card (maker + model), kernel, etc.) and details of the problem you see at linux-bugs@nvidia.com and we will try to help. This is a TOP priority for us right now, we hope to have it resolved soon.
8.3 OpenGL
8.3.1 OpenGL crashes when I start Quake or other apps
The most common cause of this is that some remnants of MesaGL are still left on your system. You should refer to section 6.5.3 in Known Bugs, above, for details on how to resolve this conflict.
8.3.2 OpenGL is slow when I run XXX app
This also seems to be caused by having conflicts between MesaGL components, and our OpenGL components. You can refer to section 6.5.3 in Known Bugs, above, for details on how to resolve this conflict.