gz-sim: Instant crash on start (ARM64 Ubuntu 22.04 Virtual Machine)

@bertaveira I’ve tried various VMs (UTM, Parallels, VMware Fusion, Virtual Box) on macOS (Intel and M1) and none of them have good enough support for OpenGL 4.3+ to run accelerated graphics for Gazebo Sim after the upgrade of ogre2 to 2.2. Same outcome for docker.

The most promising candidate so far is VMware Fusion 13 which claims to have support for OpenGL 4.3 (https://docs.vmware.com/en/VMware-Fusion/13.0/rn/vmware-fusion-130-release-notes/index.html). I have installed Gazebo Garden from source on Ubuntu Jammy (upgraded to 22.10 to get the latest mesa drivers). Unfortunately the hardware acceleration is still not there. The mesa drivers appear to support a suitable version of OpenGL:

glxinfo |grep -i opengl
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
OpenGL core profile version string: 4.3 (Core Profile) Mesa 22.2.1
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.3 (Compatibility Profile) Mesa 22.2.1
OpenGL shading language version string: 4.30
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 22.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

However the rendering window on gz sim is grey, and the rendering examples (for example simple_demo ogre2) are not working. I have not done a full OpenGL debug yet, so there may be a combination of mesa environment flags that will get it working.

If you’re on mac, M1 or Intel, the Metal rendering for gz sim running natively works well.

Edit

Disabling DRI3 gets the simple_demo and ogre2_demo examples running with ogre2:

LIBGL_DRI3_DISABLE=1 ./simple_demo ogre2

LIBGL_DRI3_DISABLE=1 ./ogre2_demo ogre2

The latter is encouraging as it uses PBS in the render.

No luck yet with the main application.

Edit2

Progress: I pulled the latest source for the Garden branches, rebuilt and ran a marine project which is very demanding on graphics:

LIBGL_DRI3_DISABLE=1 gz sim -v4 waves.sdf

Gazebo Garden running with acceleration on this system:

System: macOS Monterey 12.6 Machine: Mac Pro (2019) VM App: VMware Fusion 13.0.0 VM: Ubuntu 22.10

Hi, As an exclusive ros2 user, I do not use Humble and gz-sim natively, using instead Parallels 19 VM configured with Ubuntu 22.04 & ROS 2 Humble Desktop Full. I usually disable Graphics Acceleration in Desktop Control and rviz and ign gazebo run ok. Parallels seems to have made some changes in this ver 19 that works better. I should add that I cannot install the new gz harmony or iron in the UB22 VM as arm64 binary install packages are not yet release and the compile from source don’t work.

@devashishRaj Please take a look at the build commands used in https://github.com/gazebosim/gazebo_test_cases/issues/804. M1 (ARM) machines are not fully supported yet, so we don’t have any official documentaiton.

Hi @staycoolish!

I’ve tried out multiple complicated worlds. You can see it in action in Gazebo’s tools from 0:04 to 0:23. (Big shoutout to this OP! #855 for the camera!!)

https://www.youtube.com/watch?v=h-yra2-bHZE.

I’ve used a Blender environment, multiple sensors, and various types of robots. Oh boy!! I had to dust off my old Dockerfile and run it on my M2. Everything felt so old, and it’s only been a year! The current setup is ten times better than before!

Anyway…

Take a look at this link:

https://github.com/gazebosim/gz-sim/assets/65916520/014e4b94-a242-4e99-b80d-678a09fde022.

I was able to use quadcopter, Prius, and some other features on Docker. The thing is that my team and I are currently focused on other projects and haven’t touched Gazebo in a while. We will resume with Gazebo later. I use Gazebo in my free time now.

Anyway…

I must emphasize that this is Citadel on Docker. Regarding your comment about performance, that’s exactly why I chose Citadel. If you use Fortress, Garden, or Harmonic, it will be much more resource-intensive than Citadel. Fortress, Garden, or Harmonic are much larger and more complex than Citadel. Citadel was kind of new at the time, so it was able to work with Docker due to lower rendering requirements (I’m not entirely sure if I’m using the terminology correctly).

Honestly, Gazebo performs better with a local/native setup rather than in a virtual machine. If you still want to use a VM, go for 20.04, as I believe it’s currently only supported on that Citadel. Citadel is now EOL, I believe.

I personally need smooth graphics too, and so far, native/local setups are the only ones I’ve used. You can use Docker, but you’ll need to allocate more CPU cores, maybe up to 10 or the maximum available which is what you see in the second video.

Harmonic on the M2 Mac was my very first time on a Mac. If it worked on M2, it should work with M1 as well. I have a regular M1 at my office.

I’m not familiar with robotstack, sorry 😦 but thanks for the information!

Could you give this a try on your M1?

Open a terminal and run:

ulimit -n unlimited
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
brew tap osrf/simulation
brew install gz-harmonic

Alternatively, you can try running ign gazebo --render-engine ogre. It worked for me (the last time I tried this was last year, so it might have changed by now).

I ran ign gazebo --render-engine ogre and this worked for me on Gazebo Fortress. Thanks, really performant

The unlinking qt (=qt@6) is an extra step. You still need to follow the instructions to install qt@5.

My oversight as I should request to have the instructions updated to include the unlink step if a conflict is observed.

Correcting my previous post, on Ubuntu 22.04 and Lubuntu 22.04, ~/gz sim works with the line “LIBGL_ALWAYS_SOFTWARE=1” in ~/.bashrc file, remembering to “$ source .bashrc” . In my case this environment variable does not appear in /etc/environment, though it is displayed in $ printenv|grep ALWAYS.