libGL error: failed to load driver: swrast

[Angel de Vicente]

Hi,

I'm trying to configure VirtualGL to be able to use visualization software remotely, and it more or less works, but I'm not sure things are perfectly configured, so I'm hoping someone here can give me some guidance.

The setting is as follows: 

Remote machine (deim)

------------------------

Fedora 4.13.11-200.fc26.x86_64

GPU: NVIDIA Corporation GP100GL [Tesla P100 PCIe 12GB] (rev a1)

VirtualGL.x86_64                        2.4-8.fc26 

Workstation (com)

-----------------

ArchLinux with virtualgl 2.5.2-2 installed

Let's try to run glxgears remotely. As you can see below all seems OK (and I can see the glxgears turning, but should I worry about that libGL errors? (I understand that swrast is for software rendering, so perhaps I don't care if it cannot be loaded, but I'm not sure about this.

Any help/pointers appreciated.

Ángel de Vicente

[angelv@com ~]$ vglconnect angelv@deim

VirtualGL Client 64-bit v2.5.2 (Build 20170313)

vglclient is already running on this X display and accepting unencrypted

   connections on port 4242.

Enter passphrase for key '/home/angelv/.ssh/id_rsa': 

[...]

[angelv@deim ~]$ 

[angelv@deim ~]$ vglrun +v -cl com glxgears

[VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

[VGL] Shared memory segment ID for vglconfig: 28901376

[VGL] VirtualGL v2.4 64-bit (Build 20170210)

[VGL] Opening connection to 3D X server :0

[VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with dlopen("libdlfaker.so")

libGL error: No matching fbConfigs or visuals found

libGL error: failed to load driver: swrast

[VGL] Using Pbuffers for rendering

[VGL] Using 1 / 20 CPU's for compression

[VGL] Using pixel buffer objects for readback (BGR --> BGR)

[VGL] Client version: 2.1

23345 frames in 5.0 seconds = 4668.886 FPS

23947 frames in 5.0 seconds = 4789.379 FPS

24045 frames in 5.0 seconds = 4808.887 FPS

[DRC]

Yes, you should worry about that swrast error, because that means Mesa's
libGL is being loaded into the OpenGL application, not nVidia's. Look
under /usr/lib64 and make sure libGL.so.1 is pointing to libGL.so.1.0.0,
which it should be if the nVidia drivers are properly installed. Also,
use /opt/VirtualGL/bin/glxspheres64 as a test, not GLXgears. GLXgears
is not a useful benchmark. Also, GLXspheres will display the OpenGL
renderer, which you can use to verify whether the nVidia drivers are
working properly.

> --
> You received this message because you are subscribed to the Google
> Groups "VirtualGL User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to virtualgl-use...@googlegroups.com
> <mailto:virtualgl-use...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/virtualgl-users/ae336b4d-cf77-4b7b-9d40-5e4f43678173%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/ae336b4d-cf77-4b7b-9d40-5e4f43678173%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Angel de Vicente]

Hi,

El miércoles, 15 de noviembre de 2017, 18:20:03 (UTC), DRC escribió:

Yes, you should worry about that swrast error, because that means Mesa's
libGL is being loaded into the OpenGL application, not nVidia's.  Look
under /usr/lib64 and make sure libGL.so.1 is pointing to libGL.so.1.0.0,
which it should be if the nVidia drivers are properly installed.  Also,
use /opt/VirtualGL/bin/glxspheres64 as a test, not GLXgears.  GLXgears
is not a useful benchmark.  Also, GLXspheres will display the OpenGL
renderer, which you can use to verify whether the nVidia drivers are
working properly.

thanks for the help. /usr/lib64 seems OK:

[root@deim lib64]# ls -ltr libGL*

-rwxr-xr-x. 1 root root  589824 Feb 10  2017 libGLEW.so.2.0.0

lrwxrwxrwx. 1 root root      16 Feb 10  2017 libGLEW.so.2.0 -> libGLEW.so.2.0.0

-rwxr-xr-x. 1 root root  445816 Feb 11  2017 libGLU.so.1.3.1

lrwxrwxrwx. 1 root root      15 Feb 11  2017 libGLU.so.1 -> libGLU.so.1.3.1

lrwxrwxrwx. 1 root root      15 Feb 11  2017 libGLU.so -> libGLU.so.1.3.1

lrwxrwxrwx. 1 root root      22 Aug 23 10:46 libGLdispatch.so.0 -> libGLdispatch.so.0.0.0

lrwxrwxrwx. 1 root root      22 Aug 23 10:46 libGLdispatch.so -> libGLdispatch.so.0.0.0

lrwxrwxrwx. 1 root root      15 Aug 23 10:46 libGLX.so.0 -> libGLX.so.0.0.0

lrwxrwxrwx. 1 root root      15 Aug 23 10:46 libGLX.so -> libGLX.so.0.0.0

lrwxrwxrwx. 1 root root      14 Aug 23 10:46 libGL.so.1 -> libGL.so.1.0.0

lrwxrwxrwx. 1 root root      14 Aug 23 10:46 libGL.so -> libGL.so.1.0.0

lrwxrwxrwx. 1 root root      18 Aug 23 10:46 libGLESv2.so.2 -> libGLESv2.so.2.0.0

lrwxrwxrwx. 1 root root      18 Aug 23 10:46 libGLESv2.so -> libGLESv2.so.2.0.0

lrwxrwxrwx. 1 root root      21 Aug 23 10:46 libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.0.0

lrwxrwxrwx. 1 root root      21 Aug 23 10:46 libGLESv1_CM.so -> libGLESv1_CM.so.1.0.0

-rwxr-xr-x. 1 root root   74216 Aug 23 10:46 libGLX.so.0.0.0

-rwxr-xr-x. 1 root root  581768 Aug 23 10:46 libGL.so.1.0.0

-rwxr-xr-x. 1 root root   78888 Aug 23 10:46 libGLESv2.so.2.0.0

-rwxr-xr-x. 1 root root   45312 Aug 23 10:46 libGLESv1_CM.so.1.0.0

-rwxr-xr-x. 1 root root  640736 Aug 23 10:46 libGLdispatch.so.0.0.0

-rwxr-xr-x  1 root root 1291224 Sep  2 09:14 libGLX_nvidia.so.384.81

lrwxrwxrwx  1 root root      23 Sep  2 10:44 libGLX_nvidia.so.0 -> libGLX_nvidia.so.384.81

lrwxrwxrwx  1 root root      27 Sep  2 10:44 libGLX_indirect.so.0 -> /usr/lib64/libGLX_mesa.so.0

lrwxrwxrwx  1 root root      26 Sep  2 10:44 libGLESv2_nvidia.so.2 -> libGLESv2_nvidia.so.384.81

lrwxrwxrwx  1 root root      29 Sep  2 10:44 libGLESv1_CM_nvidia.so.1 -> libGLESv1_CM_nvidia.so.384.81

-rwxr-xr-x  1 root root   54296 Sep  2 10:46 libGLESv1_CM_nvidia.so.384.81

-rwxr-xr-x  1 root root   86200 Sep  2 10:46 libGLESv2_nvidia.so.384.81

lrwxrwxrwx. 1 root root      20 Oct  3 21:37 libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0

-rwxr-xr-x. 1 root root  487576 Oct  3 21:38 libGLX_mesa.so.0.0.0

 

and running glxspheres64 gives the following, again with the rwrast error:

[angelv@deim ~]$ vglrun +v -cl com glxspheres64

[VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)

[VGL] Shared memory segment ID for vglconfig: 29261824

[VGL] VirtualGL v2.4 64-bit (Build 20170210)

[VGL] Opening connection to 3D X server :0

[VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with dlopen("libdlfaker.so")

libGL error: No matching fbConfigs or visuals found

libGL error: failed to load driver: swrast

Visual ID of window: 0x21

Context is Direct

[VGL] Using Pbuffers for rendering

OpenGL Renderer: Tesla P100-PCIE-12GB/PCIe/SSE2

[VGL] Using 1 / 20 CPU's for compression

[VGL] Using pixel buffer objects for readback (BGR --> BGR)

[VGL] Client version: 2.1

1120.859969 frames/sec - 1250.879726 Mpixels/sec

1146.893768 frames/sec - 1279.933445 Mpixels/sec

1144.531196 frames/sec - 1277.296815 Mpixels/sec

[angelv@deim ~]$

Any pointers?

Many thanks,

AdV

[DRC]

Something just occurred to me. In the remote (vglconnect) shell
session, run glxinfo and look at the server GLX extensions. If
GLX_EXT_libglvnd is among them, then that probably explains why you're
seeing a Mesa error message. When used with the VGL Transport
(vglconnect), VirtualGL makes a few GLX/OpenGL calls to the client-side
X display in order to probe whether it supports quad-buffered stereo.
If the client-side X display supports GLX_EXT_libglvnd, then the libGL
implementation on the Fedora server will use the appropriate GLX
implementation for the X server it's communicating with:
libGLX_nvidia.so.0 when it's communicating with the server-side (3D) X
display and libGLX_mesa.so.0 when it's communicating with the
client-side (2D) X display.

If this hypothesis is correct, then setting VGL_PROBEGLX=0 in the
environment should make the swrast message go away. If so, then that
message truly is innocuous, but you can probably make it go away for
good by installing the Mesa swrast driver (I forget which package
contains that on Fedora.)

If my hypothesis is incorrect, then here are other things to try:

-- Check LD_LIBRARY_PATH and LD_PRELOAD and make sure they aren't
pointing to a directory that contains another libGL DSO.
-- 'vglrun ldd /opt/VirtualGL/bin/glxspheres64' and make sure that it
isn't picking up a non-nVidia libGL DSO somehow.
-- Re-install the nVidia drivers with 32-bit support, if you haven't
already, and install the 32-bit VirtualGL package along with the 64-bit
package.

DRC

> --
> You received this message because you are subscribed to the Google
> Groups "VirtualGL User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to virtualgl-use...@googlegroups.com
> <mailto:virtualgl-use...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/virtualgl-users/b8f7c22a-a144-48b3-a006-ee9d76353346%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/b8f7c22a-a144-48b3-a006-ee9d76353346%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Angel de Vicente]

Hi,

DRC writes:

> Something just occurred to me.  In the remote (vglconnect) shell

> session, run glxinfo and look at the server GLX extensions.  If

> GLX_EXT_libglvnd is among them, then that probably explains why you're

> seeing a Mesa error message.

In order not to get confused, I will call client to my workstation (in

this case called "com") and server to the remote machine where the P100

Nvidia card is (in this case called "deim"), so from my client I do

vglconnect angelv@deim and in deim is where I want to run vglrun -cl

com

This doesn't seem to be the problem. I get this in the client and in the

server:

,----

| [angelv@com ~]$ glxinfo | grep -i glvnd

`----

,----

| [angelv@deim ~]$ vglrun glxinfo | grep -i glvnd

| libGL error: No matching fbConfigs or visuals found

| libGL error: failed to load driver: swrast

| [angelv@deim ~]$

`----

> If this hypothesis is correct, then setting VGL_PROBEGLX=0 in the

> environment should make the swrast message go away.  If so, then that

> message truly is innocuous, but you can probably make it go away for

> good by installing the Mesa swrast driver (I forget which package

> contains that on Fedora.)

I wasn't sure if I had to set VGL_PROBEGLX in the client or the server,

so I tried in both. If set in the client the swrast message doesn't go

away, but if set in the server it does go away:

,----

| [angelv@com ~]$ export VGL_PROBEGLX=0 ; vglconnect angelv@deim

|

| [angelv@deim ~]$ vglrun +v -cl com glxspheres64

| [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

| Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)

| [VGL] Shared memory segment ID for vglconfig: 262146

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| [VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with

| dlopen("libdlfaker.so")

| libGL error: No matching fbConfigs or visuals found

| libGL error: failed to load driver: swrast

`----

,----

| [angelv@com ~]$ vglconnect angelv@deim

|

| [angelv@deim ~]$ setenv VGL_PROBEGLX 0

| [angelv@deim ~]$ vglrun +v -cl com glxspheres64

| [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

| Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)

| [VGL] Shared memory segment ID for vglconfig: 294914

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| [VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with

| dlopen("libdlfaker.so")

| Visual ID of window: 0x21

| Context is Direct

| [VGL] Using Pbuffers for rendering

| OpenGL Renderer: Tesla P100-PCIE-12GB/PCIe/SSE2

| [VGL] Using 1 / 20 CPU's for compression

| [VGL] Using pixel buffer objects for readback (BGR --> BGR)

| [VGL] Client version: 2.1

| 1097.198122 frames/sec - 1224.473105 Mpixels/sec

`----

> If my hypothesis is incorrect, then here are other things to try:

So, at this point I don't know if your hypothesis is correct, incorrect

or both at the same time :-)

> -- Check LD_LIBRARY_PATH and LD_PRELOAD and make sure they aren't

> pointing to a directory that contains another libGL DSO.

> -- 'vglrun ldd /opt/VirtualGL/bin/glxspheres64' and make sure that it

> isn't picking up a non-nVidia libGL DSO somehow.

I unset LD_LIBRARY_PATH and LD_PRELOAD (which was unset in my case), and

I get the same problem with swrast.

,----

| [angelv@deim ~]$ vglrun ldd /usr/bin/glxspheres64

| [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to

| [VGL]    50ce, the IP address of your SSH client.

| linux-vdso.so.1 (0x00007ffc5a8fa000)

| libdlfaker.so => /usr/lib64/VirtualGL/libdlfaker.so (0x0000152579a1d000)

| librrfaker.so => /usr/lib64/VirtualGL/librrfaker.so (0x0000152579794000)

| libGL.so.1 => /usr/lib64/libGL.so.1 (0x0000152579508000)

| libX11.so.6 => /usr/lib64/libX11.so.6 (0x00001525791ca000)

| libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000152578f5d000)

| libm.so.6 => /usr/lib64/libm.so.6 (0x0000152578c47000)

| libc.so.6 => /usr/lib64/libc.so.6 (0x0000152578872000)

| libdl.so.2 => /usr/lib64/libdl.so.2 (0x000015257866e000)

| libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000152578446000)

| libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x000015257822b000)

| libxcb-keysyms.so.1 => /usr/lib64/libxcb-keysyms.so.1

| (0x0000152578028000)

| libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x0000152577e26000)

| libturbojpeg.so.0 => /usr/lib64/libturbojpeg.so.0 (0x0000152577bb3000)

| libXv.so.1 => /usr/lib64/libXv.so.1 (0x00001525779ae000)

| libXext.so.6 => /usr/lib64/libXext.so.6 (0x000015257779c000)

| libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x000015257757d000)

| libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00001525771f4000)

| /lib64/ld-linux-x86-64.so.2 (0x0000152579e27000)

| libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x0000152576fc2000)

| libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x0000152576d0c000)

| libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x0000152576af5000)

| libXau.so.6 => /usr/lib64/libXau.so.6 (0x00001525768f1000)

| [angelv@deim ~]$

`----

What I found is that the file libGL.so.1.0.0 is owned by a libglvnd-glx

package, whih at this point I'm not sure if it is a problem or not.

,----

| root@deim ~]# rpm -qf /usr/lib64/libGL.so.1.0.0

| libglvnd-glx-0.2.999-24.20170818git8d4d03f.fc26.x86_64

|

| [root@deim ~]# rpm -qf /usr/lib64/libGLX_nvidia.so.384.81

| xorg-x11-drv-nvidia-libs-384.81-2.fc25.x86_64

`----

> -- Re-install the nVidia drivers with 32-bit support, if you haven't

> already, and install the 32-bit VirtualGL package along with the 64-bit

> package.

Do you think this could solve it even if glxspheres64 is a 64-bits code?

Many thanks for your help,

AdV

[DRC]

On 11/16/17 4:48 AM, Angel de Vicente wrote:
> In order not to get confused, I will call client to my workstation (in
> this case called "com") and server to the remote machine where the P100
> Nvidia card is (in this case called "deim"), so from my client I do
> vglconnect angelv@deim and in deim is where I want to run vglrun -cl
> com

"In the remote shell session" means on the server machine.

> I wasn't sure if I had to set VGL_PROBEGLX in the client or the server,
> so I tried in both. If set in the client the swrast message doesn't go
> away, but if set in the server it does go away:

On the server machine, in the remote shell session.

> | [angelv@com ~]$ vglconnect angelv@deim
> |
> | [angelv@deim ~]$ setenv VGL_PROBEGLX 0
> | [angelv@deim ~]$ vglrun +v -cl com glxspheres64
> | [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH
> | Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
> | [VGL] Shared memory segment ID for vglconfig: 294914
> | [VGL] VirtualGL v2.4 64-bit (Build 20170210)
> | [VGL] Opening connection to 3D X server :0
> | [VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with
> | dlopen("libdlfaker.so")
> | Visual ID of window: 0x21
> | Context is Direct
> | [VGL] Using Pbuffers for rendering
> | OpenGL Renderer: Tesla P100-PCIE-12GB/PCIe/SSE2
> | [VGL] Using 1 / 20 CPU's for compression
> | [VGL] Using pixel buffer objects for readback (BGR --> BGR)
> | [VGL] Client version: 2.1
> | 1097.198122 frames/sec - 1224.473105 Mpixels/sec
> `----
>
>> If my hypothesis is incorrect, then here are other things to try:
>
> So, at this point I don't know if your hypothesis is correct, incorrect
> or both at the same time :-)

It appears that it was correct, although I don't understand why you
aren't seeing GLX_EXT_libglvnd in the glxinfo output. But since setting
VGL_PROBEGLX=0 on the server made the error message go away, clearly
that error message came from libGLX_mesa.so.0, which was being used to
communicate with the 2D (client-side) X display. Perhaps the libglvnd
implementation in Fedora defaults to using Mesa if it can't determine
the appropriate OpenGL vendor for a particular X display.

Long and the short of it: the error is innocuous. Don't worry about
it. You may be able to make it go away permanently by doing `sudo dnf
install mesa-dri-drivers`.

[Angel de Vicente]

Hi again,

DRC writes:

> Long and the short of it:  the error is innocuous.  Don't worry about

> it.  You may be able to make it go away permanently by doing `sudo dnf

> install mesa-dri-drivers`.

OK, so let's forget those errors then (by the way, I do have

mesa-dri-drivers.x86_64 installed).

But I have some other bigger problems now :-(

I have three visualization packages that we would like to use: VisIt,

Mayavi2 and Paraview, and I'm trying them both with vglconnect and with

TurboVNC. And the situations for each package is as follows:

+ VisIt (version 2.12.3)

-------

This behaves apparently OK. Either with (vglconnect / vglrun) or with

(TurboVNC / vglrun) I can start VisIt (2.12.3), can resize windows, open

some files, visualize some data, etc. The only noticeable difference is

that when I start it as (vglconnect / vglrun) I have to specify the name

of the client machine, and I get those innocent swrast messages (which I

don't get when I'm running inside TurboVNC). This is the output when

running in (vglconnect / vglrun):

,----

| [angelv@deim ~]$ vglrun +v -cl com visit

| [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

| Running: gui2.12.3

| [VGL] Shared memory segment ID for vglconfig: 14909450

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| Unable to load library icui18n "Cannot load library icui18n: (icui18n:

| cannot open shared object file: No such file or directory)"

| QGtkStyle was unable to detect the current GTK+ theme.

| Running: viewer2.12.3 -geometry 1063x1063+857+17 -borders 29,3,3,3

| -shift 22,29 -preshift -19,0 -defer -host 127.0.0.1 -port 5600

| [VGL] Shared memory segment ID for vglconfig: 14942221

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| Running: mdserver2.12.3 -host 127.0.0.1 -port 5601

| [VGL] NOTICE: Replacing dlopen("/usr/lib64/libdl.so.2") with

| dlopen("libdlfaker.so")

| libGL error: No matching fbConfigs or visuals found

| libGL error: failed to load driver: swrast

| [VGL] Using Pbuffers for rendering

| [VGL] Using 1 / 20 CPU's for compression

| [VGL] Using pixel buffer objects for readback (BGRA --> BGRA)

| [VGL] Client version: 2.1

| Running: engine_ser2.12.3 -host 127.0.0.1 -port 5600

`----

+ Paraview (version 5.4.0)

If I run it with (vglconnect / vglrun) I can at least load and show a

basic image, but I cannot resize the window, as can be seen in the image:

http://picpaste.com/paraview-vglconnect-1Jpzk5sZ.png

If I try to run it inside TurboVNC, I get nasty GL errors about failing

to create context, as can be seen in the image:

http://picpaste.com/paraview-turbovnc-G6pA04dg.png

+ Mayavi (version 4.5.0)

This one complains about GLEW and core dumps...

If running (vglconnect / vglrun)

,----

| [angelv@deim ~]$ vglrun +v -cl com mayavi2

| [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

| [VGL] Shared memory segment ID for vglconfig: 15695882

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| Bus::open: Can not get ibus-daemon's address.

| IBusInputContext::createInputContext: no connection to ibus-daemon

| libGL error: No matching fbConfigs or visuals found

| libGL error: failed to load driver: swrast

| [VGL] Selecting structure notify events in window 0x06400025

| [VGL] Using Pbuffers for rendering

| ERROR: In

| /builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,

| line 628

| vtkXOpenGLRenderWindow (0x5636f7557970): GLEW could not be initialized.

| 

| Segmentation fault (core dumped)

| [angelv@deim ~]$

`----

If running (TurboVNC / vglrun)

,----

| [angelv@deim ~]$ vglrun +v mayavi2

| [VGL] NOTICE: Added /usr/lib64/VirtualGL to LD_LIBRARY_PATH

| [VGL] Shared memory segment ID for vglconfig: 15859722

| [VGL] VirtualGL v2.4 64-bit (Build 20170210)

| [VGL] Opening connection to 3D X server :0

| [VGL] Selecting structure notify events in window 0x02a00027

| [VGL] Using Pbuffers for rendering

| ERROR: In

| /builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,

| line 628

| vtkXOpenGLRenderWindow (0x557f2571f680): GLEW could not be initialized.

| 

| Segmentation fault (core dumped)

| [angelv@deim ~]$

`----

Any ideas?

Many thanks,

AdV

[DRC]

VirtualGL 2.4 is quite old. Before I can provide support for these
issues, you will need to verify whether they still exist in the latest
version. Please download and install VirtualGL 2.5.2. In general, I do
not recommend using O/S-supplied builds of VirtualGL. They are
typically outdated and sometimes are not implemented correctly. For
instance, the Fedora implementation places the faker libraries under
/usr/lib64/VirtualGL, which means that their build cannot be used to run
setuid root applications
(https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.2/doc/index.html#hd0012).
Other distributions, such as Arch, have historically bundled VirtualGL
incorrectly, leading to problems with applications that use dlopen() to
load libGL. Furthermore, new releases of VirtualGL almost always
contain application compatibility fixes. That's why, if you are
experiencing an issue with a particular application, the first thing you
should always try is upgrading to the latest official build of VirtualGL.

In short, if you are using an O/S-supplied build of VirtualGL, then you
should seek support from the O/S distributor. I can only support the
builds that I provide.

DRC

[Angel de Vicente]

Hello,

El jueves, 16 de noviembre de 2017, 17:21:06 (UTC), DRC escribió:

VirtualGL 2.4 is quite old.  Before I can provide support for these
issues, you will need to verify whether they still exist in the latest
version.  Please download and install VirtualGL 2.5.2.

OK, thanks for the advice. I downloaded the latest RPM version, removed the old 2.4 from the server machines and installed the new 2.5.2. 

VisIt still seems OK, Paraview now doesn't give me any trouble with window resisizing, but Mayavi2 is still giving me the same error:

(to avoid possible issues with the ArchLinux 2.5.2 VirtualGL version, which I didn't compile myself, I just run the test inside TurboVNC)

[angelv@deim ~]$ vglrun +v mayavi2

[VGL] Shared memory segment ID for vglconfig: 22118410

[VGL] VirtualGL v2.5.2 64-bit (Build 20170302)

[VGL] Opening connection to 3D X server :0

[VGL] Selecting structure notify events in window 0x02600027

[VGL] Using Pbuffers for rendering

ERROR: In /builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 628

vtkXOpenGLRenderWindow (0x564e98fe8670): GLEW could not be initialized.

Segmentation fault (core dumped)

[angelv@deim ~]$ 

AdV

[DRC]

OK, that is probably a legitimate bug, then. How does one obtain
mayavi2? The supposed link to the application home page is dead:
http://code.enthought.com/projects/mayavi/

[Angel de Vicente]

Hi,

our version was installed with dnf in Fedora, but I think the latest version of Mayavi can be downloaded from:

https://pypi.python.org/pypi/mayavi

AdV 

[DRC]

Sorry for the delay. I've reproduced this issue, and it seems that the
segfault is occurring here:
https://github.com/Kitware/VTK/blob/v7.1.1/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx#L386-L387


The cause of the crash seems to be the following sequence of events:

(1) VTK obtains a GLXFBConfig with glXChooseFBConfig(..., {
GLX_RED_SIZE=8, GLX_GREEN_SIZE=8, GLX_BLUE_SIZE=8, GLX_DEPTH_SIZE=16,
GLX_DOUBLEBUFFER=1 }). In the case of my particular machine, the first
FB config returned is:

0x259 24 tc 0 24 0 r y . 8 8 8 0 . 4 24 0 16 16 16 16 0 0
None PRW

which is the most commonly-used FB config for TrueColor rendering.

(2) VTK uses glXGetVisualFromFBConfig() to obtain the corresponding X
visual. VirtualGL returns 0x21, which is the only TrueColor 24-bit
visual provided by TurboVNC.

(3) VTK creates a window using this visual.

(4) For reasons I can't understand, VTK doesn't store the FB config it
obtained earlier. It instead tries to back-engineer it using this code:

https://github.com/Kitware/VTK/blob/feb05ce07089c5c1027818d5c878de19d229a69d/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx#L506-L523

Since there is not a 1:1 correspondence between Visuals and GLXFBConfigs
in VirtualGL, this code iterates through all of the GLXFBConfigs and
ultimately chooses the last one, which is an esoteric floating point
pixel format:

0x4c3 0 ?? 0 64 0 y . 32 32 0 0 f 4 24 8 16 16 16 16 0 0
None P..

(5) VTK calls glXCreateContextAttribsARB() with this FB config and
attributes of GLX_CONTEXT_MAJOR_VERSION_ARB=4,
GLX_CONTEXT_MINOR_VERSION_ARB=5, i.e. requesting an OpenGL 4.5 context.

(6) VTK calls glXMakeCurrent() with the new context. Within the body of
glXMakeCurrent(), VirtualGL creates a Pbuffer and maps it to the OpenGL
window, then calls glXMakeContextCurrent() to swap in the Pbuffer. This
call to glXMakeContextCurrent() fails for an unknown reason (but likely
related to the bizarre FB config that VTK has chosen.)

(7) VGL returns False from glXMakeCurrent(), but VTK ignores the return
value.

(8) There is no valid context when glBlendFuncSeparate() is called,
which presumably leads to the segfault.


I was able to work around this by commenting out:
https://github.com/VirtualGL/virtualgl/blob/master/server/faker-glx.cpp#L185-L190

thus making VirtualGL's implementation of glXGetVisualFromFBConfig()
more strict (i.e. it will no longer return a visual for the esoteric
floating point FB configs.) However, unfortunately that kicks the can
down the road and exposes new issues, which I am unable to diagnose:

ERROR: In
/builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkShaderProgram.cxx,
line 424
vtkShaderProgram (0xff953465f0): Shader object was not initialized,
cannot attach it.

ERROR: In
/builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkOpenGLVertexArrayObject.cxx,
line 271
vtkOpenGLVertexArrayObject (0xff9493e730): attempt to add attribute
without a program for attribute vertexWC

ERROR: In
/builddir/build/BUILD/VTK-7.1.1/Rendering/OpenGL2/vtkOpenGLPolyDataMapper2D.cxx,
line 359
vtkOpenGLPolyDataMapper2D (0xff951551c0): Error setting 'vertexWC' in
shader program.

NOTE: These errors can also be reproduced using the VTK examples and
with Mayavi2 on the local display (without VGL), so the errors are VTK
bugs, not ours.


I will investigate how best to work around the initial error. I need to
figure out why the more liberal visual matching code was added to
glXGetVisualFromFBConfig() in the first place and also try to find a
platform that reproduces the visual matching error but doesn't reproduce
the shader errors.

DRC

[DRC]

Try the latest 2.5.x pre-release build at
https://virtualgl.org/DeveloperInfo/PreReleases. It fixes the segfault
caused by the interaction issue between VGL's overly liberal
implementation of glXGetVisualFromFBConfig() and VTK's overly stupid
visual matching algorithm, which at least allows Mayavi2 to start.
However, I still can't find a way around the subsequent shader errors,
which seem to be an interaction issue between VTK and the nVidia
drivers. But if you're lucky enough to not be encountering those errors
on your platform, then hopefully this should allow Mayavi2 to work properly.

DRC