Reputation: 864
After installing various packages and programs like vtk, tvtk, ParaView, mayavi, … on my system, I end up with totally broken global packages. For instance: currently I'm not able to run mayavi for more than few seconds, than it crashes without any message. The problem is that every library needs different version of dependencies (notably Qt4 vs. Qt5), you sometime needs to build the software manually to allow certain non-standard features (ParaView with Python support) and so on. The result is total mess.
Therefore, I decided to build ParaView in Docker to isolate the software. I definitely need Python scripting capabilities of ParaView which is not default choice for Ubuntu repository package. Here is result of my work. I was inspired by this repository, however there are certain drawbacks, notably no Python and MPI support and it is a fork of official ParaView repo.
So, I used it and create a new repository. It is an Ubuntu image with all necessary packages, ParaView is built with MPI and Python support. See README
how to build it and how to run it. If anyone is interested I can push the image to dockerhub
. Note that user on host machine needs to have uid
1000, otherwise X server tunnel won't work correctly. This can be, however, easily fixed.
So, the issue is following. When I run the ParaView, I see this error message:
libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: i965
Obviously, there is no OpenGL
acceleration. Is there anyone who knows how to enable OpenGL support in docker? I know of this repository, however I don't like the solution via vnc
. Is there any other way how to do the same? I'm not familiar with OpenGL
so any help is much appreciated.
Upvotes: 1
Views: 2004
Reputation: 1399
You may try these steps:
Then you should be able to use software rendered OpenGL.
Sharing X unix socket from host can have some caveats. You can use mviereck/x11docker to run your image on a second X server instead. Software rendered OpenGL works fine. Hardware rendering is experimental and in development.
On your github repo example you are using host display :0, sharing $DISPLAY
and unix sockets:
docker run -ti -e DISPLAY=unix$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix paraview
If you share all files in dev/dri
with your container (especially /dev/dri/card0
), most probably you get hardware acceleration. If you get some rendering glitches, you can use docker run option --ipc=host
. Depending on X setup, one needs to share ~/.Xauthority
and $XAUTHORITY
, too, or setting xhost +SI:localuser:root
on host if container user is root.
CAUTION: This setup breaks down container isolation! (For better isolation, check out x11docker.)
Upvotes: 3
Reputation: 13108
In addition to what @mviereck proposed, on an nvidia-docker container, I needed to do docker run --privileged
. My entire docker run command looks like:
Obviously this isn't an ideal solution, but is sufficient for many local use cases where isolation isn't a major concern.
CMD="${DOCKER} run --detach=true \
--privileged \
--group-add ${DOCKER_GROUP_ID} \
--env HOME=${HOME_DIR} \
--env DISPLAY \
--interactive \
--name DevContainer \
--net=host \
--rm \
--tty \
--user=${USER_ID}:${GROUP_ID} \
--volume $HOME_DIR_HOST:${HOME_DIR} \
--volume $WORK_DIR:${WORK_DIR} \
--volume /tmp/.X11-unix:/tmp/.X11-unix \
--volume /var/run/docker.sock:/var/run/docker.sock \
${IDEA_IMAGE}"
Many of those options are superfluous to OpenGL, but useful for certain applications needing extended access.
Since I'm using an nvidia docker container, $DOCKER
is actually nvidia-docker
in my case.
I also added my host user to the video
group, though I'm not sure if that mattered.
Upvotes: 1