I got Beyond All Reason running (almost) on an M2 Pro Mac
(Disclaimer: this was heavily assisted by Claude.)
So my setup is:
- macOS Sequoia on M2 Pro
- UTM 5.0.3 beta running QEMU with the Apple Hypervisor backend
- Debian 13 ARM64 guest with paravirtualized virtio-gpu
- Mesa's Venus Vulkan driver in the guest, forwarded to the host
- virglrenderer + MoltenVK on the host, translating Vulkan → Metal → Apple GPU
- FEX-Emu running BAR's x86_64 binaries on aarch64
In the screenshot, BAR is running through llvmpipe — Mesa's CPU software rasterizer — not the GPU. The GPU-accelerated path (Zink → Venus → MoltenVK) crashes on a specific, probably fixable feature gap. Framerate is unusable, but the engine loaded a map, spawned an AI, ran Lua widgets and rendered. Crashes on window resize (separate Mesa bug, workaround: don't resize). As you can see the UI widgets look messed up but they briefly showed correctly at the beginning.
I guess getting into a game at all is already progress, thanks to latest advances in the Venus driver?
Reproduction:
UTM 5.0.3 beta (stable 4.x lacks Venus):
brew install --cask utm@beta
Create a new VM (with virtualize, not emulate):
- System: ARM64, QEMU backend
- Display: Emulated card =
virtio-gpu-gl-pci, GPU Supported on, Vulkan = MoltenVK, Renderer Backend = Default - Apple Virtualization: OFF
Install Debian 13 ARM64. Verify Venus loaded:
vulkaninfo --summary | grep -A2 "GPU0"
You want driverName = venus. If you only see llvmpipe, the UTM display settings are wrong.
Install FEX-Emu (the InstallFEX.py path doesn't work on Debian 13):
sudo apt install curl
curl -fsSL "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xEDB98BFE8A2310DC9C4A376E76DBFEBEA206F5AC" \
| sudo gpg --dearmor -o /etc/apt/keyrings/fex.gpg
echo "deb [signed-by=/etc/apt/keyrings/fex.gpg] https://ppa.launchpadcontent.net/fex-emu/fex/ubuntu noble main" \
| sudo tee /etc/apt/sources.list.d/fex.list
sudo apt update
sudo apt install fex-emu-armv8.4
FEXRootFSFetcher # pick Ubuntu_24_04
FEXBash -c "uname -m" # should print x86_64
Get BAR (extract — the AppImage's FUSE path doesn't work under FEX):
mkdir ~/bar && cd ~/bar
wget https://github.com/beyond-all-reason/BYAR-Chobby/releases/download/v1.2988.0/Beyond-All-Reason-1.2988.0.AppImage
chmod +x Beyond-All-Reason-1.2988.0.AppImage
./Beyond-All-Reason-1.2988.0.AppImage --appimage-extract
cd squashfs-root
Run through llvmpipe (the working path):
LIBGL_ALWAYS_SOFTWARE=1 \
GALLIUM_DRIVER=llvmpipe \
MESA_LOADER_DRIVER_OVERRIDE=llvmpipe \
__GLX_VENDOR_LIBRARY_NAME=mesa \
FEXInterpreter ./beyond-all-reason --no-sandbox
Host a skirmish vs AI, pick any map, don't resize the window.
The broken GPU path uses MESA_LOADER_DRIVER_OVERRIDE=zink MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 instead — UTM's QEMU dies with VK_ERROR_INITIALIZATION_FAILED: Vertex shader function could not be compiled into pipeline.
Existing issues that could use a boost to get the GPU working:
UTM ships MoltenVK without MVK_USE_METAL_PRIVATE_API=1**.** This single build flag would expose VkPhysicalDeviceFeatures::logicOp, which Zink complains about at startup. The flag exists because it disqualifies a binary from Mac App Store distribution — but UTM's GitHub build isn't App Store, so it could ship with the flag. MoltenVK README documents this: https://github.com/KhronosGroup/MoltenVK#optionally-build-with-metal-private-api . UTM maintains its own MoltenVK fork at https://github.com/utmapp/MoltenVK . No existing UTM issue requests this; the closest is DXVK support #7575 (https://github.com/utmapp/UTM/issues/7575), which hits the same root cause — logicOp: 0 blocks DXVK at D3D feature level 10+. Same fix unlocks both. I'll file a new issue and cross-link.
VK_EXT_custom_border_color is closed-as-not-planned on MoltenVK: https://github.com/KhronosGroup/MoltenVK/issues/1987 . Metal genuinely doesn't expose this. MoltenVK doesn't seem interested. Can we make them change their mind? Another more realistic ask is Mesa/Zink degrading gracefully instead — Maintainer might be responsive to these reports at https://gitlab.freedesktop.org/mesa/mesa/-/issues
Separate MoltenVK shader-compilation NULL deref at MVKCmdBindGraphicsPipeline::isTessellationPipeline() on the Zink path. I got a crash with this that should be fixed in MoltenVK.
Mesa/llvmpipe resize crash — SIGSEGV in _mesa_glapi_set_dispatch after SDL_WINDOWEVENT_SIZE_CHANGED, looks like a thread-safety bug.
That's it, I humbly hope this contributes somewhat to progress towards a Mac build :)
Thanks for such a great RTS game :)