Update - may, 1st 2003

There were two driver releases by nVIDIA in the meantime. 1.0-4349 and 1.0-4363. Right now I'm using 1.0-4363. Again I have no stability issues with it. 1.0-4349 was the same. The slowdowns "introduced" with the 1.0-4191 release are gone by now. Stuff is back to nice speeds again. It still could be faster for sure... we're are never satisfied ;-) The only issues, I sofar found with 1.0-4363, are more of coder-concern. First thing is the still missing support for the OpenGL/GLX-extension GLX_ARB_render_texture. I emailed nVIDIA about it asking when we'll see it being supported by the driver. Andy Ritger of nVIDIA replied promptly and promised that they'll address this issues as fast as they can. Another thing I found can be considered a real bug. When grabbing the main rendering-context with glCopyTexSubImage2D() and the OpenGL window is partly overlapped by another window, glClear()s to the color- and z-buffer don't seem to affect the area which is covered by the overlapping window. See a screenhost of this in action here and here. If you like to test it on your own box, the programs used to reproduce this can be grabbed here. They are quick hacks, but I have reports from some people that have them working on their Linux-machines (e.g. several nVIDIA-based gfx-cards, ATI Radon 9700 Pro). If the contained binaries don't work for you, you can still try to compile them yourself. You'll need development-stuff for OpenGL, GLUT, SDL and SDL_Image. BTW, they should also compile without any change on Windows and MacOS X. I might try to verify this myself later.

Update - march, 7th 2003

This update is much overdue. I am currently using the 1.0-4191 driver release from nVIDIA. Furthermore I have updated my system in the meantime. Take a look below for specs. So what can I say for the usual question about lockups/crashes. Rocksolid this driver/hardware combo is for me. I have xscreensaver 4.08 (using many of the gl-hacks) running all the time, I play tons of UT2003 and foobillard, I model/animate/render away with Realsoft3D, I match-move with Icarus and finally my own OpenGL/Cg-app fx-nx-dx runs flawlessly (well as long as the OpenGL/Cg/driver part is concerned ;) Oh yeah, another thing of interest... 2D slowdown with the 1.0-4191 release. I use Gnome 2.2.0 and I am affected by this slowdown. Here's a little hint that might help to get a bit more reponsiveness back again. Just disable any desktop background image or gradient. Playing around with the acceleration of the XRENDER XFree86-extension doesn't make a difference for me. That's about it.

Update - september, 27th 2002

Right now I am running the system described below and using the driver-version 1.0-3123. Unfortunately I have entered the land of lockups again :/ At least they are occuring only under specific circumstances, which can be avoided. And even if those circumstances are present it doesn't happen very often. Those circumstances are __GL_FSAA_MODE=5 and __GL_DEFAULT_LOG_ANISO=3. The env-var __GL_SYNC_TO_VBLANK isn't touched at all. I think it is set to 0 by default (according to /usr/share/doc/NVIDIA_GLX-1.0/README). When I have __GL_FSAA_MODE=5 and __GL_DEFAULT_LOG_ANISO=3 set in a bash and start some OpenGL-program from that very bash it can happen that the machine locks hard. But this only happens (if it happens) when I exit the started OpenGL-program. During the run-time of the program it does not happen. Don't ask... that's just what I observed sofar. Furthermore I have encountered this only with windowed OpenGL-programs. Not that this makes much sense, since even "full-screen" OpenGL-programs are "windowed" somehow. I have only "tested" this for __GL_FSAA_MODE=5, __GL_DEFAULT_LOG_ANISO=3 and no other combination of these two env-vars. I have better things to do than to try to lockup my machine :)

Update - december, 3rd 2001

After updating my kernel to 2.4.16 and installing the XFree86-driver 1.0-2313 from nVIDIA I checked out that lockup-thing again. This time it works rock-solid with either __GL_SYNC_TO_VBLANK=0 or __GL_SYNC_TO_VBLANK=1. I am not sure what finally lead to this status, but nevertheless I wanted to mention this here.

Introduction to the problem

When I updated the nVIDIA driver from 0.9-769 to 1.0-1251 on my linux-box suddenly all OpenGL apps failed. They stalled/hung/crashed. Using RedHat 7.0 I first thought it was a problem of similar nature like the PAM issue seen on Mandrake-based systems. But this not the case. Using the tool strace I found out that OpenGL-programs get stuck when a call to glXSwapBuffers(), glutSwapBuffers() or SDL_GL_SwapBuffers() occured.
So I said to myself: "Just try out a single-buffered OpenGL-program. See if the same problem surfaces there too." I changed some OpenGL-program of mine to only use glDrawBuffer( GL_FRONT ) and simply ignore any calls to glXSwapBuffers() and the like. Guess what, that worked. Then I wondered why 0.9-769 could use double-buffering and 1.0-1251 seemingly not. I soon remembered an env-var I once read about in some README-file from nVIDIAs driver distribution... "__GL_SYNC_TO_VBLANK". This led to the...

Solution

Very simple... just make sure the env-var __GL_SYNC_TO_VBLANK is set to 0. This is really all that is needed. Somehow 0.9-769 works with both, vblank-sync enabled and disabled. But 1.0-1251 sort of needs an explicit "export __GL_SYNC_VBLANK=0" on my system. I put the line "export __GL_SYNC_TO_VBLANK=0" that into my ~/.bashrc, but you can also put it /etc/bashrc to make it available to all users on your system.

My system (updated on march, 7th 2003)

RedHat Linux 7.2 (or 7.3) running
kernel 2.4.19 on a
Athlon XP 2000+ (~1,6 GHz) (512 MBytes PC266 RAM) plugged into an
Asus A7N8X Deluxe mobo with an
forgot the brand (GeForce4 Ti 4800, 64 MBytes DDR, TV-Out/DVI)
Adaptec AHA 2940
Haupauge WinTV

Output of cat /proc/driver/nvidia/agp/* /proc/driver/nvidia/version /proc/driver/nvidia/cards/0 (updated on march, 7th 2003)

Fast Writes: Supported
SBA: Supported
AGP Rates: 8x 4x
Registers: 0x1f000e1b:0x1f004102
Host Bridge: nVidia (unknown)
Fast Writes: Supported
SBA: Supported
AGP Rates: 8x 4x
Registers: 0x1f00421f:0x00000102
Status: Enabled
Driver: NVIDIA
AGP Rate: 8x
Fast Writes: Disabled
SBA: Disabled
Model: GeForce4 Ti 4200 with AGP8X
IRQ: 11
Video BIOS: 04.28.20.05.01
Card Type: AGP
NVRM version: NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4191 Mon Dec 9 11:49:01 PST 2002
GCC version: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)

Addition(s):

Since I saw some reports (mainly @ #nvidia on irc.openprojects.net and @ www.linuxgames.com) of people still having lockups after having disabled vblank-syncing I wanted to do some kind of stress test on my system here. I opened a bash and entered this:

export __GL_FSAA_MODE=4
gears -fps -delay 0 -planetary -geometry 300x240 &
molecule -fps -delay 0 -no-wander -no-labels -geometry 300x240 &
cage -fps -delay 0 -geometry 300x240 &
sierpinski3d -fps -delay 0 -geometry 300x240 &

With these four xscreensaver GL-hacks running I continued to use my machine as usual... coding with nedit, compiling with gcc, browsing with mozilla, chatting with xchat and listening to mp3s with xmms played back from a nfs-mounted partition. After approximately six hours (5 hours, 56 minutes, 12 seconds) I grew tired of this and stopped the four GL-hacks. No single lockup or else happened. This is of course no very sophisticated large-scale test of stability, but for me more than enough to point out that my system runs rock-solid now. I may repeat this with Q3A and/or UT later.

Mirco "MacSlow" Müller, last change on may, 1th 2003