A developer’s workstation displays AnyPS5 shader translation progress, with partial Vulkan game rendering and incomplete features flagged.
AnyPS5 has hit 100% on its GPU shader-instruction tracker. That figure measures recognition, not working games, and the gap between the two is the real story for Windows users.

A developer’s workstation displays AnyPS5 shader translation progress, with partial Vulkan game rendering and incomplete features flagged. What the milestone actually says​

The open-source AnyPS5 project has reached 100% GPU shader instruction coverage in its effort to run PS5 games natively on Windows and Linux PCs. Its live tracker lists all 1,166 instructions in the tracked AMD RDNA 1 and RDNA 2 set as implemented. The tracker breaks these down by instruction encoding (DS, FLAT, GLOBAL, MIMG, SMEM, the SOP and VOP families and others). Every category reads 100%.

The counting rule matters more than the headline number. On the tracker, an instruction counts as implemented when the project's shader decoder recognizes it. It does not count as implemented only once it has been translated, executed correctly and checked against PS5 hardware.

The tracker also leaves out some decoded opcodes that aren't in AMD's public instruction list. These include several DS-family instructions, VAddI32, VSubI32, VMulLoI32, VSubrevI32, SCbranchCdbg and a few data-cache instructions. So "100%" means the project's own list is fully covered. It is not proof that the PS5 GPU is fully supported.

Other outlets reported the same caveat. Overclock3D noted that the tool now recognises all shaders but this doesn't mean it can run PS5 games accurately. VideoCardz made the same point: the milestone covers instruction recognition, not necessarily complete and accurate execution in every game.

Not an emulator, but not a simple port either​

AnyPS5 describes itself as a tool for automatically porting PS5 executables to Linux and Windows. Its relinker converts a game executable into the host's native format. The project also supplies its own implementations of the PS5 system libraries (PRX files), which the converted program loads dynamically. The project says there is no emulation layer and no separate runtime process.

The GPU path is where this gets less clean. According to the project's architecture documentation, game command buffers and state go through a pipeline in four stages:

  1. The RDNA shader code is decoded.
  2. It is translated into an intermediate representation and optimized.
  3. SPIR-V is emitted.
  4. A Vulkan graphics pipeline runs it.

Compiled shader variants are cached in memory and on disk. The decoder milestone covers only the first stage. It doesn't cover control-flow handling, translation correctness, graphics state or Vulkan execution for any particular game.

The CPU side is a smaller problem. The PS5 uses an x86-64 Zen 2 CPU, so game code can generally run directly on a PC processor. For Intel hosts, the relinker has a --to-intel option. It converts supported AMD-only instructions, and it raises an error if it meets unsupported ones.

The system-library denominator keeps moving​

Tom's Hardware reported 84.69% implementation, or 2,578 of 3,044 system-library functions currently declared in the codebase. The live tracker I could see lists 2,697 of 3,190, or 84.55%. The two figures are different snapshots, not a conflict. HotHardware also noted that that number is inconsistent depending on the source.

The denominator only includes functions the project has already declared. It does not cover every function in PS5 firmware, and it grows as new functions are added. A function also counts as implemented once it no longer calls a "not implemented" stub. That says nothing about whether it behaves like the console version. Tom's Hardware gave an example: libSceHttp is reported at a high implementation percentage, yet the project's technical-debt document says no HTTP request reaches the network.

What is actually playable​

The project's compatibility record lists one verified title, Dreaming Sarah, a 2D platformer. The record is marked Windows-only, and Linux is unverified. It lists 60 FPS on a GTX 1050 Ti / Core i5-7500 system and 36 FPS on an Intel HD Graphics 620 / Core i5-7200 system. The record gives no game version, AnyPS5 build or test date. Treat it as a limited data point, not a catalogue-wide result.

A bring-up report for Ghost of Yōtei shows how far a complex title still has to go. It comes from a developer's GitHub discussion, not a general benchmark:

  • The tester used Windows 11, an RTX 3080 Laptop GPU, 32 GB of RAM and a 32–64 GB page file. The executable was relinked with --windows --to-intel.
  • The report said the opening cinematic rendered correctly. The game took about seven minutes to reach the world and ran at roughly 3.4 frames per minute there, or one frame every 17–18 seconds.
  • Remaining work includes graphics formats, tessellation, resource handling and performance. The driver was spending about 17.6 seconds per frame, much of it rebuilding resource bindings.
  • An earlier status in the same discussion listed unfinished tessellation lowering and runtime-indexed descriptors as open blockers.

None of those blockers is about whether the decoder recognizes an instruction.

Windows specifics: the relinker and the memory warning​

The usage documentation sets out a few Windows requirements:

  • Output format: Windows output requires the --windows flag. The default output is Linux ELF whatever the filename is, so naming the file .exe does nothing on its own.
  • Input: You need a clean ELF executable, not a SELF container, with its bundled modules in a sce_module/, sce_modules/ or prx/ folder beside it.
  • Runtime layout: The output sits next to a libs/ folder with AnyPS5's own built system libraries, plus an app0/ folder for converted modules and resources. Original PS5 .prx files must not go in libs/. Windows tries to load them as DLLs and can fail with error 193.
  • Self-built libraries: Self-built libraries also need libgcc_s_seh-1.dll, libstdc++-6.dll and libwinpthread-1.dll. Without them, error 126 can appear even though the .prx file is present.

Memory is the biggest practical trap. A title can request up to 13,824 MiB (13.5 GiB) of direct memory. On Windows, that memory is committed in full at allocation time, not when pages are first touched. The commit limit is installed RAM plus page-file size, and it must cover this allocation along with everything else already committed. If it doesn't, the allocation fails. The documented fixes are to enlarge the page file or close other applications.

This isn't a rule that every game needs 13.5 GiB of free RAM. The Ghost of Yōtei tester hit this on a 32 GB machine with an automatic page file, and a 32–64 GB page file fixed it. So a 16 GB machine with a small page file is a poor candidate. A later pull request there reportedly cut commit charge at one stop from about 15.3 GiB to roughly 6.6–7.0 GiB, but that change is project work, not something users can rely on yet.

No disc-ripping shortcut, and a legal note​

The workflow starts with an already-extracted game ELF and its modules. The project is not a disc-ripping or decryption tool. Its disclaimer says it doesn't include or distribute copyrighted software, firmware, keys or proprietary libraries. It puts responsibility for lawful acquisition and use of binaries on users. Laws on console software differ by jurisdiction, so check your own situation. I'm not offering a legal conclusion.

Analysis: hype versus engineering​

Social posts have already claimed this could bring big PS5 releases to PC "with some work." The evidence doesn't support that. Even the project's own numbers show unfinished system libraries, one verified title and a flagship-class game limited by performance and unfinished features. A few commenters have also doubted how much of the code is hand-written. Tom's Hardware's report counts over 100 human contributors alongside AI-assistant help. That doesn't settle the question either way.

The more realistic outlook is a framework that might eventually support individual titles, much as compatibility layers like Wine and Proton grew over years. The milestone is a sensible checkpoint because every missing shader instruction used to be a possible hard crash. But unnormalized sampler coordinates, tessellation, unsupported image formats and descriptor handling are the sort of work that decides whether a game renders correctly.

Bottom line​

  • What changed: AnyPS5's decoder now recognizes all 1,166 tracked RDNA 1/2 instructions.
  • What it doesn't mean: It doesn't mean validated execution, full GPU support or broad game compatibility.
  • Current proof of playability: One verified title, Dreaming Sarah, on specific Windows hardware.
  • Windows users: Use --windows, expect heavy commit-limit demands and don't expect a plug-and-play experience.
 

References

  1. AnyPS5 project reaches critical GPU milestone in race to enable running PS5 games natively on PC Tom's Hardware 2026-10-10T11:30:00+00:00
  2. GitHub - boykopovar/AnyPS5: Tool for automatic PS5 executables porting to Linux and Windows · GitHub github.com
  3. AnyPS5 achieves 100% PS5-to-PC GPU Shader Instruction Translation overclock3d.net