search

Open-UAV / openuav-turbovnc

Simulation environment for UAVs, ROVs and AUVs using Gazebo physics and Unity3D rendering.
Other
42 stars 14 forks source link

VirtualGL fails to load gazebo, [VGL] ERROR issues thread #29

Closed harishanand95 closed 3 years ago

harishanand95 commented 3 years ago

VirtualGL needs to be updated to the latest version for GPU version > 420

https://www.mail-archive.com/virtualgl-users@googlegroups.com/msg00190.html

peneroka commented 3 years ago

Hello, I tried to build docker image of this repo using the build.sh on local machine (a laptop with amd gpu), I have succesfully load the vnc of the container through port 40001. But, in the container, I can't run the gazebo. It shows error [VGL] ERROR : Could not open display :0. as in the image below. I tried to update the VirtualGL, but no succeed. How to update it? Or how to troubleshoot this error? Thanks before.

image

harishanand95 commented 3 years ago

Hi @peneroka,

Unfortunately, we have not tested our framework with AMD GPUs.

Let me briefly describe the issue you are facing. Applications like Gazebo need libX11.so and libGLX.so to work. For all applications inside the container, X11 is provided by the TurboVNC's Xvnc (acting both as X window server and as a vnc server). VirtualGL is used to redirect applications (like Gazebo or Unity) that make GLX calls (3D rendering) to run the graphics rendering in a dedicated GPU and we achieve this by preloading each command you run in the terminal through vglrun command.

Regarding env variables, the DISPLAY env variable points to :1.0 which is the TurboVNC X window session (Xvnc) while the application also needs an X window server (with 3D acceleration) for GLX calls. We provide details of GLX session using the variable VGL_DISPLAY which is set to :0.0 on all containers. If VGL_DISPLAY is not set on the container, it assumes the value :0.0.

You can check for any GLX issues, by using the command glxgears. Glxgear application's 2D window will be handled by TurboVNC (Xvnc) and 3D rendering will be handled by an X with GPU (virtualGL should redirect this correctly).

To fix your issue, I would suggest trying to set up an X server with GPU support separately on host or passing a host X server running on the machine (with GPU) to the container as /tmp/X11-unix/X0. For example, changing the host X0 or whatever X connection you have and passing it to the container correctly in run.sh.
-v /tmp/.X11-unix/X0:/tmp/.X11-unix/X0:rw

/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch is the command to run the Xorg at display :0.0, you might need to run a command similar to this on your host machine with xorg conf set properly to use AMD GPUs.