HI Jan,

I'm using NVidia's 2.0.2 NVIDIA 87.62 under Suse 10.0 64 bit.  I run
multi-threaded, multiple-graphics card every day without problems.  I
have Althon64 X2 and 2 7800GTs.

I haven't tried changing drivers at all recently.  The compiler is:

gcc --version
gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)

This doesn't provide you with any real insight I know, but perhaps
it'll give at least one other working point.

Robert.

On 11/7/06, Jan Wurster <[EMAIL PROTECTED]> wrote:
  Hi there,

  as the subject indicates this might be slightly off topic, but maybe
someone out there experiences similar problems ;)

  It seems like everything more recent than the 7676 release of nvidia's
linux drivers crash on me in a multithreaded application environment
(involving OpenSceneGraph for rendering) - but only (!) if binaries are
compiled with gcc 4.x, regardless of architecture (problem exists with
both i386 and amd64 machines, single or multi-cpu). gcc 3.3.x, which I
installed optionally, works, all the time and with all nvidia driver
releases. The OSG release used doesn't matter, I've tried 1.0 to 1.2 - I
also don't think that it is part of the problem at all.

  Within the current beta driver release, there's an 'indirect
rendering' mode which is enabled if the user's X environment can't get
access to /dev/nvidiactrl. All is well in this case.

  The crash occurs as soon as data is shovelled onto the graphics
hardware, it doesn't matter if I configure the OSG to use display lists
or vbos. In a release build, things actually work ok for a while - in a
debug build, the crash occurs always and immediately.

  I'm a bit at a loss at this point. Data that changes the OSG
scenegraph comes in from multiple threads - but synchronized, so no
concurrent access should happen. Window/camera handling and rendering is
actually done in one thread only of course, so OpenGL should be happy.
I've never seen this kind of problem before - Windows platforms work out
fine as well. It definitely has to do with multithreading in a way (also
I don't see the problem) - when I run the application singlethreaded,
everything's fine. But I don't see why the compiler matters!? Since it's
the same system, even the exact same pthread lib gets linked, the only
difference I really see is that gcc-4.x binaries obviously link to
different std-libs.

  Maybe somebody on this list has experienced similar issues?

  Best regards,
-.jan.-


gdb output (doesn't make much sense):

0x00002aaaafa8609b in _nv001206gl () from /usr/lib64/libGLcore.so.1
(gdb) where
#0  0x00002aaaafa8609b in _nv001206gl () from /usr/lib64/libGLcore.so.1
#1  0x00002aaaafa8851c in _nv001206gl () from /usr/lib64/libGLcore.so.1
#2  0x00002aaaafa87985 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#3  0x00002aaaafabb092 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#4  0x00002aaaafae0e61 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#5  0x00002aaaafae0bd9 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#6  0x00002aaaafae0c41 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#7  0x00002aaaafad10f7 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#8  0x00002aaaafad178c in _nv001206gl () from /usr/lib64/libGLcore.so.1
#9  0x00002aaaafad02f0 in _nv001206gl () from /usr/lib64/libGLcore.so.1
#10 0x00002aaaafa8099e in _nv001206gl () from /usr/lib64/libGLcore.so.1
#11 0x00002aaaaf739d6a in _nv000051gl () from /usr/lib64/libGLcore.so.1
#12 0x00002aaaaf6e7656 in _nv001198gl () from /usr/lib64/libGLcore.so.1
#13 0x00002aaaaf6e7175 in _nv001198gl () from /usr/lib64/libGLcore.so.1
[...]
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to