Xenia Canary and xemu Release New Builds With ARM64 and Vulkan Improvements

Six targeted ARM64 optimizations landed in Xenia Canary's March 31 build, closing out a sprint of low-level code generation work that chips away at the performance gap between Xbox 360 emulation on ARM hardware and its x86_64 counterpart. The same week, xemu pushed a development snapshot that addressed a long-standing crash in its Vulkan pipeline and patched the "Load Disc" UI failure that had been quietly catching users off guard since the v0.8.134 stable release.

The Xenia Canary changes, tagged at commit d2c8ca6, are entirely focused on the A64 code generator, which translates Xbox 360 PowerPC instructions into native ARM64 machine code at runtime. The most consequential entries: FPCR switching now uses lazy mode tracking rather than reloading the floating-point control register on every transition, and V128 bit-shifts are inlined using NEON instructions, eliminating the C helper thunks that added overhead on every vector operation. Three additional entries optimize the DIV, MUL_HI, SWIZZLE, and LOAD_VECTOR_SHL/SHR instruction families; a sixth adds ARM64 bitmask immediates for AND, OR, and XOR with constant values, shaving instruction count on common bitwise operations. None of this is cosmetic: every removed thunk call and every avoided register reload translates directly into JIT throughput, which matters most in the titles sitting just below the playable threshold.

That threshold is precisely why the canary channel exists. Xenia Canary pushes experimental changes faster than mainline can safely absorb them, and it occasionally introduces regressions as a result. The practical split: keep a stable build for everyday library verification and use canary on a dedicated test machine pointed at the titles you most want to see cross the compatibility line.

On the xemu side, the March 23 pre-release at commit 45f4137 was primarily the work of contributors mborgerson and abaire. The headline fix relaxed and simplified the surface-to-texture constraint logic in the NV2A Vulkan path, reducing the surface of driver-specific behavior that had been producing rendering failures across different host GPUs. A commit from xemu-robot bumped SPIRV-Reflect to vulkan-sdk-1.4.341.0, keeping the shader reflection layer current with the SDK. For macOS users on Apple Silicon, mborgerson updated the library download script to correctly target Darwin 23 for the arm64 build, resolving a breakage under recent macOS releases. Abaire separately patched the SDL_ShowOpenFileDialog call to stop passing a missing path, which resolved the crash documented in issue 2785: whenever a user's games directory had been moved or deleted since initial setup, hitting "Load Disc" would immediately take down the emulator.

If you want to help push a title from boots to playable, the most useful contribution is a focused bug report tied to a specific build. Run the latest canary or dev snapshot, reproduce the failure, and capture the full session log immediately after. For Xenia Canary, the log writes to the same directory as the executable; for xemu, "File > Open Log File" surfaces the current session. When filing a GitHub issue, include your host CPU model, GPU model, driver version, and the exact build commit shown in the emulator's title bar. Build hashes like d2c8ca6 and 45f4137 exist so developers can bisect regressions precisely: a report that cites the commit hash is worth ten that say "latest version.