With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally. X prints
out this info:
(II) [GLX]: clip_lock: timed out [5]
If the SDL app is started full screen, there’s no problem (tested with
Chromium B.S.U. and glTron).
This behavior does not occur with GLUT, the Qt GL extension, or with
Q3.
Any ideas?
Cheers,
Mark----------------------------
Mark B. Allan
http://www.reptilelabour.com
“Good people drink good beer”
With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally.
I get the same problem using 1.1.6 and Windows 2000. When opening an
OpenGL application my computer just freezes for up to 10 seconds, then
it works normally. I’ve traced it to the init function for GL, but I’m
not sure where to even start looking for the cause.
CK
I also see this; there’s almost always a 20-30 second delay between starting
an SDL app and the window appearing. The rendering is fully accelerated once
it does appear, though. Other windowed OpenGL apps start immediately, and Q3A
works perfectly. The “clip_lock” message is also present in my
/var/log/XFree86.0.log file after this occurs.
I’ve just upgraded to Xfree86 4.0.2 (completely new /usr/X11R6 tree with the
default libGL libraries removed) and the NVIDIA 0.9-6 drivers. To try and fix
this I’ve done a fresh build of SDL 1.1.7 (previously had 1.1.2), built the
lastest bintools from source, rebuilt the NVIDIA kernel module and rebooted (I
thought it might be an SMP problem), but with no improvement.
I’ll see if I can deduce what SDL does differently to GLUT when opening an
OpenGL window. I’m unsure whether to pester NVIDIA about this yet; it does
seem to only affect SDL apps…
Regards,
David.
Mark B. Allan wrote:> With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally. X prints
out this info:
(II) [GLX]: clip_lock: timed out [5]
If the SDL app is started full screen, there’s no problem (tested with
Chromium B.S.U. and glTron).
This behavior does not occur with GLUT, the Qt GL extension, or with
Q3.
Any ideas?
Cheers,
Mark
It would appear that this is an SMP-related problem.
I build a new kernel using the same configuration as my current kernel except
for disabling SMP, rebooted in single-processor mode, rebuild the NVIDIA
kernel driver, and SDL apps started immediately. Rebooted using the SMP
kernel; 30 second delay when starting SDL apps.
Looking at the NVIDIA driver FAQ, item 6.4.8 “OpenGL and dlopen()” says there
are problems with applications that use dlopen() to load the OpenGL library.
SDL uses this method, whereas GLUT (which works fine) does not. It doesn’t
mention SMP in this item, however, which implies that this can happen on
single-processor machines as well. YMMV, I suppose…
I’ll try to modify a copy of SDL to not use dlopen() and see if it works
around the problem.
David.
David Bateman wrote:>
I also see this; there’s almost always a 20-30 second delay between starting
an SDL app and the window appearing. The rendering is fully accelerated once
it does appear, though. Other windowed OpenGL apps start immediately, and Q3A
works perfectly. The “clip_lock” message is also present in my
/var/log/XFree86.0.log file after this occurs.
I’ve just upgraded to Xfree86 4.0.2 (completely new /usr/X11R6 tree with the
default libGL libraries removed) and the NVIDIA 0.9-6 drivers. To try and fix
this I’ve done a fresh build of SDL 1.1.7 (previously had 1.1.2), built the
lastest bintools from source, rebuilt the NVIDIA kernel module and rebooted (I
thought it might be an SMP problem), but with no improvement.
I’ll see if I can deduce what SDL does differently to GLUT when opening an
OpenGL window. I’m unsure whether to pester NVIDIA about this yet; it does
seem to only affect SDL apps…
Regards,
David.
Mark B. Allan wrote:
With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally. X prints
out this info:
(II) [GLX]: clip_lock: timed out [5]
If the SDL app is started full screen, there’s no problem (tested with
Chromium B.S.U. and glTron).
This behavior does not occur with GLUT, the Qt GL extension, or with
Q3.
Any ideas?
Cheers,
Mark
I built a copy of SDL that doesn’t use dlopen(), but I still get “clip_lock:
timed out [5]” messages. If for some bizarre reason someone wants a patch for
this build, email me and I’ll send you one.
Strangely, after upgrading my window manager this problem only manifests
itself every tenth time or so. This is good enough for me to get on with
some development, so I’ll send a report to NVIDIA and hope their next driver
release fixes things.
David.
David Bateman wrote:>
It would appear that this is an SMP-related problem.
I build a new kernel using the same configuration as my current kernel except
for disabling SMP, rebooted in single-processor mode, rebuild the NVIDIA
kernel driver, and SDL apps started immediately. Rebooted using the SMP
kernel; 30 second delay when starting SDL apps.
Looking at the NVIDIA driver FAQ, item 6.4.8 “OpenGL and dlopen()” says there
are problems with applications that use dlopen() to load the OpenGL library.
SDL uses this method, whereas GLUT (which works fine) does not. It doesn’t
mention SMP in this item, however, which implies that this can happen on
single-processor machines as well. YMMV, I suppose…
I’ll try to modify a copy of SDL to not use dlopen() and see if it works
around the problem.
David.
David Bateman wrote:
I also see this; there’s almost always a 20-30 second delay between starting
an SDL app and the window appearing. The rendering is fully accelerated once
it does appear, though. Other windowed OpenGL apps start immediately, and Q3A
works perfectly. The “clip_lock” message is also present in my
/var/log/XFree86.0.log file after this occurs.
I’ve just upgraded to Xfree86 4.0.2 (completely new /usr/X11R6 tree with the
default libGL libraries removed) and the NVIDIA 0.9-6 drivers. To try and fix
this I’ve done a fresh build of SDL 1.1.7 (previously had 1.1.2), built the
lastest bintools from source, rebuilt the NVIDIA kernel module and rebooted (I
thought it might be an SMP problem), but with no improvement.
I’ll see if I can deduce what SDL does differently to GLUT when opening an
OpenGL window. I’m unsure whether to pester NVIDIA about this yet; it does
seem to only affect SDL apps…
Regards,
David.
Mark B. Allan wrote:
With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally. X prints
out this info:
(II) [GLX]: clip_lock: timed out [5]
If the SDL app is started full screen, there’s no problem (tested with
Chromium B.S.U. and glTron).
This behavior does not occur with GLUT, the Qt GL extension, or with
Q3.
Any ideas?
Cheers,
Mark
David Bateman wrote:
I built a copy of SDL that doesn’t use dlopen(), but I still get “clip_lock:
timed out [5]” messages. If for some bizarre reason someone wants a patch for
this build, email me and I’ll send you one.
Strangely, after upgrading my window manager this problem only manifests
itself every tenth time or so. This is good enough for me to get on with
some development, so I’ll send a report to NVIDIA and hope their next driver
release fixes things.
David.
David Bateman wrote:
It would appear that this is an SMP-related problem.
I build a new kernel using the same configuration as my current kernel except
for disabling SMP, rebooted in single-processor mode, rebuild the NVIDIA
kernel driver, and SDL apps started immediately. Rebooted using the SMP
kernel; 30 second delay when starting SDL apps.
Looking at the NVIDIA driver FAQ, item 6.4.8 “OpenGL and dlopen()” says there
are problems with applications that use dlopen() to load the OpenGL library.
SDL uses this method, whereas GLUT (which works fine) does not. It doesn’t
mention SMP in this item, however, which implies that this can happen on
single-processor machines as well. YMMV, I suppose…
I’ll try to modify a copy of SDL to not use dlopen() and see if it works
around the problem.
David.
David Bateman wrote:
I also see this; there’s almost always a 20-30 second delay between starting
an SDL app and the window appearing. The rendering is fully accelerated once
it does appear, though. Other windowed OpenGL apps start immediately, and Q3A
works perfectly. The “clip_lock” message is also present in my
/var/log/XFree86.0.log file after this occurs.
I’ve just upgraded to Xfree86 4.0.2 (completely new /usr/X11R6 tree with the
default libGL libraries removed) and the NVIDIA 0.9-6 drivers. To try and fix
this I’ve done a fresh build of SDL 1.1.7 (previously had 1.1.2), built the
lastest bintools from source, rebuilt the NVIDIA kernel module and rebooted (I
thought it might be an SMP problem), but with no improvement.
I’ll see if I can deduce what SDL does differently to GLUT when opening an
OpenGL window. I’m unsure whether to pester NVIDIA about this yet; it does
seem to only affect SDL apps…
Regards,
David.
Mark B. Allan wrote:
With SDL 1.1.7 and the latest NVIDIA 0.9.6 drivers, whenever I try to
open a windowed GL context, my machine completely locks for about 5
seconds, then the window opens and the app behaves normally. X prints
out this info:
(II) [GLX]: clip_lock: timed out [5]
If the SDL app is started full screen, there’s no problem (tested with
Chromium B.S.U. and glTron).
This behavior does not occur with GLUT, the Qt GL extension, or with
Q3.
Any ideas?
Cheers,
Mark
It’s really sad that NVidia doesn’t give to opensource community their
cards spec. Because their releases aren’t really great most of the time
and we have to wait so much time between two of them.
I got a Mandrake 7.2 systeme with NVidia 0.9.6 and SDL 1.1.7, and no OGL
works fine (even some little pseudo code i write), all my pc freezes and
i have to reboot !
Crap…
On my Suse 6.4 Xfree 4.0.1 nv 0.9.6 SDL-1.1.6 it works fine, but I guess
I’ll have to check it for 1.1.7 too. Note that I do not link with opengl,
SDL loads dynamically libgl.so and I did not experirence the startup lags
mentioned. Also note that I do not have an SMP although I would love to.