My resident programming expert and fluid dynamicist and I have wrestling with a graphics driver issue on CentOS6. As he said this morning this seems to be "pretty deep in the weeds". WE have many CentOS6 systems running the elrepo nvidia kmod packages. All have some sort of hardware rendering capability. But the systems I added to our computational cluster that had to have the X11/Gnome layer added after initial installation seem to refuse to load the nvidia gl libraries. So all the apps show nothing about nvidia when you ldd them. And the Nvidia control panel says direct rendering = No. We have looked at differences in the prelink stuff, and in /etc/ld.so.*. If you brute force by adding the nvidia libs in your LD env path it will work at least partially, but that isn't necessary at all on the vanilla Gnome systems. Looking at the Xorg logs the nvidia glcore stuff appears to be loading. Most apps complain that swrast failed to load unless you have the LD env path added.

I'm hoping someone has some better ideas.

did you install mesa ?
for a complete list of mesa options see
nvidia only installs ONE lib libGL.so.340.93 ( this is for my OLDER nvidia card )
the current is libGL.so.352.41
this is then linked to libGL.so.352.41 > libGL.so

mesa is what cent uses
mesa has it's OWN libGL.so
and mesa is what the cent rpms use




and have you read through the redhat docs
cent moved to using the docs on the redhat web site

now the wiki dose have some info - mostly for centos5 and some 6
https://wiki.centos.org/





also there has been a on going issue with the FIRST time that the proprietary nvidia driver is installed

cent ships with the Nouveau driver installed by default

now using yum to install the kmod should ??? do all the correct work of uninstalling nouveau and switching to the nvidia driver

-- but not always

normally doing this should be all that is needed
this will grab
gcc
autotools
x11 and x11-devel
the kernel source
and a few other things

and install the nvidia driver ( replacing the Nouveau driver)

but there can be a "glitch " with the boot image still having nouveau still used

if that happens
make sure that there is a "blacklist" for the nouveau

add " blacklist=nouveau " to the booting kernel line ( custom boot by hitting the "e" key )
and rebuild the boot image


normally this glitch is from using the nvidia.run driver from the nvidia website and NOT from the "Akmod-nvidia "

Yes to mesa. And yes I verified no nouveau crap is lingering.

It's appearing that the cluster manager overlay (rocksclusters.org) has sprinkled extra /lib, /usr/lib, /lib64 and /usr/lib64 entries all over the place in ld.so.*. This seems to have caused all sorts of havoc. When I took all the extra garbage out the nvidia stuff suddenly appears in something like /usr/bin/glxgears. And the swrast errors running apps displayed remotely have also stopped. The Nvidia control panel also reports direct rendering = yes.

[aammoorcro@hyperion ~]# ldd /share/apps/GridgenV15/linux_x86_64/bin/gridgen
linux-vdso.so.1 => (0x00007fffe063d000)
libtk8.3.so => not found
libtcl8.3.so => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003814800000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003815800000)
libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00002ad61a81a000)
libXaw.so.7 => /usr/lib64/libXaw.so.7 (0x0000003815400000)
libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x00002ad61ab66000)
libXt.so.6 => /usr/lib64/libXt.so.6 (0x000000381e800000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003820400000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003820000000)
libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x000000381ec00000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003818800000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003818000000)
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002ad61ad83000)
libm.so.6 => /lib64/libm.so.6 (0x0000003815000000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ad61afa4000)
libc.so.6 => /lib64/libc.so.6 (0x0000003814400000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003814c00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003814000000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003820800000)
libnvidia-tls.so.340.93 => /usr/lib64/nvidia/tls/libnvidia-tls.so.340.93 (0x00002ad61b1bb000)
libnvidia-glcore.so.340.93 => /usr/lib64/nvidia/libnvidia-glcore.so.340.93 (0x00002ad61b3bf000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x000000381a400000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003817800000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003817c00000)

this might be the lib mis-match

some software is very picky
if it was built using the NVIDIA "gl.h" and the NVIDIA gl.so
it might NOT!!! run if the MESA gl.so is used
and visa versa

if the software was built using the MESA libGL.so and the MESA gl.h
it might NOT run using the NVIDIA gl.so


see the problem

this is why i reinstall mesa after i install the nvidia driver

cent/rhel/sl use mesa as the default


now i use the nvidia.run ( old habit from fedora(4 to 12) and cent 5 days

the kmod-nvidia would most of the time be 3 to 5 days behind the kernel update
this would leave a text only boot for a few days or revert to the old kernel to the kmod was release
-- a real pain --

so
try forcing a reinstall of all of the installed mesa
then see what happens

1 members found this post helpful.

I appreciate all the info. At the moment taking all of the extra duplicate entries out of /etc/ls.so.* seems to have completely resolved the issues. Time will tell if we are really getting full performance from the GPU in Tecplot, Gridgen, Pointwise... etc.

FWIW nvidia proprietary driver does not use mesa. The box I'm typing it right now has nVidia blob, hardware acceleration works, no mesa installed.

Yeah, actually the whole point of having a good Nvidia chip and drivers is to avoid mesa "software" rendering. The first thing you do with a lot of the commercial apps that refuse to work with NVidia hardware acceleration is use the "-mesa" switch. That way their tech support can worm out of helping you get hardware acceleration working. Voice of experience. And more and more companies are refusing to support remote display hardware acceleration.