PS3 emulation is fast on ARM now

Tech summary (PS3 emulation on ARM / RPCS3)

• Major performance + efficiency claim: The video argues that RPCS3 emulation on ARM became ~60% faster while also being ~25% more power efficient (less power draw) compared to ~6 months earlier.
• Core approach: Use ARM architecture documentation (notably a 17,000+ page ARM reference manual) plus heavy instruction-level optimization of emulator-generated code, especially the SPU recompiler path.
• Target hardware for optimization: The presenter uses an AYN Odin 2 handheld (Android gaming handheld with Linux-capable options, cheaper than an ARM laptop) to port and tune RPCS3 for ARM performance.

---

Key bottleneck found: “busy wait” bug in a spin-loop

On ARM, a small function called busy wait was found to consume about half the CPU time due to a spin/busy-loop pattern.

What was wrong

• The busy-wait implementation was designed around x86 timer frequency assumptions.
• On the presenter’s ARM device:
  • The hardware timer runs at ~19 MHz
  • Timing granularity was ~150× slower than expected
  • Result: waits lasted ~150 microseconds instead of ~1 microsecond

Fix

• Scale busy-wait timeout by timer frequency to avoid excessive waiting.
• Reported impact:
  • ~25% average performance boost
  • ~10% average power reduction
  • Anecdotes include improved game framerate (e.g., Skylanders from 5–10 FPS to locked 30 FPS on an ARM MacBook).

Second issue inside busy-wait: ARM yield vs correct stalling

• ARM yield is a hint intended mainly for SMT systems.
• On most consumer ARM devices using SMP, yield effectively does little for this use case.
• Fix: replace yield with ISB (Instruction Synchronization Barrier) for more correct throttling (and some additional power savings).
• Note: ISB isn’t a perfect conceptual replacement for pause, but it works well enough for performance/power.

---

Recompiler / LLVM-generated code: big wins from fixing bad instruction lowering

The SPU recompiler uses LLVM to translate PS3 assembly → LLVM IR → native code for x86/ARM. The video claims ARM lagged due to LLVM codegen mistakes, then documents specific fixes.

ARM vs x86: where ARM can be naturally better (sometimes)

Several PS3-like operations map efficiently to ARM instructions, sometimes using fewer instructions than x86 (unless x86 has AVX-512). Examples mentioned:

• abs difference-style operations
• bit counting / CLZ / unsigned comparisons
• Some bitwise select/shuffle-related operations can be more direct on ARM

Major ARM-specific LLVM fix: SHFB emulation using better ARM shuffles

• Problem instruction: SHFB (PS3 shuffle)
  • Initially emulated by mapping to x86 SHF/PSHFB behavior
  • This led to very poor ARM codegen
• Optimization:
  • Rewrite SHFB lowering to use ARM TBL/TBX shuffle instructions correctly
  • Instruction count reduced significantly (described as ~10 → ~5, with further potential reductions discussed)
• Compatibility issue:
  • Using two-source TBX/TBL required constraints on the register allocator
  • LLVM could crash for some games
• Solution:
  • Catch compilation crash and retry using a fallback single-source TBX/TBL method
• Reported result:
  • ~8% performance uplift while preserving compatibility

---

Additional NEON/ARM instruction optimizations (instruction selection & LLVM workarounds)

The video describes multiple instruction-level improvements, often driven by LLVM generating suboptimal code.

• FCGT
  • LLVM failed to optimize correctly
  • Workaround uses inline assembly with BSL-based selection logic
  • Special handling noted due to SPU behavior differences (e.g., no NaN/infinity semantics on SPU)
  • Reduced sequence: 15 → 7 (claimed)
• FSM / “reverse of gather bits”
  • LLVM produced inefficient scalarized sequences
  • Workaround uses more idiomatic IR, ending with ARM compare/select ideas
  • ~3 instructions → ~2 instructions (described)
• Shift/rotate emulation issues
  • LLVM “poison”/undefined behavior around shifts caused extra instructions on ARM
  • Workaround: use specific intrinsics (e.g., USH path) to ensure correct masking/rotation semantics
  • Net effect: fewer instructions per shift/rotate

---

“More interesting” optimization: faster compare/checksum via multiply-accumulate

A novel micro-optimization targets a core behavior seen on Snapdragon 8 Gen 2 class designs (like the Odin 2).

Key idea

• Some ARM mid cores can handle many vector loads per clock, but have fewer vector arithmetic ops per clock (load-heavy vs ALU-heavy balance).
• Comparisons yield lane masks like all-ones (-1) or zero.
• Multiply comparison masks and accumulate:
  • Because (-1 × -1) = +1, the algorithm can count matches using multiply-accumulate instead of explicit logical operations.

Reported impact

• Mid cores: ~38%
• Larger cores: ~21%
• Also extended to checksum workloads:
  • Checksumming previously used unrolled code, then partially rolled into loops to improve instruction cache behavior
  • Combined gain: >5% uplift on ARM for targeted portions

---

SVE (Scalable Vector Extension): limited gains + complex reality

• The video explains how SVE predicates/masks differ from NEON.
• Practical issue:
  • Even if the CPU design supports SVE, Qualcomm disables SVE in the hypervisor on Odin 2
  • So the host environment may not report SVE

What the presenter did anyway

• Wrote SVE-targeted optimizations
• Tested via QEMU
• Implemented several SVE2-related improvements, including:
  • Better codegen for FMA-like sequences (e.g., F/MLS vs FMLA patterns)
  • More efficient SVE widening multiply mappings
  • More efficient vector rotate emulation using XR with SVE2 encodings

Validation claim

• On a newer Snapdragon laptop demo unit (Best Buy), they observed about ~10% uplift in a synthetic loop heavy in multiplies (not necessarily representative of full emulation).

Rollout observation

• SVE enablement can be inconsistent across vendors/chips.
• The talk contrasts this with how AVX-512 availability differs based on platform support.

---

Power-saving optimization: waiting on cache lines (WFE + LDAXR)

For spinlocks in GPU emulation, low-power waiting uses ARM primitives:

• LDAXR + WFE to sleep until a cache line changes

Measured impact

• Desktop: power reduced by a few watts in locked-framerate scenarios
• Odin 2: smaller but still measurable savings (anecdotally)

---

Performance “results framing” and device expectations

The presenter frames results differently for desktop vs Odin 2:

• On desktop, bottlenecks are clearer (compute/memory/power limits).
• On Odin 2:
  • GPU and CPU compete for shared resources
  • Heat/power budgets constrain what “wins” translate into overall performance
  • After CPU optimizations, some bottlenecks may shift (e.g., games becoming GPU-limited instead of CPU-limited)

Benchmarks mentioned

• CellMark: emulator runs at roughly ~78% of PS3 speed on Odin 2, despite not reaching full target clock parity
• Mentions core-speed distribution (e.g., X3 doing better than A715/A710/A510-class cores)

---

Main speakers / sources

Primary speaker/source

• The video presenter/developer narrating the RPCS3 ARM optimization work

Named projects/people referenced

• Nekotekina
  • Former RPCS3 lead developer
  • Initial ARM port, exited before recompiler completion
• KD-11
  • Graphics developer who enabled the recompiler and worked on graphics backends
• DH
  • Developer/founder associated with RPCSX, an Android PS3 emulator

Project/source materials cited

• RPCS3 (upstream emulator codebase)
• ARM architecture reference manual (17,000+ pages)
• LLVM (IR/native code generation behavior and codegen issues)
• ARM blog posts and GitHub issues/PRs (for yield/ISB busy-wait porting and LLVM codegen workarounds)