Supporting OpenGL/WebGL and using HW acceleration (GPU)

[accetto]

This idea has been initiated by the issue #1 in accetto/headless-drawing-g3, which has originally started as the issue #5 in accetto/ubuntu-vnc-xfce-firefox.

Even if the main purpose of my containers is to provide encapsulated application environments for experimenting, testing and development, I see a few generally usefull graphical applications, that could benefit from the hardware acceleration (GPU). One of them is probably Blender, another one could be FreeCAD.

One interesting subset of use cases is also using GPUs available on the cloud.

Also, even as it seems like the NVidia brand is currently the leader in this area, I would very welcome any hints about using also other brands of GPU hardware.

Because I don't have enough experience with this and currently I even don't have any up-to-date NVidia hardware, I would very welcome any help in this area. It could be with testing or just a hint about a helpful resource somewhere.

As the starting point I will publish several Docker images containing Mesa3D libraries and VirtualGL toolkit in the repository accetto/headless-drawing-g3. The GL Vendor-Neutral Dispatch library (glvnd) and the OpenGL benchmark application glmark2 from the Ubuntu 20.04 LTS distribution will also be included.

[accetto]

Some interesting articles that can be helpful:

• OpenGL and CUDA Applications in Docker
• HW accelerated GUI apps on Docker
• Setting up a HW accelerated desktop on AWS G2 instances
• How to Properly Use the GPU within a Docker Container
• NVIDIA Container Toolkit

[accetto]

I did some testing on a notebook with a standard integrated graphics HW from Intel and I want to share the results.

I've used the glmark2 benchmark application and one of my Docker images containing the mesa-utils and VirtualGL.

First I've run glmark2 directly on my host and I've got the following result:

=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel
    GL_RENDERER:   Mesa Intel(R) UHD Graphics 620 (KBL GT2)
    GL_VERSION:    4.6 (Compatibility Profile) Mesa 20.2.6
=======================================================
...
=======================================================
                                  glmark2 Score: 3936 
=======================================================

Then I've run it inside the container, but using the display #0 of the host. The VNC must not be started in this case.

xhost +local:$(whoami)

docker run -it -P --rm \
    -e DISPLAY=${DISPLAY} \
    --device /dev/dri/card0 \
    -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
    --name devrun \
    <image-with-mesa-and-virtualgl> --skip-vnc

xhost -local:$(whoami)

From the second terminal:

docker exec -it devrun glmark2

The result has been:

=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel
    GL_RENDERER:   Mesa Intel(R) UHD Graphics 620 (KBL GT2)
    GL_VERSION:    4.6 (Compatibility Profile) Mesa 20.2.6
=======================================================
...
=======================================================
                                  glmark2 Score: 4074 
=======================================================

It's interesting that the result was even slightly better than in the first case, but it could be just a usual deviation.

Then I've tested it inside the container, not using the VisualGL first. Software rendering was used in this case. I've accessed the container with TigerVNC Viewer. The VNC was running, of course.

xhost +local:$(whoami)

docker run -it -P --rm \
    --device /dev/dri/card0 \
    -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
    --name devrun \
    <image-with-mesa-and-virtualgl>

xhost -local:$(whoami)

The result has been significantly worse:

headless@devrun:~$ glmark2
** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
** Failed to set swap interval. Results may be bounded above by refresh rate.
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     Mesa/X.org
    GL_RENDERER:   llvmpipe (LLVM 11.0.0, 256 bits)
    GL_VERSION:    3.1 Mesa 20.2.6
=======================================================
...
=======================================================
                                  glmark2 Score: 378 
=======================================================

It's just about 10% of the first result directly on the host! I've got the score of just 306 by accessing the container via noVNC. That was another test run, of course. The slightly lower value is expectable, because there is an additional processing by websockify.

At last I've run the test inside the container using vglrun glmark2. The container has been started the same way as the one above. I've got the following result:

headless@devrun:~$ vglrun glmark2
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel
    GL_RENDERER:   Mesa Intel(R) UHD Graphics 620 (KBL GT2)
    GL_VERSION:    4.6 (Compatibility Profile) Mesa 20.2.6
=======================================================
...
=======================================================
                                  glmark2 Score: 549 
=======================================================

It can be seen, that Intel UHD Graphics 620 has been used for rendering and that the result is about 45% better then the previous one. So it seem that VirtaulGL is really working. By accessing the container via noVNC I've got the score of 447.

Note that I've got only about 60% of the scores while using an external 4K monitor.

I would make the following conclusions from these tests:

1. The best performance can be achieved by sharing the display of the host and not running the VNC server inside the container.
2. It still makes sense to install 3D applications inside containers. They can be nicely encapsulated and it seems that they could run without a performace penalty if sharing the display with the host.
3. It seems that the bottleneck is actually the VNC server running inside the container. According the results from above it costs about 90% of the performace. However, it can be different with NVidia hardware and NVIDIA Docker Toolkit installed.
4. If you still want/need to run the VNC server inside he container, then it's better to use the vglrun command from the VirtualGL toolkit, because the performance gain seems to be about 45%. It can be probably much more with NVidia hardware and drivers.

[draco1544]

Any news on this ?

[accetto]

I'm currently updating the images to Ubuntu 22.04 LTS. Maybe it'll bring some improvements. Also the TigerVNC and noVNC have been already updated in between.

The new release will be published in the next few days.