Yes, sure.

First, keep in mind that I am a sysadmin, I don't know a thing about graphic programming.

It all began, fortunately, as we have one RHEL 6 virtual machine, and a RHEL 6 physical machine with an NVidia card. So, strangely, this software worked perfectly in the virtual machine, not only with the display in X2go, but on the console too ! The ESX does NOT have an NVidia card, it is a basic display for servers ! I would not have expected this ? So I began digging, using strace on my machines, reading your pages, searching with Google. An interesting test was the following : I initiated an X2go connection on the virtual machine, then from a terminal in this connection, I connected to the virtual machine through ssh -X : and from within this connection, I started the software on the vm, but with its display redirected on the X2go display of the physical machine : and it worked perfectly : this meant that the graphic driver on the machine where the software is run is not involved at all ! it would have to be some specific library involved in OpenGL.

Then I figured out that on the VM alone, the software uses the stock "mesa" libGL.so. I found on some page on the web that a good test to see which libGL.so was used was to run

ldd /usr/bin/glxinfo

Then I looked at the postinstall script of the NVidia driver provided by ELrepo : I saw ldconfig ! This is how the NVidia libGL.so is provided to OpenGl applications !

And I must have seen somewhere else the tip about LD_LIBRARY_PATH : which worked perfectly with

ldd /usr/bin/glxinfo

But my software was still failing : why ? Actually, this software is complex, it starts opening a graphic console, from which the real utilities are started : this console is buggy, it does not provide the user's environment to the utilities it starts : this is what got me confused in a first time, I did not know it was buggy, I had to figure it out : so I dug deeper, found the utilities' rc file, figured out how to change LD_LIBRARY_PATH inside the rc file, and I was done !

So to us, the fix is "just" to add at the beginning of LD_LIBRARY_PATH : /usr/lib64, so that it is libGL.so from mesa-libGL-devel which is used for the OpenGL calls, and not the NVidia one, which is registered in the OS by ldconfig. And then, fix the other bugs which get in the way ;-)

I hope I have been clear enough ?

Robert Grasso | System engineer T +33 (0)4 56 38 08 33 | F +33 (0)4 56 38 08 30

rgrasso@altair.com | www.altair.com Altair | Innovation Intelligence ®

-----Original Message----- From: ulrich.sibiller@gmail.com [mailto:ulrich.sibiller@gmail.com] On Behalf Of Ulrich Sibiller Sent: Monday, March 06, 2017 7:00 PM To: Robert GRASSO Subject: Re: [X2Go-User] High performance OpenGL issues : fixed

On Mon, Mar 6, 2017 at 5:53 PM, Robert GRASSO <rgrasso@altair.com> wrote:

...

Apologies, fix found.

Please dismiss this question

Can you please give us information about the fix? It may help others...

Uli