Brian Degenhardt
3410a08c2b
Depth written from the pixel shader does not bit-match the fixed-function interpolation that a later read-only pass tests against on Apple GPUs, so a GEQUAL retest of the same geometry drops out along shared triangle edges and whatever was drawn underneath shows through as pinpoints of light. Black (SLUS-21376) speckles white over dark walls; God of War II's Athena statue speckles blue. The PS2 32-bit Z floor is the only reason a depth-writing draw takes the gl_FragDepth path at all. Its arithmetic is exact -- z*2^32, floor, *2^-32 is an integer op between two exponent shifts -- and it only ever lowers the stored value, so it masks the mismatch rather than causing it. Stray pixels on a Black wall against the software renderer, Vulkan on an M2 Max: floor + gl_FragDepth (shipping) 748 gl_FragDepth, floor removed 7062 floor - 1 Z unit 0 floor + 1 Z unit 263082 no gl_FragDepth at all 0 The disagreement is therefore under one PS2 Z unit, and a coplanar retest has no margin to absorb it. OpenGL reproduces at exactly 748 as well, which rules out the API and leaves the hardware. Whole-frame divergence from the software oracle drops 762 -> 2 on Black; the God of War II and NFS Underground dumps are unchanged. This is what no_ps2_z_quantization already does for Mali, and the floor only landed in January, so opting out returns Apple to long-standing behaviour. Wire the flag up for Metal and OpenGL too, neither of which read it before -- Metal is how Mac and iOS actually reach this, and it is the only backend the bug was reported on. Both now honour the INI override as well. Vulkan gates on driverID rather than vendorID because Apple silicon reports whoever wrote the driver: Honeykrisp is Mesa's 0x10005, not Apple's 0x106B. OpenGL matches on GL_RENDERER for the same reason -- an Intel Mac reports vendor "Apple Inc." with an AMD GPU. Mali is deliberately left out of the OpenGL gate; the Vulkan path opts it out for early-ZS, but that has not been tested on a Mali GL driver. The Metal change is uncompiled -- those translation units only build on macOS.
ARMSX2 — Native ARM64 JIT Fork of PCSX2
ARMSX2 is a free and open-source PlayStation 2 (PS2) emulator based on PCSX2. Its purpose is to emulate the PS2's hardware, using a combination of MIPS CPU Interpreters, Recompilers and a Virtual Machine which manages hardware states and PS2 system memory. This allows you to play PS2 games on your phone, PC, or gaming handheld, with many additional features and benefits.
Thank You
The ARMSX2 team is eternally indebted to the PCSX2 project it is based on. We are so fortunate to build on their 20 years of hardcore development.
About This Fork
The upstream PCSX2 project ships an ARM64 interpreter build for ARM, but its high-performance JIT recompilers (EE, IOP, VU0, VU1, and vtlb fast memory) are x86-64 only.
This fork exists to close that gap. The goal is to preserve the correctness features of 20 years of PCSX2 development, while generating the fastest native ARM performance possible.
Current status:
- ✅ EE (Emotion Engine) recompiler — integer, float, MMI, COP0/COP1/COP2, branches, load/store
- ✅ IOP (I/O Processor / R3000A) recompiler — full integer, load/store, branches, coprocessors
- ✅ VU (Vector Unit) recompiler — microVU skeleton + Upper FMAC vector ISA complete; Lower ISA and runtime complete
- ✅ vtlb fast memory
- ✅ Native ARM64 binary builds and boots the PS2 BIOS
- ✅ 2D games are already playable
- ✅ 3D games run
Why LLMs / AI Were Used
A word on methodology:
The x86-64 JIT code in upstream ARMSX2 is already proven correct — it has run thousands of PS2 titles for years. The challenge in this port is not emulator design or JIT theory; it is mechanical translation of a large, well-understood x86-64 assembly codebase into equivalent ARM64 assembly (via VIXL) while preserving the exact same register-allocation contracts, block lifecycle, and recompiler semantics.
Large language models (LLMs) were used as an accelerant for this translation work — pattern-matching x86 JIT boilerplate to ARM64 equivalents, scaffolding emit routines, and keeping the porting velocity high. The JIT logic (block compiler, dispatcher, analysis passes, flag pipelines, clamping rules, Tri-Ace hacks, etc.) is taken directly from the upstream x86 implementation and validated against it. Nothing was hallucinated from scratch.
In other words: the hard engineering was done by the PCSX2 team over two decades. The hard typing — translating ~50k lines of x86 emitter code into ARM64 — is what AI helped compress.
System Requirements
ARMSX2 targets ARM64 across desktop (macOS, Windows, Linux) and mobile (Android, iOS/iPadOS), all from the single shared core. Our setup documentation page contains additional details on software and hardware requirements.
Please note that a BIOS dump from a legitimately-owned PS2 console is required to use the emulator. For more information, visit this page.
Building
Check out our github actions for the latest build recipe