2018-08-19 20:27 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0003033OpenFOAM[All Projects] Bugpublic2018-08-11 13:52
Reporterpeterpfeiffer 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformHost: centos 7.5OSLinuxOS Version7.5
Product Version6 
Target VersionFixed in Version 
Summary0003033: paraFoam error: libGL error: No matching fbConfigs or visuals found
DescriptionHost OS: Centos 7.5.
Docker: 18.03.1-ce (1.37 API)

Docker Image: openfoam/openfoam6-paraview54 latest 63210ff51dcc 4 weeks ago 2.34GB

Docker Image installs correctly.

When executing paraFoam the following error is encountered:

OpenFOAM-6(80) paraFoam
Created temporary 'pitzDaily.OpenFOAM'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
I/O : uncollated
Steps To ReproduceFollowing steps outlined on: https://openfoam.org/download/6-linux/

steps:

cd $HOME/OpenFOAM/${USER}-6
openfoam6-linux

(docker container loads correctly)
Steps executed from inside docker container:

mkdir -p $FOAM_RUN

cd $FOAM_RUN
cp -r $FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily .
cd pitzDaily
blockMesh
simpleFoam
paraFoam <- ERROR generated


OpenFOAM-6(80) paraFoam
Created temporary 'pitzDaily.OpenFOAM'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
I/O : uncollated

Additional Information
Docker Image: openfoam/openfoam5-paraview54
Same Issue
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0009917

wyldckat (updater)

Quick questions:
1. Is CentOS 7.5 installed on a real machine or inside a virtual machine?

2. Are you able to use any 3D acceleration software on that machine that has CentOS 7.5?

  - For example "glxgears" and/or the pre-built ParaView binaries from ParaView.org

~0009923

peterpfeiffer (reporter)

Hi Wyldckat,

1. Real Machine. Fresh install of CentOS 7.5.

2. glxgears display without errors when executed directly on the host and from withing the docker container. In each case (directly on the host, and from within docket) the gears are moving much,much slower than what the windows reports. ~34 FPS inside docker and 100-230 FPS on the host.

paraFoam displays properly with only the openGL window failing to visualize.

So far, crumbs seem to point to an issue/incompatibility with libGL*

I have since installed the nvidia driver. NVIDIA-Linux-x86_64-390.77.run No Change. Same error.


nvidia-smi:

Wed Aug 8 09:21:23 2018
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.77 Driver Version: 390.77 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Quadro 2000 Off | 00000000:05:00.0 On | N/A |
| 30% 37C P12 N/A / N/A | 60MiB / 962MiB | 0% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1896 G /usr/bin/X 49MiB |
| 0 2035 G /usr/bin/gnome-shell 8MiB |
+-----------------------------------------------------------------------------+


[root@cuw002 yum.repos.d]# glxinfo | grep -i opengl
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)
OpenGL extensions:

~0009936

wyldckat (updater)

I've tested this with Docker 17.05 and 18.06 on a Ubuntu 16.04 host. I only got paraFoam/ParaView to work if I use the option "-x", namely:

  openfoam6-linux -x

but in your original report there was no "-x" option. So my question is if you were and are using this option or not?

Because if not, try using it to see if it works?

By the way, what does the "glxinfo | grep -i opengl" command give you when you run it from within the container?



For future reference, I use an AMD GPU integrated into the CPU, so the drivers are completely different form NVidia's, although I still got an error message but it still managed to get ParaView to open without problems... the output I've gotten when launching 'paraFoam' was this:

  Created temporary 'pitzDaily.OpenFOAM'
  libGL error: failed to open drm device: No such file or directory
  libGL error: failed to load driver: radeonsi
  I/O : uncollated

~0009942

peterpfeiffer (reporter)

Glad to hear you were able to reproduce the issue on radeon. I am feeling a little better :-) and it will help with tweaking the next release.

Since yesterday I installed paraview-4.4.0-2.el7.x86_64 from the epel repo. yum also installed whole bunch of dependencies. Unfortunately I did not think to capture the list. paraview 4.4 works on the host. I am planning to build the latest 5.x version from source (if needed) when I have more time.

 openfoam6-linux -x works. Although not entirely stable. Had 1 crash when testing.

Its the "-x" option that helped. I am still having the error if I run penfoam6-linux without "-x".

glxinfo | grep -i opengl from within docker. Very different. The "VMware, inc" vendor string is a little odd.

OpenFOAM-6(105) glxinfo | grep -i opengl
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits)
OpenGL version string: 3.0 Mesa 18.0.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

~0009947

wyldckat (updater)

A few details for future reference:

 - The '-x' option was originally added for supporting remote connections with X support via SSH. This change was submitted in report #2599.

 - I don't have enough experience with Docker to know if the issue report here was due to recent changes in Docker, due to security policies or something along those lines. I still have to check if there is an explicit host connection in Docker that allows direct access to the GPU, as was done with the '-x' option for network access.

 - The vendor string referring to VMware may be related to the "llvmpipe" rendered, but oddly enough I can't find any information about that.



As for glxinfo on my side, I get the following from within docker, depending on the connection:

 - When connecting via X2Go with an NX-VNC session, I get the same output on both the session and within the container, namely:

    OpenFOAM-6(38) glxinfo | grep -i opengl
    OpenGL vendor string: VMware, Inc.
    OpenGL renderer string: llvmpipe (LLVM 6.0, 128 bits)
    OpenGL version string: 3.0 Mesa 18.0.5
    OpenGL shading language version string: 1.30
    OpenGL context flags: (none)
    OpenGL extensions:


 - When connecting from the physical desktop:

    OpenFOAM-6(42) glxinfo | grep -i opengl
    libGL error: failed to open drm device: No such file or directory
    libGL error: failed to load driver: radeonsi
    OpenGL vendor string: VMware, Inc.
    OpenGL renderer string: llvmpipe (LLVM 6.0, 128 bits)
    OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.0.5
    OpenGL core profile shading language version string: 3.30
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile
    OpenGL core profile extensions:
    OpenGL version string: 3.0 Mesa 18.0.5
    OpenGL shading language version string: 1.30
    OpenGL context flags: (none)
    OpenGL extensions:
    OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.0.5
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
    OpenGL ES profile extensions:


However, I'm not able to launch ParaView from within the X2Go session, nor from within the Docker container, given that no proper OpenGL support is turned on in that session.


In the meantime I'll try to look further into Docker changes, to see what exactly changed that affected how things used to work.

~0009949

wyldckat (updater)

@peterpfeiffer: Please test the attached script "openfoam6-linux.patched1":

1. Download it and place it in a safe path, for example, at "~/OpenFOAM/docker".
2. Then make it executable:

  chmod +x openfoam6-linux.patched1

3. Then run it:

  ./openfoam6-linux.patched1

What I changed is that I added a couple of lines that will set to use the ".Xauthority" file that is being used from the local machine for your local connection, to then also be used from within the container, so that it has permissions to access the GPU.

This way the "-x" option is not needed and it does not open access to/from the outside network.



If this fails, then please test running the following commands:

    xhost local:docker
    openfoam6-linux

The first command should give you a message like this:

    non-network local connections being added to access control list

Meaning that physical connections to the machine will allow X to allow connections from the "local:docker".
This is conceptually the same as the patched script, but instead modifies the global authority file from the current local X session.
+Notes

-Issue History
Date Modified Username Field Change
2018-08-07 21:23 peterpfeiffer New Issue
2018-08-07 21:28 wyldckat Note Added: 0009917
2018-08-08 14:52 peterpfeiffer Note Added: 0009923
2018-08-09 00:30 wyldckat Note Added: 0009936
2018-08-09 20:47 peterpfeiffer Note Added: 0009942
2018-08-11 12:47 wyldckat Note Added: 0009947
2018-08-11 13:48 wyldckat File Added: openfoam6-linux.patched1
2018-08-11 13:52 wyldckat Note Added: 0009949
+Issue History