Inside AnyPS5: static ELF relinking, NID symbol resolution, the 5-stage RDNA 2 shader recompiler, and what '100% shader coverage' means

In early October 2026, reports in Tom's Hardware, VideoCardz, TechPowerUp, and GIGAZINE covered a milestone in the open-source boykopovar/AnyPS5: the GPU shader instruction counter reached 100.0% (1,166 / 1,166 instructions), while system-library implementation rose from 84.76% (2,575 / 3,038) on October 9 to 88.3% (3,239 / 3,668) in the October 14, 2026 upstream snapshot.

When those numbers appeared alongside desktop clips of commercial titles (Animal Well, PAC-MAN WORLD Re-PAC, Dead Cells) and first-party bring-up tests (Demon's Souls, Astro Bot, Gran Turismo 7, Ghost of Yōtei), two misconceptions spread quickly in forum threads. First, many readers assumed the project boots PlayStation 5 firmware inside a virtual machine or JIT-translates CPU instructions frame by frame like a seventh-generation console emulator. Second, seeing a 1,166 / 1,166 shader badge and an 88.3% library counter led players to ask why Demon's Souls still freezes on Continue Offline or why Ghost of Yōtei stalls on its splash screen.

The upstream C++23 source tree answers both questions directly. Inspecting the ARCHITECTURE.md specification, the static relinker pipeline under core/relinker/, the replacement .prx runtime in core/libs/prx/, the 5-stage shader compiler in core/gpu/Shaders/Recompiler.cpp, and the AST/token scanner documented in docs/dev/PROGRESS.md shows how AnyPS5 converts a clean PS5 ELF into a native Windows or Linux executable, how its runtime maps FreeBSD-derived Sony kernel semantics onto Win32 and POSIX primitives, and why per-commit behavior is tracked separately in the community AnyPS5 guide.

1. Static binary relinking vs. virtual machine emulation

Console emulators for architectures like PowerPC or the Cell Broadband Engine (such as RPCS3) translate a foreign CPU instruction set into x86-64 or ARM64 machine code through an ahead-of-time (AOT) or just-in-time (JIT) recompiler while emulating privileged supervisor states.

Because the PlayStation 5's AMD Zen 2 CPU is already an x86-64 processor executing unprivileged user-space instructions for game code, AnyPS5 skips CPU virtualization. Similar to Wine and Proton on Linux or user-mode translation layers like spine and shadPS4, it divides execution into offline static relinking and runtime library replacement.

Figure 1: The two-phase AnyPS5 execution model: offline static binary relinking (core/relinker/) paired with build-time NID export patching (nid_patcher) and host OS loader resolution.

Inside core/relinker: from Orbis/Prospero ELF to host PE/ELF

When you run the relinker on a clean, decrypted PS5 executable (eboot.bin or input.elf; encrypted packages and SELF/fSELF containers are rejected during header validation), the CLI entrypoint (core/relinker/main.cpp) passes the input tree to RelinkerPipeline (core/relinker/RelinkerPipeline.cpp).

RelinkerPipeline parses the PlayStation ELF segments, dynamic tables, and module import descriptors, and emits a native host executable without wrapping the guest binary in a custom loader stub:

• For the default Linux x86-64 target, the relinker rebuilds the ELF program headers, dynamic symbol tables (.dynsym / .dynstr), and relocation tables so the standard Linux dynamic linker (ld-linux-x86-64.so.2) can map and execute the binary directly.
• For the Windows x86-64 target (--windows), it reconstructs the binary as a Portable Executable (.exe) with a standard PE32+ header, Import Address Table (IAT), and section layout compatible with the Windows NT loader (ntdll.dll). It pins the image base to a 64 KiB-aligned non-ASLR address (--windows-fixed-base <address>, constrained between 0x20000 and 0x7fffffff0000).
• For companion guest modules, GuestModuleBuilder (core/relinker/GuestModuleBuilder.cpp) converts the engine plugins, audio middleware, and physics libraries bundled inside sce_module/, sce_modules/, or prx/ into matching host shared libraries while preserving their relative runtime paths under app0/.

Static instruction rewriting: --to-intel, --to-rosetta, and dead-export compaction

Although both the PS5's Zen 2 CPU and a desktop PC use x86-64, instruction set extensions and microarchitectural behaviors differ across AMD, Intel, and Apple Silicon (Rosetta 2) hosts. During static analysis, the relinker can decode and rewrite executable code sections before emitting the final binary:

--to-intel operates strictly at relink time. If a game's scripting VM or anti-tamper layer generates AMD-specific opcodes into executable heap pages at runtime, a static relinker never sees those bytes.

2. Clean-room .prx system libraries and the NID linking mechanism

Once the relinker emits app.exe (or app.elf), the binary still needs to call PlayStation 5 operating system services without Sony firmware.

On a physical PS5, executables rarely import system functions by human-readable C names like sceKernelMapDirectMemory. Instead, the PlayStation toolchain links against NIDs (Name Identifiers), which are 11-character Base64-like cryptographic hashes derived from the symbol name and a Sony ABI obfuscation suffix stored in the import table.

How nid_patcher turns standard C++ into NID exports

The core/libs/prx/ directory in the upstream repository contains more than 80 module subdirectories (libkernel, libSceAgc, libSceAgcDriver, libSceAudioOut, libScePad, libSceSaveData, libSceSysmodule, libSceVideoOut, and others). Each directory compiles into a standard host dynamic library named <module>.prx inside the runtime libs/ folder.

Writing C++ functions named after raw 11-character NID hashes would make the codebase unreadable and fail to compile whenever a hash contains characters outside [A-Za-z0-9_] (such as + or -). AnyPS5 handles this with a two-step build process documented in ARCHITECTURE.md:

1. Developers write standard C++ functions using descriptive symbol names and annotate them with APS5_VABI (enforcing the System V AMD64 ABI used by PS5 guest code, even on Windows where the host ABI is Microsoft x64) and APS5_EXPORT("<nid>", func).
2. After CMake links each .prx dynamic library (cmake/PrxLibrary.cmake), the build runs nid_patcher (tools/nid_patcher/main.cpp). nid_patcher parses the compiled ELF .dynsym/.dynstr or PE Export Address Table (EAT) and overwrites the exported symbol string in place with the 11-character NID.

Because both the relinked game binary (app.exe / app.elf) and the host .prx libraries now share identical NID symbol strings, the operating system's native loader (ntdll.dll on Windows, ld.so on Linux) binds thousands of PS5 system calls at process startup without runtime hash-lookup overhead.

Figure 2: Inside libkernel.prx: avoiding Windows DllMain loader-lock deadlocks via __aps5_guest_initialize (top) and servicing asynchronous file/memory batches via dual APR/AMM worker queues (bottom).

Inside libkernel.prx: bridging three OS mismatches

Replacing high-level libraries like libScePad (mapped to SDL3 gamepads and anyps5-input.ini profiles) is relatively direct. The harder systems work sits inside core/libs/prx/libkernel/, where FreeBSD-derived Orbis/Prospero kernel semantics meet Windows NT and Linux kernel rules.

A. Escaping the Windows DllMain Loader Lock (DynamicLoader.cpp)

On a PS5, dynamically loaded guest .prx modules execute their static constructors (_init / .init_array) with full freedom to spawn threads, allocate direct memory, or load additional modules. On Windows, running guest initialization inside DllMain(DLL_PROCESS_ATTACH) while the NT loader holds the global Loader Lock causes immediate deadlocks if guest code spawns a thread or calls LoadLibrary.

As implemented in core/libs/prx/libkernel/DynamicLoader.cpp and documented in ARCHITECTURE.md, the relinker emits a metadata table named __aps5_guest_initialize into converted Windows modules instead of wiring guest constructors into DllMain. The header of this table holds an atomic 32-bit state word:

• 0: Uninitialized.
• UINT32_MAX (0xFFFFFFFF): Initialization completed.
• Any other non-zero value: The Win32 Thread ID (GetCurrentThreadId()) of the thread currently initializing the module.

After LoadLibrary returns and the Windows Loader Lock is released, libkernel walks the module's dependency graph depth-first, uses compare-and-swap on the state word to claim ownership (allowing recursive re-entry by the same Thread ID while blocking concurrent threads until UINT32_MAX is written), and executes the module's initialization pointers in normal user context.

B. FreeBSD libthr-modeled pthread cancellation (Thread.cpp & Cancel.hpp)

PlayStation 5 system threads use POSIX thread cancellation (scePthreadCancel, deferred vs. asynchronous modes, and cleanup handler stacks). On Windows, and across different libc implementations, native thread termination does not match Sony's cancellation-point semantics.

To match those rules across platforms, core/libs/prx/libkernel/Thread.cpp and Cancel.hpp port the cancellation state-machine design from FreeBSD's libthr (thr_cancel.c and thr_exit.c). Blocking libkernel calls wrap waits in CancelPointScope, checking per-thread cancellation flags before and after kernel waits and unwinding registered guest cleanup handlers in LIFO order before exiting the thread.

C. Asynchronous I/O and memory command buffers (Apr.cpp)

PS5 games stream multi-gigabyte assets using APR (sceKernelAprSubmitCommandBuffer*) and AMM (sceKernelAmmSubmitCommandBuffer*). Instead of issuing individual synchronous read() or mmap() syscalls, the game builds a command packet stream in memory that combines file reads, priority changes, memory mappings, and completion event flags, then submits the batch.

In core/libs/prx/libkernel/Apr.cpp, AnyPS5 uses a dual-queue worker design:

1. A submission parser (ParseCommands / ParseAmmCommands) validates the guest command buffer and assigns a monotonically increasing tracking ID (id = m_nextId++).
2. File I/O batches go to the APR Worker Thread, while virtual and direct memory mapping batches go to the AMM Worker Thread, allowing disk reads and page-table updates to run concurrently.
3. Synchronous variants (*AndGetResult) block only on the specific submission's condition variable (WaitCompletion), while asynchronous batches signal guest event flags or completion buffers (WriteResult) in the background.

3. The 5-stage RDNA 1/2 to SPIR-V shader recompiler

The PlayStation 5 GPU is based on an AMD RDNA 2 architecture programmed through Sony's low-level AGC (libSceAgc / libSceAgcDriver) graphics API. Game engines pre-compile shaders into proprietary AMD GCN/RDNA machine code binaries and submit draw and compute work via Draw Command Buffers (DCB) and Asynchronous Compute Buffers (ACB) encoded with PM4 packets.

Desktop PCs cannot execute raw PS5 AGC command buffers or console-specific RDNA machine code directly. The host runtime in core/gpu/ translates both the command stream (core/gpu/Execution/Pm4.cpp) and the shader binaries (core/gpu/Shaders/Recompiler.cpp) into Vulkan 1.1 and Khronos SPIR-V.

Figure 3: The end-to-end graphics pipeline in core/gpu/, from AGC PM4 packet decoding to the 5-stage shader recompiler (Recompiler.cpp) and Vulkan 1.1 pipeline creation.

Walking through core/gpu/Shaders/Recompiler.cpp

When the PM4 command processor encounters a draw or dispatch packet (DrawIndexAuto, DrawIndex2, DispatchDirect), it hashes the active shader binary and execution state (stage, user SGPR layout, vertex/export attributes). On a cache miss in the Variant Cache, Recompiler.cpp runs five stages:

1. Stage 1 (RdnaDecoder, core/gpu/Shaders/RdnaDecoder.cpp): Parses the binary instruction stream across all seven RDNA 1 and RDNA 2 encoding families defined in the AMD RDNA 2 Instruction Set Architecture Reference Guide:
   • SOP (SOP1, SOP2, SOPC, SOPK, SOPP): Scalar ALU operations, wave branches, and barrier/waitcnt control (s_waitcnt, s_barrier).
   • SMEM: Scalar memory loads for constant buffers, descriptor tables, and root user data.
   • VOP (VOP1, VOP2, VOP3, VOP3P, VOPC): Vector ALU floating-point and integer math, packed FP16 dot products, and wave-wide condition mask (VCC / EXEC) updates.
   • MIMG: Multi-dimensional image sampling, mipmapped fetches, and typed texture reads and writes.
   • DS: Local Data Share (LDS) workgroup shared memory atomics and swizzles.
   • FLAT / GLOBAL / SCRATCH: Unified 64-bit Buffer Device Address (BDA) pointer loads, stores, and atomics.
2. Stage 2 (ControlFlow, core/gpu/Shaders/ControlFlow.cpp): RDNA hardware manages divergent branches by manipulating the 32-lane or 64-lane EXEC (Execute Mask) register (s_and_saveexec_b64, s_or_b64 exec, s_cbranch_execz). SPIR-V requires structured control flow (OpSelectionMerge, OpLoopMerge) under the Khronos SPIR-V Specification. ControlFlow.cpp reconstructs a control-flow graph (CFG) of basic blocks, recovers structured loops and conditional branches from EXEC mask manipulations, and synthesizes divergence merge blocks.
3. Stage 3 (Translation, core/gpu/Shaders/Translation.cpp): Lowers decoded RDNA instructions within the structured CFG into an intermediate representation. Scalar (s0..s105) and vector (v0..v255) register accesses map to SSA values, and console descriptor table pointers fetched via SMEM bridge to Vulkan descriptor bindings and VK_KHR_buffer_device_address 64-bit pointers.
4. Stage 4 (Optimization, core/gpu/Shaders/Optimization.cpp): Runs dead-code elimination, constant folding, and flag coalescing so redundant scalar status bit calculations (SCC) and unused EXEC mask saves do not bloat the generated SPIR-V module.
5. Stage 5 (SpirvBackend, core/gpu/Shaders/SpirvBackend.cpp): Emits the binary SPIR-V word stream and passes it to Khronos SPIRV-Tools (spvtools::Optimizer) before calling vkCreateShaderModule.

Build-time patch for Khronos SPIRV-Tools:
In cmake/PatchSpirvTools.cmake and docs/dev/TechnicalDebt.md, the build applies a local patch to the SPIRV-Tools submodule referencing KhronosGroup/SPIRV-Tools PR #6962. Unpatched upstream SPIRV-Tools showed high memory growth when optimizing large machine-translated shaders with dense control-flow graphs during runtime uber-shader compilation.

4. Deconstructing the upstream progress metrics: why 100% shaders ≠ 100% compatibility

The Python scanner in tools/progress.py generates the repository's headline counters. Understanding its rules explains two patterns that often confuse readers following AnyPS5 progress.

Figure 4: Historical trajectory of AnyPS5's upstream progress counters (Sept 28 to Oct 14, 2026) and the AST/token counting rules in tools/progress.py.

Rule 1: how tools/progress.py counts system libraries (3,239 / 3,668, 88.3%)

According to docs/dev/PROGRESS.md, tools/progress.py does not compare the codebase against a master list of every undocumented function in Sony's PS5 firmware. Instead, it scans the C and C++ source files listed in core/libs/prx/*/CMakeLists.txt:

1. It strips comments and preprocessor directives, then locates every function definition annotated with the APS5_VABI calling-convention macro.
2. It tokenizes the function body ({ ... }). If the body contains the stub marker NotImplemented_nid_no_patch (or matches a recognized placeholder stub pattern), the function is counted as unimplemented. Any other non-stub APS5_VABI function body is counted as implemented.
3. If two .prx targets share a common .cpp file (shared_sources), the script deduplicates those definitions so they are counted once in the global total.

Why the percentage dipped on October 8 while implemented functions increased

The commit timeline in Figure 4 (tracked on the AnyPS5 progress dashboard) shows how denominator changes affect the ratio:

Between October 5 (75159a62) and October 8 (1ff271fa), contributors implemented 49 new functions (2,511 → 2,560), yet the reported percentage dropped from 86.02% to 84.60%. During those three days, developers declared 107 newly discovered imports across .prx modules to test additional games, expanding the denominator from 2,919 to 3,026.

In addition, tools/progress.py marks a function as implemented as soon as it is no longer a NotImplemented_nid_no_patch stub. An early function that returns SCE_OK (0) or populates default struct fields carries the same weight in the numerator as the full implementation of sceKernelAprSubmitCommandBuffer.

Rule 2: why 1,166 / 1,166 shader coverage only measures Stage 1 (RdnaDecoder)

As Tom's Hardware's Zak Killian wrote when covering the milestone, reaching 100% shader instruction coverage is a major step forward, "but playing all PS5 games natively on PC is still far off."

In tools/progress.py, the 1,166 / 1,166 counter checks whether Stage 1 (RdnaDecoder.cpp) recognizes every instruction entry in the project's enumerated RDNA 1 and RDNA 2 instruction table across DS, FLAT, GLOBAL, MIMG, SMEM, SOP, and VOP.

Even when RdnaDecoder decodes 100% of a game's shader opcodes without throwing an unknown-instruction abort, a frame must still pass Stages 2 through 5 and the AGC command processor:

• Control-flow structuring edge cases (Stage 2): Complex wave-ballot loops or irreducible EXEC-mask state machines can still trip SPIR-V structured merge rules.
• Resource and descriptor semantics (Stage 3 and PM4): If an AGC PM4 packet binds a depth-stencil surface, HTILE metadata buffer, or DCC-compressed render target using a layout mode not yet handled by Pm4.cpp, the shader executes against zeroed or misaligned memory.
• Vulkan pipeline barriers and synchronization: On the PS5's unified memory architecture, shaders rely on hardware L2 cache coherency and s_waitcnt / s_barrier semantics. On a PC discrete GPU over PCIe, missing a vkCmdPipelineBarrier between an asynchronous compute pass and a graphics draw causes black screens, flickering geometry, or device-lost (VK_ERROR_DEVICE_LOST) crashes without changing the 1,166 / 1,166 shader counter.

5. Case studies: how architecture explains per-game reports

The test configurations cataloged in the AnyPS5 games database and interactive AnyPS5 game checker show which architectural layer each game exercises:

Because behavior shifts across commits and branches, the AnyPS5 game checker records each report as a separate configuration card tied to its branch, commit hash, operating system, launch route, and eight verification checks (Launch, Menu, Gameplay, Finish, Audio, Inputs, Saves, Stability).

6. Building and testing AnyPS5 locally

To inspect the codebase or test a clean, decrypted ELF that you have the legal right to use:

1. Match your release artifacts: Pair relinker-v0.1.2 with the matching prx-windows-v0.1.2.zip or prx-linux-v0.1.2.tar.gz archive from the same tag, or build both the relinker and libs CMake targets from the same commit (cmake --build build --config Release --target relinker --parallel and --target libs).
2. Verify host hardware and OS limits first: Check your Vulkan 1.1 driver, host RAM plus pagefile commit margin (up to 13,824 MiB of direct memory on Windows), and /dev/udmabuf permissions on Linux against the AnyPS5 requirements reference.
3. Keep libs/ and app0/ separated: Place AnyPS5's host .prx libraries (plus libgcc_s_seh-1.dll, libstdc++-6.dll, and libwinpthread-1.dll on Windows) inside libs/, and place converted guest modules inside app0/ at the relative paths printed by Guest module: during relinking. Step-by-step commands are documented in the AnyPS5 setup and AnyPS5 GitHub guides.

References and primary sources

1. Upstream architecture specification (boykopovar/AnyPS5): docs/dev/ARCHITECTURE.md (commit a48c0066), covering the static relinker pipeline, nid_patcher symbol rewriting, __aps5_guest_initialize deferred Windows initialization, FreeBSD-modeled pthread cancellation, APR/AMM workers, and the 5-stage shader recompiler.
2. Upstream progress scanner rules (boykopovar/AnyPS5): docs/dev/PROGRESS.md (commit 43349d43), defining how tools/progress.py counts APS5_VABI definitions, NotImplemented_nid_no_patch stubs, shared_sources deduplication, and RdnaDecoder.cpp instruction recognition.
3. Upstream technical debt and SPIRV-Tools patch (boykopovar/AnyPS5): docs/dev/TechnicalDebt.md (commit a48c0066) and KhronosGroup/SPIRV-Tools Pull Request #6962.
4. Zak Killian, Tom's Hardware (Oct 10, 2026): AnyPS5 project reaches critical GPU milestone in race to enable running PS5 games natively on PC.
5. WhyCry, VideoCardz (Oct 9, 2026): AnyPS5 reaches 100% GPU shader instruction coverage for PS5-to-PC conversion.
6. TechPowerUp (Oct 2026): AnyPS5 Achieves Full PS5 GPU Shader Instruction Translation.
7. GIGAZINE (Oct 9, 2026): AnyPS5 is an open-source tool that allows you to play PS5 games on Windows and Linux.
8. AMD RDNA 2 Instruction Set Architecture Reference Guide: AMD GPUOpen / TechDocs (rdna2-shader-instruction-set-architecture.pdf) and AMD GPUOpen RDNA 2 Overview.
9. FreeBSD libthr pthread cancellation implementation: lib/libthr/thread/thr_cancel.c and lib/libthr/thread/thr_exit.c#L196-L259.
10. Khronos Vulkan and SPIR-V specifications: Khronos Vulkan Registry and Khronos SPIR-V Registry.