FEX-Emu 2610: AVX-VNNI and a 1GB Cap for the Disk Cache

By Indie Kings | October 30, 2026

Updated October 30, 2026: FEX-Emu, the usermode x86 and x86-64 emulator for Arm64 Linux, shipped FEX-2610 on October 7, 2026 with AVX-VNNI support and a 1GB cap on its disk cache. The repository reports 8,357 stars, 419 forks and 84 contributors, is MIT licensed, and was created on March 6, 2020.

Image: a Raspberry Pi 5 board, one class of Arm64 Linux device that can run FEX, via Wikimedia Commons.

x86 on Arm64, with thunks

FEX lets an Arm64 Linux machine run x86 applications, including 32-bit and 64-bit binaries, in the same spirit as qemu-user and box64. The part that matters for games is the pairing with Wine and Proton. FEX translates the CPU instructions, while Wine and Proton translate the Windows API calls, which is how an Arm64 laptop or single board computer can run a Windows game without a full system emulator.

The design avoids emulating the GPU. FEX forwards graphics API calls to the host's OpenGL or Vulkan libraries, so the game talks to the native Arm driver through a thunk layer instead of a software renderer. That is why the project can claim broad compatibility without owning a graphics stack. It also means the quality of the result depends on the host driver, the game's use of extensions, and the thunk coverage for whatever the engine calls. The README describes an experimental code cache to reduce in-game stuttering, a per-application configuration system for tuning performance, and a FEXConfig GUI for exploring those settings.

The requirements are specific. FEX needs ARMv8.0-a or newer hardware with the FEAT_FP and FEAT_CRC32 extensions. It has been tested on Arch Linux, Fedora, openSUSE and Ubuntu 22.04, 24.04, 24.10 and 25.04, though other distributions are likely to work. An x86-64 RootFS is required, and FEXRootFSFetcher can download one for many distributions. On Ubuntu, a single install script walks through the PPA and the RootFS. The project is not a drop-in package for every distro, and the RootFS is a real dependency rather than a detail.

The target devices are broader than a desktop tower. Arm64 Linux covers Raspberry Pi boards, Snapdragon laptops, Ampere and Grace servers, and handhelds running Arm chips. The release notes mention DGX Spark by name in the Vulkan section, which is a reminder that this is not only a retro gaming tool. Any Arm64 Linux machine that needs to run an x86 binary is a candidate, and games are simply the most demanding test.

What 2610 changes in the JIT

FEX-2610 is a monthly release, and its JIT section is a list of small compatibility wins rather than a headline rewrite. The biggest addition is AVX-VNNI support, an instruction set extension that some game libraries are beginning to use. Without it, a library that detects the extension or compiles a path around it can fail in ways that look like a game bug rather than an emulator gap.

The release also optimizes SSE4.2 string operations, which are common in game code and in the libraries underneath it. 3DNow! is enabled again after the last known bug was fixed, which matters for older titles and for software that still carries the instruction path. The x87 FXAM instruction got better emulation because Mono uses it to detect denormals, a detail that explains why a .NET game can behave differently under translation. There is also a peephole optimization for a common case of an unmasked AVX gather instruction, which some sound libraries rely on.

The most consequential change may be the software fallback for RDRAND and RDSEED. These are hardware random number instructions, and some programs refuse to run unless they exist. FEX can now emulate them in software, but the fallback is not enabled by default because it is slower than a hardware implementation. The release notes also call out Qualcomm Oryon platforms, where the hardware random number implementation is bugged and does not return real values. For those machines, the software path is not a performance trade, it is a correctness fix.

None of this is a GPU breakthrough, and the release does not pretend otherwise. The JIT changes are about closing gaps that individual games or libraries hit, one instruction at a time. That is how an emulator matures: not with a single compatibility switch, but with a long list of small fixes that move a title from crashing to playable.

A 1GB cache cap and cleaner upgrades

The disk cache changes are the practical improvement most users will notice. When the cache is enabled, FEX now limits it to 1GB by default and stops caching at that point. The limit is configurable in the INI options, but the default exists because some edge cases allowed the cache to grow without bound. A 1GB ceiling is a reasonable balance between reuse and disk consumption, especially on a handheld or a small SSD.

There is also an optional in-memory cache for hot blocks. The release notes are careful about when it helps: it is worth using only if a game stutters frequently from JIT invocations and the machine has spare RAM. That is a narrow case, and the project does not present it as a universal speedup. The more useful change is automatic cleanup. When FEX updates, it removes old disk caches that are not relevant to the new version, so users do not accumulate multiple 1GB files as they upgrade.

Two smaller fixes round out the cache work. For ELF files, FEX now uses an embedded GNU build-id hash as a partial key, which helps when a file has been replaced and an outdated cache could otherwise be reused. And the Vulkan thunks were upgraded to fix minor bugs with newer drivers, which the release says fixes some games on DGX Spark that were using newer Vulkan extensions. Neither change will make headlines, but both reduce the class of bug where the emulator is blamed for a stale cache or a driver mismatch.

The project still carries 266 open issues and pull requests, and a monthly cadence means fixes arrive in batches. FEX-2609 shipped on September 8 and FEX-2608 on August 5, so 2610 is the October entry in a steady rhythm. The latest commit on October 29 is a merge from the maintainer's branch, which is normal for a project where the release is a snapshot of ongoing work rather than a frozen branch.

Project card

FAQ

What is FEX-Emu?
A usermode x86 and x86-64 emulator for Arm64 Linux, comparable in role to qemu-user and box64.

Can it run Windows games?
Yes, when paired with Wine or Proton. FEX translates the CPU instructions and the Windows layer handles the operating system calls.

What hardware does it need?
ARMv8.0-a or newer with the FEAT_FP and FEAT_CRC32 extensions, plus an x86-64 RootFS.

What is new in FEX-2610?
AVX-VNNI support, faster SSE4.2 string operations, 3DNow! re-enabled, a RDRAND and RDSEED software fallback, a 1GB disk cache cap and Vulkan thunk fixes.

Why cap the disk cache?
Some edge cases allowed unbounded growth. The 1GB default is configurable and keeps upgrades from leaving several large cache files behind.

Does it work on a Steam Deck?
The Steam Deck is x86-64, so FEX is not the tool for it. FEX targets Arm64 Linux devices.

Bottom Line

FEX-2610 is a maintenance release, but the kind that decides whether a game launches. AVX-VNNI, faster string operations and a software RDRAND fallback close gaps that individual titles hit, while the 1GB cache cap and automatic cleanup make the emulator less likely to waste disk space or reuse a stale block. The project remains a translation layer, not a graphics emulator, so the host driver and the game's extension use still matter. On an Arm64 Linux machine with a working Vulkan driver, this is the release to try before the next monthly snapshot.

Sources

• GitHub FEX-Emu/FEX release FEX-2610, JIT, disk cache and Vulkan thunk notes, published October 7, 2026
• GitHub FEX-Emu/FEX Readme.md, purpose, requirements, tested distributions, RootFS and configuration, accessed October 30, 2026
• GitHub API metadata for FEX-Emu/FEX, stars, forks, contributors, issues, size and latest commit, accessed October 30, 2026

Related: Snapintosh: macOS 27 Boots on a Snapdragon X2 Laptop With Its Own Adreno Metal Driver | vkd3d-proton 3.1: Descriptor Heaps and Shader Model 6.9