Menu
▾
▴
Re: [Mesa3d-users] LIBGL_ALWAYS_INDIRECT ignored / glxgears: Error: couldn't get an RGB, Double-buffered visual. [solved or circumvented?]
|
From: Reuti <re...@st...> - 2010-02-21 11:32:03
|
One thing I forgot: the /usr/X11R6/lib64 and /usr/X11R6/lib were empty on the server before. -- Reuti Am 21.02.2010 um 12:29 schrieb Reuti: > Hi all, > > I searched the archive for something related to the subject of this > post. But although I found other users also having this problem on > the Internet, there was nothing related in the archive here. Maybe > this is even the wrong list for this issue, then maybe someone can > please point me to the correct one for further investigation. > > > *** Setup: > > I have a powerful server running Linux with several cores (but > without any sophisticated graphics card, just a minimum **) ), to > which users connect from the offices. On their desks they use a > Linux, Mac OS X and Linux. > > > *** Behavior of failing programs: > > Starting programs via SSH's X11 forwarding which use OpenGL I get > errors like: > > - glxgears: Error: couldn't get an RGB, Double-buffered visual. > - glxinfo: Error: couldn't find RGB GLX visual > - others startup up display only a black screen w/o any content > > Even setting LIBGL_ALWAYS_INDIRECT or LIBGL_ALWAYS_SOFWARE doen't > change anything. > > > *** Behavior of working programs: > > Some applications like GaussView 4 from Gaussian or Maestro from > Schrodinger have a switch -soft, respecitvely -sgi, which enables > them to work in this configuration. Unfortunately not all software we > want to use have such an option. > > > *** Obersavtion between workstation: > > When I try to "emulate" the server by a workstation which has an > Nvidia card installed, and connect to this machine from another > workstation, all is working fine. I can see of course, that in this > case other libraries are used. On the server: > > $ ldd /usr/bin/glxgears > ... > libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f3f8273d000) > ... > libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 > (0x00007f3f8181d000) > libXdamage.so.1 => /usr/lib64/libXdamage.so.1 > (0x00007f3f8161a000) > libXfixes.so.3 => /usr/lib64/libXfixes.so.3 > (0x00007f3f81414000) > libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f3f8120b000) > ... > > But on an "emulated" server on a workstation: > > $ ldd /usr/bin/glxgears > ... > libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 > (0x00007f952cf92000) > ... > libGLcore.so.1 => /usr/X11R6/lib64/libGLcore.so.1 > (0x00007f952b1d6000) > libnvidia-tls.so.1 => /usr/lib64/tls/libnvidia-tls.so.1 > (0x00007f952d286000) > libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f952afc4000) > .... > > > *** Solution. > > Now I found a hint on the Internet *), to copy the files from the > workstation from /usr/X11R6/lib and lib64 to the server machine. I > chose to copy them to /opt/nvidia not to mess up with the default > installation. When I now set LD_LIBRARY_PATH all applications are > running fine (one still listed the old libGL.so and I had to use > LD_PRELOAD for it). > > > *** Question: > > Why is this working? My assumption would be, that the original > libGL.so supplied by openSUSE 11.1 and openSUSE 11.2 (ubuntu karmic > in the link *) ) checks the local graphics card first, before it can > even decide to honor LIBGL_ALWAYS_INDIRECT/SOFTWARE at all. Hence an > error is given to the application and fails. When this behavior is > the same across three dristributions with different versions of > libGL.so (7.2 and 7.5), I would assume that this behavior is intended > - but why? Was is falling back to software rendering silently in > former versions of libGL.so? > > And why is the libGL.so installed with Nvidia working, although there > is no Nvidia card at all in the server? Or is the problem in the X11- > Client libraries, which run on the server? > > > -- Reuti > > *) http://forum.compiz.org/viewtopic.php?f=86&t=12271 > > **) It's a server from SUN with only the graphics card from the ILOM > (Integrated Lights Out Management for remote administration and KVM). > > ---------------------------------------------------------------------- > -------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users |
