34.8k Stars Won't Put GTA VI on Your PC. Here's What AnyPS5 Is Actually Doing

Seeing GTA VI run on a PC before the official port would be a spectacular way to end the console exclusivity argument. So a project that promises to turn PS5 executables into Windows and Linux programs gets attention almost automatically. When I checked on October 13, 2026, GitHub showed AnyPS5 at roughly 34.8k stars.

The attention has technical substance behind it: open code, hand written system libraries, a shader compiler, and reports of commercial games booting. There is also AI involvement, which the contributors state openly in their own write ups.

None of that means GTA VI is about to run on PC through AnyPS5. Rockstar's official page lists November 19, 2026, on PlayStation 5 and Xbox Series X|S. Nothing in the project's own material claims a GTA VI boot.

TL;DR. AnyPS5 does not emulate PS5 hardware. The CPU is already x86-64, so the real work is replacing a platform's dependencies: a relinker rewrites the game's ELF into a native executable, hand written libraries answer the system calls the game expects (with the right ABI, not just the right name), and a recompiler turns RDNA shaders into SPIR-V for Vulkan. AI is used in development, not at runtime, and the project's answer to "did the model understand the hardware correctly" is a hardware oracle that runs real RDNA snippets on a real AMD GPU. The 90% style progress counters measure stubs removed and opcodes decoded, not games completed. Boot reports are real and narrow: PAC-MAN WORLD Re-PAC on main, GTA V at about 27 to 28 FPS in one scene on an experimental branch, Astro Bot at about 10 FPS on a patched build.

The more interesting question is what is already happening. AnyPS5 is a good lens for looking at a console as a set of software dependencies, some of which can be replaced, and at AI as a tool that can help replace them.

By deplatforming here I mean freeing a program from its technical attachment to one platform. The game still executes its own code. The environment around it is reproduced by other people.

This has a familiar relative: Wine, the compatibility layer for Windows applications. The shared idea is reproducing the interfaces a program expects. AnyPS5 does it its own way: ahead of time conversion of the executable, its own libraries, and a separate path for console graphics.

The hardware gives you the first opening#

The PS5 runs an AMD Zen 2 CPU on x86-64. That is the same instruction family as an ordinary Intel or AMD desktop. A large share of the game's machine code can potentially be executed by the host CPU itself.

Identical instructions are not compatibility, though. The program expects a particular loader, particular system functions, a particular memory layout, particular threading rules, and a particular graphics interface. For the game, the platform lives in exactly those details.

Picture a program that can compute a car's trajectory perfectly well, but reads a file through a function Windows does not have. The CPU understands the math. Execution stops at the first contact with the outside world.

AnyPS5 splits that problem into parts. Simplified, the pipeline looks like this:

That shape comes from the project's architecture notes and its implementation. It avoids running a separate process that pretends to be a whole console. The work of reproducing platform behavior does not disappear, it just lives in the libraries and the graphics layer.

Step one: rewrite the executable#

The first component is the relinker. It reads the executable, walks its dependencies and relocations (the places where addresses must be patched at load time), and emits a file in the target OS format: ELF for Linux, PE for Windows.

Conversion.cpp shows the sequence: prepare the source image, run RelinkerPipeline, convert the game's bundled modules, pick a platform patcher, write the result. Illustrative pseudocode, not a literal excerpt:

auto image      = read_game_elf();
auto imports    = analyze_imports_and_relocations(image);
auto modules    = convert_bundled_modules(image);
auto executable = build_native_executable(image, imports, modules, target_os);

Nobody is recovering the game's C++ sources and rebuilding it. The existing binary and its relationship with the environment are what get reworked.

Even inside x86-64 there are differences. The project has a --to-intel mode that rewrites supported AMD specific instructions, with a stated limit: instructions the game generates at runtime are not something an ahead of time pass can catch. The input has to be prepared too, since the relinker expects a clean ELF rather than an arbitrary game package. Both are spelled out in the usage docs.

Step two: "just provide the functions"#

In the executable, a system function can be referenced by a NID, a compact identifier. AnyPS5 builds its own libraries and renames exported functions to the identifiers the game looks for. NidCompute.cpp computes a NID from a name. The identifier connects a call to an implementation. It says nothing about the implementation being correct.

Here is a small real excerpt from Time.cpp:

std::uint64_t APS5_VABI sceKernelGetProcessTime() {
    const std::uint64_t start = GetStartNanos();
    return (GetMonotonicNanos() - start) / 1000ULL;
}

The game calls a familiar system function. AnyPS5 returns elapsed time in microseconds using its own clock helpers. From the caller's point of view the interface holds.

That tiny function hides another platform boundary: APS5_VABI. On Windows the macro expands to __attribute__((sysv_abi)), telling the compiler which calling convention the guest code expects. The ABI governs, among other things, how arguments are passed and which registers may be clobbered.

A matching function name is not enough. If the caller puts an argument in one register and the implementation reads another, the thing breaks before any real work happens.

Clocks make a compact example. Threads and memory get hard fast: wakeup ordering, cancelled waits, address reuse. A mistake there can surface minutes later, when the next scene load meets a badly reproduced synchronization primitive.

Step three: the GPU, where it stops being cheap#

A console shader cannot be handed to an arbitrary driver as a finished program. AnyPS5 builds its own translation path: decode RDNA instructions, rebuild the control flow graph, lower operations into an intermediate representation, emit SPIR-V for Vulkan.

Recompiler.cpp really does contain a decoder, a GraphBuilder, a Structurizer, an InstructionTranslator and a SpirvEmitter. Strip out resource management, specialization and caches, and the logic reads like this (again, illustrative pseudocode):

auto instructions  = decode_rdna(shader_bytes);
auto control_flow  = build_control_flow(instructions);
structurize(control_flow);
auto ir    = translate_to_ir(instructions, control_flow);
optimize(ir);
auto spirv = emit_spirv(ir, host_gpu_capabilities);

An IR is convenient because it separates what an operation means from the machine format it came in. The meaning still has to be reproduced exactly: rounding, memory behavior, branching, how threads inside the GPU interact.

Beyond shaders, the graphics layer handles draw commands, textures, buffers and synchronization. The driver's known limitations list has a telling case: GPU results can land late in memory the game has already freed and reused for something else. That needs correct ordering of events. A faster GPU does not fix it.

Where the AI actually sits#

In the execution path above there is no step where a language model invents the next frame. AnyPS5 performs program transformations. The AI shows up in building those transformations.

Contributors publish concrete loops: diagnose a crash, change code, build, run, post a new report. In the PAC-MAN WORLD Re-PAC thread the author credits Claude with diagnosis and patch preparation. The Astro Bot reports name Codex directly. That confirms assistants are in use. It does not let anyone compute how much faster the project moved.

My engineering hypothesis: this kind of work suits assistants unusually well, because the big task decomposes into checkable fragments. Parse a structure format. Find the cause of a crash. Implement one instruction. Write a test for an edge value. Repeat on another driver.

The hard part stays in verification. If a model misunderstood an instruction's behavior and then wrote the test from the same misunderstanding, a green test only proves two errors agree.

Which is why the hardware oracle is the most interesting file in the repository. The tool runs small RDNA assembly snippets on a real AMD GPU and returns the result, so measured values can be frozen into tests. The docs warn about GPU differences: an observation on one desktop card does not automatically prove PS5 behavior in every case.

The contribution rules require stating the provenance of shader instruction semantics, disclosing AI use, and owning every line you submit. That is a sane collaboration model: the assistant proposes an implementation, and evidence of correctness is gathered separately.

Read the progress counters carefully#

tools/progress.py counts a library function as implemented once it no longer calls the project's NotImplemented_nid_no_patch stub. For GPU instructions, the counter reflects decoder recognition.

Those are useful measures of work on the code. They do not measure the share of compatible games. A function can exist while a rare mode of it still diverges from the console. A decoder can recognize an opcode while the failure happens later. And the denominator of the library statistic only includes functions the project already knows about. "90% implemented" cannot be read as "10% away from GTA VI".

Concrete boot reports say much more. As of October 13, in the threads I read:

These are substantial results. The distance between a first frame, a controllable character, and a finished playthrough is still large. A working menu says little about saves, about a complex scene five hours in, or about another GPU family.

GTA VI would require checking its binary, its shaders, its memory behavior, its world streaming and the system interfaces it actually uses. Even a fully working PS5 build of GTA V would not prove the next game compatible. A shared developer and a shared series name are not measurements.

So promising a near term GTA VI boot through AnyPS5 would be premature. What is already worth discussing is the changing cost of this kind of engineering. If AI helps cycle through checkable hypotheses faster, write adapters, and dissect crashes, then more attempts become practical. How much faster those attempts reach a stable result is something only reproducible tests will show.

Platform lock in is made of many small contracts between a program and its environment. AnyPS5 makes a number of those contracts visible in code. That is its most interesting effect: "which device does this game run on" slowly turns into "which dependencies are still missing".

AI can help write the next implementation. Correctness still has to be demonstrated on a running game.

What would you accept as proof that a compatibility layer is actually correct, rather than correct enough to boot a menu?

Checked on October 13, 2026. Code read at commit dacd78525e537a779682032c0ace7f7af120af05. Boot results and FPS figures are as reported by the authors of the linked threads; I did not run the games myself while preparing this. Illustrative pseudocode is marked separately from the one real source excerpt.

Sources and further reading#

• AnyPS5 repository
• AnyPS5 architecture notes
• AnyPS5 usage docs, including --to-intel limits
• Conversion.cpp, the relinker pipeline
• NidCompute.cpp
• Time.cpp, sceKernelGetProcessTime
• VabiMacros.hpp, the sysv_abi boundary
• Recompiler.cpp, RDNA to SPIR-V
• libSceAgcDriver known limitations
• HW_ORACLE.md
• CONTRIBUTING.md, provenance and AI disclosure rules
• tools/progress.py
• PAC-MAN WORLD Re-PAC report
• GTA V report
• Astro Bot report
• Rockstar, GTA VI official page
• Sony, PS5 specifications press release
• Wine, about the compatibility layer