how to use TurboVNC on a docker container with no display or preliages

[jjziets]

I have been trying to play a game(SuperTuxKart) on vastai. Yea it's for fun but so one learns. I'm effectively renting a supercomputer and want to try use it to play a 3d game. But this is turning out to e a lot more of a challenge than I thought.

using Image: [tensorflow/tensorflow ] Image CUDA version: 11.2

I installed x11vnc virtualgl_3.0.1_amd64.deb turbovnc_3.0_amd64.deb SuperTuxKart-1.3-linux-64bit apt-get install xorg openbox

root@C.4656436:~$ /opt/TurboVNC/bin/vncserver -geometry 1366x768 -depth 16 -noautokill

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n
root@C.4656436:~$ /opt/TurboVNC/bin/vncserver -geometry 1366x768 -depth 16 -noautokill

Desktop 'TurboVNC: 91c695f2e120:1 ()' started on display 91c695f2e120:1

Starting applications specified in /opt/TurboVNC/bin/xstartup.turbovnc
Log file is /root/.vnc/91c695f2e120:1.log

but when I try to run the x11vnc it with that display it does not work

x11vnc -passwd TestVNC -display 91c695f2e120:1 -N -forever -rfbport 40000 &
[1] 19234
12/06/2022 19:58:30 passing arg to libvncserver: -passwd
12/06/2022 19:58:30 passing arg to libvncserver: -rfbport
12/06/2022 19:58:30 passing arg to libvncserver: 40000
12/06/2022 19:58:30 x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 19234
12/06/2022 19:58:30 XOpenDisplay("91c695f2e120:1") failed.
12/06/2022 19:58:30 Trying again with XAUTHLOCALHOSTNAME=localhost ...

12/06/2022 19:58:30 ***************************************
12/06/2022 19:58:30 *** XOpenDisplay failed (91c695f2e120:1)

I can use Xvfb for the virtual display. but I then not getting any 3D hardware accel

export VGL_DISPLAY=:20
export DISPLAY=:20
Xvfb :20 -screen 0 1366x768x16 &
x11vnc -passwd TestVNC -display :20 -N -forever -rfbport 10100 &
vglrun /root/SuperTuxKart-1.3-linux-64bit/run_game.sh

but this sucks big time

[dcommander]

Several misunderstandings:

1. Do not use x11vnc with the TurboVNC Server. The TurboVNC Server already has a built-in VNC server.
2. It is not necessary and generally not recommended to pass -depth 16 to the TurboVNC Server. Many modern applications require a 24-bit color depth. VirtualGL also requires a 24-bit color depth. (24-bit is the default color depth in the TurboVNC Server.)
3. VGL_DISPLAY should never point to the same X display as DISPLAY. VGL_DISPLAY should point to the 3D X server, which is a dedicated shared X server that is attached to a GPU.

In a Docker environment, the most straightforward approach is to run the 3D X server and TurboVNC Server outside of the container and to run VirtualGL, the 3D application, and the window manager inside of the container. This example demonstrates how to accomplish that: https://github.com/dcommander/virtualgl_docker_examples/tree/vgl_glxspheres-glxbackend Note, however, that the nVidia Container Toolkit is required in order to access the GPU from inside of the Docker container.

With the example above, you should replace bash with the window manager startup script (openbox-session, for instance) and then pass the run script to the TurboVNC Server using the -xstartup argument or $xstartup configuration file directive.

It is possible to run the TurboVNC Server inside of the container as well, but because of the need to map the RFB listening port from the container to the host, that configuration is problematic in a multi-user environment. It should work OK if you are the only user, however. (Just map Port 5901 from the host to the container in that case.)

[jjziets]

Hi Ok thanks, in short in this case, vast.ai, where I don't have access to the host and can not pass a xserver to the docker container it is not possible to setup a game-like application from inside the server?

Also the container gets given a range of ports that is exposed to the host. I can't change that from within.

can I tell TruboVNC to use another port? I don't; see a port option like x11vnc has.

[dcommander]

Yes, you can pass -rfbport {port} to /opt/TurboVNC/bin/vncserver to specify a listening port. Unfortunately, setting up VirtualGL correctly requires root access on the host. (The vglserver_config script is executed as root in order to configure continuous access to the GPU via either the 3D X server or DRI devices.) If you are lucky, then your user account may already be able to access the DRI devices, but on a shared system, there is no guarantee that your user account will continue to have access to those devices unless vglserver_config is run. Also, the only way (of which I am aware) that a GPU can be accessed from a Docker container is by way of the nVidia Container Toolkit, which provides a special build of Docker with some nVidia-specific glueware. If your host doesn't already have that installed and you have no way to install it, then you're sunk.