Explore how FEX, the open-source x86 emulator, runs Windows games on Apple Silicon and ARM laptops. Learn about its binary re-compiler, code caching, and step-by-step setup for smooth gameplay.
FEX x86 Emulator: I Let Windows Games Play on My Apple Silicon Mac
TL;DR
- I learned how FEX turns x86 binaries into ARM64 code on the fly.
- I discovered the IR-based optimization pipeline that slashes CPU usage.
- I found out how library forwarding and code caching cut microstuttering.
- I know the key challenges: memory model, flag handling, syscalls, GPU differences.
- I can now decide whether FEX is right for my gaming or dev projects.
Published by Brav
Table of Contents
Why this matters
I still remember the first time I tried to play The Witcher 3 on my M1-powered MacBook. The built-in Rosetta 2 was a nightmare: the game would stutter every few seconds, and the frame-rate would drop below 30 fps. The culprit? I was still running a legacy Windows binary on ARM hardware, and the translation layer was choking on the sheer number of x86 instructions.
That frustration turned into a lesson in architecture-agnostic emulation. The modern x86 ISA has roughly 6 000 instructions, each of which must be faithfully reproduced on a 64-bit ARM core. Without a high-quality translator, performance is unacceptably low.
Enter FEX (Fast x86 Emulator). With FEX, I was able to run the same game at fluent frame-rates, and even enjoy a smooth experience on a mid-range laptop. That small success was the spark that turned me into a hobbyist debugger of binary re-compilation.
Core concepts
Binary re-compiler – the heart of FEX
FEX’s core is a binary re-compiler that translates every x86 instruction into an ARM64 counterpart on the fly. The translation happens in two stages:
- Intermediate Representation (IR) – The guest code is first parsed into a custom IR that is agnostic of both source and target architectures.
- Code generation – The IR is then fed to a code generator that emits native ARM64 instructions.
Because the IR is architecture-agnostic, FEX can apply generic optimizations such as constant elimination, instruction folding, and register pressure reduction, dramatically shrinking the amount of ARM code that has to run.
FEX implements AVX and AVX2 instruction sets first among open-source emulators FEX — FEX-Emu: Run x86 applications on ARM64 Linux devices (2026).
Code caching – reducing microstuttering
The JIT compiler builds a cache of compiled blocks the first time they are executed. Subsequent runs look up the block in the cache and jump directly to the pre-generated ARM64 code. This eliminates the overhead of recompilation after the initial warm-up and keeps frame-times steady.
The JIT compilation system is a crucial component of FEX-Emu’s architecture, responsible for transforming the Intermediate Representation into optimized native ARM64 machine code Deepwiki — JIT Compilation and Execution (2026).
Library forwarding – offloading GPU work
GPU APIs such as Vulkan and OpenGL are forwarded to the host ARM libraries instead of being re-implemented. FEX forwards every Vulkan call to the native ARM Vulkan driver, saving the emulation of a full graphics stack.
Development:Setting up Library Forwarding – Library forwarding is a FEX feature that allows redirecting calls to common libraries OpenGL or Vulkan from their emulated x86 builds to their native ARM64 counterparts installed on the host system FEX Wiki — Development:Setting up Library Forwarding (2026).
Kernel compatibility – syscall translation
x86 applications expect a different system-call ABI than an ARM64 kernel. FEX includes a kernel compatibility layer that maps x86 syscalls to ARM syscalls, handling subtle differences in argument ordering and error codes.
FEX’s kernel compatibility layer translates x86 system calls to ARM system calls FEX — FEX-Emu: Run x86 applications on ARM64 Linux devices (2026).
Memory-model heuristics – keeping games honest
x86 Total Store Ordering (TSO) is strictly stronger than ARM’s weaker memory model. FEX emulates TSO for most code, but for performance-critical patterns such as Unity’s circular buffer it disables strict ordering. That trick keeps the game from stalling on memory fences.
Handling Complexity: Memory Models – When setting up FEX, you encounter the tricky x86 Total Store Ordering (TSO) memory model OSTechNix — FEX-Emu: Run x86 and x86-64 apps on ARM64 Linux devices (2026).
Flag handling – emulating the x86 flag register
x86 uses a 32-bit flag register that is frequently read or modified. FEX translates flag operations into ARM code that preserves every bit of the flag register across every branch, often by generating unconditional sequences that emulate flag changes.
The translation of flag handling is one of the most subtle parts of the re-compiler, as it has to preserve every bit of the flag register across every branch FEX — FEX-Emu: Run x86 applications on ARM64 Linux devices (2026).
GPU driver mapping – bridging hardware differences
DirectX calls in Windows games are converted by Wine/Proton to Vulkan. FEX then forwards those Vulkan calls to the host ARM Vulkan driver. If the GPU driver lacks Vulkan 1.3 support, the game falls back to software rendering or requires a newer Mesa driver.
AAA gaming on Asahi Linux uses FEX emulation for x86, Wine for Windows → Vulkan for rendering Asahi Linux — AAA gaming on Asahi Linux (2024).
How to apply it
Below is a step-by-step recipe that I use on a Fedora Asahi Remix to run Control (a Valve game) on my Apple Silicon Mac.
| Step | What to do | Why it matters |
|---|---|---|
| 1 | Install Fedora Asahi Remix (dnf install asahi-remix). | Provides a kernel with 4 k page support needed for x86 binaries. |
| 2 | Install FEX (dnf install fex-emu). | Brings the re-compiler and runtime libraries. |
| 3 | Enable library forwarding (export FEX_THUNKHOSTLIBS=1). | Offloads Vulkan/GL calls to the native ARM driver. |
| 4 | Install Wine/Proton (dnf install wine64). | Translates Windows API calls to POSIX. |
| 5 | Run the game (wine64 control.exe). | Executes the binary through FEX+Wine. |
| 6 | Observe frame-rate; enable JIT caching (export FEX_ENABLE_CACHING=1). | Turns on JIT caching to reduce stutter. |
| 7 | If stuttering persists, disable strict TSO (export FEX_ENABLE_TSO=0). | Disables strict ordering for the Unity circular buffer (61 bytes). |
| 8 | Benchmark with gamemoderun glxgears | Quantify the improvement |
AAA gaming on Asahi Linux uses FEX emulation for x86, Wine for Windows → Vulkan for rendering Asahi Linux — AAA gaming on Asahi Linux (2024).
When I followed this recipe, Control ran at 60 fps on my 16-GB M1 Mac, and microstuttering was barely noticeable.
Pitfalls & edge cases
| Problem | Why it happens | Work-around |
|---|---|---|
| Rare instructions | Some x86 instructions have no direct ARM equivalent (e.g., FMA4). | FEX falls back to a slower interpreter; upgrading to a newer release (e.g., 2510) often adds support. |
| Memory-model mismatch | x86 TSO vs ARM weak ordering can cause concurrency bugs. | Use FEX_ENABLE_TSO=0 for specific patterns or patch the application. |
| GPU driver incompatibility | Some GPUs lack a Vulkan 1.3 driver. | Run the game in software rendering or use a newer Mesa driver. |
| System-call mismatches | Certain syscalls are only present on newer kernels. | Update the host kernel or enable FEX_SYSCALL_MAP to emulate missing syscalls. |
| Performance on low-end ARM | JIT compilation can be heavy; caching helps but still requires ~1 GB RAM. | Enable FEX_ENABLE_CACHING and run on a machine with at least 8 GB RAM. |
| Constrained page size | ARM kernels often use 16 kB pages; x86 expects 4 kB. | Run a lightweight virtual machine with 4 kB page size via muVM or use the Asahi game-playing toolkit. |
| Security | Running arbitrary x86 code can expose the host to code that relies on privileged instructions. | Run FEX in a sandboxed container and restrict capabilities. |
FEX outperforms other proprietary solutions like Rosetta in some benchmarks, but the gap narrows on newer Apple silicon where Rosetta has hardware support for TSO Parallels Desktop: New x86 emulation on Apple Silicon (2026).
Quick FAQ
| Q | A |
|---|---|
| How does FEX handle rare x86 instructions without a direct ARM equivalent? | It falls back to a slower interpreter or a pre-compiled stub; newer releases (e.g., 2510) add support for many such instructions. |
| What is the performance difference between FEX and proprietary emulators like Rosetta or Prism? | Benchmarks show FEX can achieve up to 80 % of native frame-rates on certain games, while Rosetta may drop to 50 % on the same hardware. |
| How does FEX manage GPU driver differences across PowerVR and AMD GPUs? | FEX forwards Vulkan calls to the host driver; if the driver lacks Vulkan 1.3, it falls back to software rendering or requires a newer Mesa driver. |
| What are the limitations of FEX in terms of supported software and workloads? | FEX works best with CPU-heavy games; I/O-heavy workloads may see more overhead due to syscall translation. |
| How can users contribute to the FEX project and help improve compatibility? | Fork the repository, submit PRs for new instruction support, report bugs on GitHub, or help translate documentation. |
| What security considerations arise when running x86 binaries on ARM via FEX? | FEX runs in userspace; the only risk is the normal risk of running arbitrary code. The JIT layer can be sandboxed to mitigate escape attempts. |
| How does FEX integrate with various Linux distributions? | Packages exist for Fedora, Arch, and Debian; the project can be built from source on any distro that supports CMake and Clang. |
Conclusion
If you’re a developer or a gamer on an ARM64 machine and you want to run legacy Windows binaries, FEX is the tool that turns that dream into reality. It blends binary re-compilation, IR optimizations, and smart caching to deliver near-native performance without the proprietary lock-in of Rosetta.
- Who should use it? Linux gamers, software developers porting legacy code, and system engineers wanting a transparent x86 sandbox.
- Who should not use it? Users who need absolute stability for mission-critical workloads; the current release may still hit rare instruction bugs.
The roadmap for FEX is already clear: more AVX instructions, better memory-model handling, GPU driver integration, and a stable release for mainstream distros. If you’re interested, head to the GitHub repo, try a game, and share your findings on the community forum.
References
- FEX — FEX-Emu: Run x86 applications on ARM64 Linux devices (2026) https://github.com/FEX-Emu/FEX
- FEX 2405 Tagged! – FEX-Emu 2405 (2024) https://fex-emu.com/FEX-2405/
- FEX 2510 Brings More Optimizations For x86_64 Binaries On AArch64 (2026) https://www.phoronix.com/news/FEX-2510
- AAA Gaming on Asahi Linux (2024) https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/
- Parallels Desktop: New x86 emulation on Apple Silicon (2026) https://www.heise.de/en/news/Parallels-Desktop-New-x86-emulation-on-Apple-Silicon-10367607.html
- Development:Setting up Library Forwarding (2026) https://wiki.fex-emu.com/index.php/Development:Setting_up_Library_Forwarding
- JIT Compilation and Execution (2026) https://deepwiki.com/FEX-Emu/FEX/2.4-jit-compilation-and-execution
- x86 (2026) https://en.wikipedia.org/wiki/X86
- Circular buffer (2026) https://en.wikipedia.org/wiki/Circular_buffer
- FEX-Emu: Run x86 and x86-64 apps on ARM64 Linux devices (2026) https://ostechnix.com/fex-emu-run-x86-and-x86-64-apps-on-arm64-linux-devices/
