Yes, qdec apparently works ok without the Nvidia driver libraries.
We want to run tksurfer remotely, so the video card won't really be
used. But apparently we need special functionality that does not exist
in the standard GL libraries.
Purchasing a video card just to get access to the driver libraries - is
this what we need to do?
Or is there a standard, open-source GL library that supports everything
that tksurfer requires?
Thanks,
Brian
Nick Schmansky wrote:
Brian,
Does the 'qdec' application run for you on Centos5?
Our apps do not require any particular graphics card. Through
experience, it seems the Nvidia cards give the least trouble (compared
to ATI), but we have never been able to track down exactly why
(something in the bowels of each manufactures OpenGL/GLX
implementation). I think, but am not positive, that GLX is graphics-
card specific (well I would think OpenGL is too), and tksurfer uses GLX
(although I think there is a way to force software rendering), so I
cannot say how the default Centos5 GL/GLX drivers will behave.
So for the systems that are not working, what graphics card is
installed?
Nick
On Thu, 2008-04-24 at 11:54 -0500, Brian Hanna wrote:
Hi all,
We are having a problem running tksurfer on several Centos 5 machines.
We are getting the dreaded GLXBadLargeRequest and just the front sliver
of the brain displayed. By installing the Nvidia driver manually, we
made it work.
We have one Centos 5 machine where it is working (machine01). That one
machine has an Nvidia card and the Nvidia driver installed.
We find that machine01 runs tksurfer correctly locally, and other
machines can connect to machine01 with VNC and run tksurfer remotely on
machine01. None of the other machines work correctly.
Following up on the Nvidia driver difference, I notice that the Nvidia
driver package includes a number of GL libraries. On the other machines,
standard Centos 5 installs, I see:
$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan 7 14:57 /usr/lib64/libGL.so ->
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan 7 14:57 /usr/lib64/libGL.so.1 ->
libGL.so.1.2
-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan 7 14:57 /usr/lib64/libGLU.so ->
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan 7 14:57 /usr/lib64/libGLU.so.1 ->
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 526048 Nov 10 11:23 /usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 ->
libGL.so.1.2
-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb 3 16:07 /usr/lib/libGLU.so.1 ->
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are
several new libraries installed from Nvidia. That's a new libGL and 10mb
libGLcore, and my standard libGL.so.1.2 has been zapped.
$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root 22 Apr 16 09:21 /usr/lib64/libGLcore.so.1
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 9777704 Apr 16 09:21
/usr/lib64/libGLcore.so.100.14.11
-rw-r--r-- 1 root root 661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root 10 Apr 16 09:21 /usr/lib64/libGL.so ->
libGL.so.1
lrwxrwxrwx 1 root root 18 Apr 16 09:21 /usr/lib64/libGL.so.1 ->
libGL.so.100.14.11
-rwxr-xr-x 1 root root 822960 Apr 16 09:21 /usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root 18 Apr 16 09:21
/usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 26 Apr 16 09:21
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root 127096 Apr 16 09:21
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root 26 Apr 16 09:21
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21
/usr/lib64/libnvidia-tls.so.100.14.11
-r--r--r-- 1 root root 185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root 26 Apr 16 09:21
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root 137944 Apr 16 09:21
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root 22 Apr 16 09:21 /usr/lib/libGLcore.so.1
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21
/usr/lib/libGLcore.so.100.14.11
-rw-r--r-- 1 root root 659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root 10 Apr 16 09:21 /usr/lib/libGL.so ->
libGL.so.1
lrwxrwxrwx 1 root root 18 Apr 16 09:21 /usr/lib/libGL.so.1 ->
libGL.so.100.14.11
-rwxr-xr-x 1 root root 608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 root root 26 Apr 16 09:21
/usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 2352 Apr 16 09:21
/usr/lib/libnvidia-tls.so.100.14.11
For a test, I temporarily copied the libraries and make the appropriate
links on another machine - basically installing the driver manually. I
find that now the entire brain displays and I don't get the
GLXBadLargeRequest.
I suppose I could have installed an Nvidia card and installed the driver
to accomplish the same thing. You can use the -x option to the NVidia
driver package to just extract it without running the installer. Be sure
to check the LICENSE file, sections 2.1.2 and 2.1.3, before deciding how
to proceed with this information.
So the problem lies in functionality available in the Nvidia libGL (etc)
libraries that is not available in the standard Centos 5 libGL. What
GL/GLX libraries do I install on a non-Nvidia machine in order to run
tksurfer? Does tksurfer depend specifically on having Nvidia cards or
other proprietary drivers installed? The wiki states:
A 2GHz or faster processor, at least 2GB of RAM, and a 3D graphics
card (with a GPU and its own graphics memory) with accelerated OpenGL
drivers, is recommended. Freesurfer is highly CPU and memory intensive
(and moderately disk intensive), so concentrate on boosting those
performance aspects (more memory is better). Most modern video
graphics card will perform fine, but be aware that graphics cards that
use CPU memory as video memory will have a noticeably slow redraw rate.
Thanks,
Brian Hanna
CMRR
University of Minnesota
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer