AnyPS5：把 PS5 游戏变成 Linux 原生程序

场景开篇：一个不是模拟器的模拟器

你打开 Steam，想玩一款 PS5 独占游戏。传统路径是：装一个 PS5 模拟器，模拟器在运行时把每一条 PS5 指令翻译成 x86 指令，把每一个 PS5 系统调用拦截后转发给宿主系统。CPU 烧到 80 度，帧率勉强 30。

AnyPS5 走了另一条路。它不是模拟器——它是一个重链接器（Relinker）。PS5 的可执行文件不是在运行时被翻译，而是在运行前就被转换成了 Linux 或 Windows 的原生格式。游戏跑起来的时候，它就是一个普通的 Linux 程序，没有中间层，没有运行时开销。

Dreaming Sarah，一款 2D 平台游戏，在 GTX 1050 Ti + i5-7500 上稳定 60 帧。这个配置在模拟器时代连启动都费劲。

核心机制：三件事代替一个模拟器

AnyPS5 做了三件传统模拟器不做的事：

1. 重链接器：改格式，不改代码

PS5 可执行文件用的是特定的二进制格式（基于 Orbis OS 的可执行格式）。重链接器做的事情是：解析这个格式，提取代码段、数据段、重定位信息，然后重新打包成 Linux 的 ELF 或 Windows 的 PE 格式。这就像把一本中文书重新装订成英文书脊——内容没变，但书架（操作系统）能直接上架了。

2. 系统 PRX 库的原生实现

PS5 游戏不直接调用硬件，它们调用系统提供的 PRX 库（PlayStation Relocatable eXecutable）。AnyPS5 为这些 PRX 库提供了原生实现——用 C++ 写的、编译成 x86 代码的等价物。游戏调用 sceVideoOutSubmitFlip，AnyPS5 的实现直接走 Vulkan API。没有拦截，没有翻译，就是一次普通的函数调用。

3. 着色器重编译到 SPIR-V

PS5 的 GPU 着色器用的是 Sony 私有的指令集。AnyPS5 的着色器重编译器把它们转换成 SPIR-V（Vulkan 的着色器格式），并且可以通过 Spirv-Tools 验证。这意味着图形管线也是原生的——Vulkan 直接执行，没有转译层。

为什么这比模拟器好？

模拟器的核心问题是间接性。每一条 guest 指令都要经过 host 的翻译层，每一次系统调用都要被拦截和转发。这带来两个代价：性能损失（翻译开销）和兼容性陷阱（翻译不完美时游戏崩溃）。

AnyPS5 消除了间接性。游戏二进制在运行前就被转换成原生格式，系统库是原生编译的，着色器是原生重编译的。运行时的开销为零——或者更准确地说，开销在链接时就付清了，运行时不再有税。

这和 WINE 的思路类似但方向相反。WINE 在 Linux 上实现了 Windows API，让 Windows 程序以为自己在 Windows 上运行。AnyPS5 在 Linux/Windows 上实现了 PS5 系统库，但多了一步——它还把可执行文件本身转换成了原生格式。WINE 的程序仍然是 Windows 二进制，运行时需要加载器理解 PE 格式；AnyPS5 的程序变成了 Linux 二进制，操作系统直接加载。

这件事的边界

AnyPS5 不是万能的。README 里有一个"已验证游戏列表"，目前 Dreaming Sarah 是唯一公开验证的游戏。系统库的覆盖率是一个百分比——不是所有 PS5 系统函数都实现了，只有已声明的部分有实现。遇到未实现的状态，项目会直接抛 std::runtime_error 终止——这是刻意的设计选择，而不是静默失败。

这个项目的定位也很明确：互操作性、研究、保存、兼容性。它不包含、不分发、也不需要 Sony 的版权软件、固件、密钥或专有库。用户需要自己确保使用的二进制合法获取。GPL v2 协议。

更大的图景：二进制可移植性

AnyPS5 代表的技术路线——二进制重链接——在游戏模拟领域不常见，但在其他领域有先例：

• Apple Silicon Transition：Rosetta 2 在运行时翻译 x86 到 ARM，但 Apple 也提供了工具链层面的二进制转换。AnyPS5 更接近后者——在链接时解决问题。
• Java 字节码：JVM 的跨平台是通过字节码 + 运行时解释/JIT 实现的。AnyPS5 走的是 AOT（Ahead-Of-Time）路线——提前编译，运行时零开销。
• WINE 的 Proton 分支：Valve 的 Proton 在 WINE 基础上加了 DXVK（DirectX 到 Vulkan 的转译），但仍然是运行时转译。AnyPS5 的着色器重编译是提前完成的。

区别在于：翻译在什么时候发生。运行时翻译 = 模拟器，链接时翻译 = 重链接器。后者更快但更不灵活——如果翻译有问题，你得重新链接，不能在运行时动态调整。

一个有趣的设计哲学

AnyPS5 的错误处理策略值得注意：不支持的状态直接崩溃。std::runtime_error 抛出，进程终止，错误信息打到 stderr。

这和模拟器社区的常见做法不同。模拟器通常尝试"尽量恢复"——遇到未实现的指令，跳过或用近似值替代，让游戏继续跑。结果是：游戏看起来在运行，但画面有 artifact、物理有 bug、存档可能损坏。

AnyPS5 选择了诚实：做不到就明确告诉你做不到，而不是假装能做到然后给你一个坏结果。这在工程上叫 fail-fast，在研究项目里尤其重要——因为你需要知道边界在哪里。

技术债务与未来

README 里有一个"技术债务"部分——这在 GitHub 项目里不常见，说明作者对项目的成熟度有清醒认知。系统库的覆盖率在持续增长，每声明一个新函数，覆盖率就涨一点。着色器重编译器已经能产出通过 Spirv-Tools 验证的 SPIR-V，但完整的图形管线兼容性还需要更多测试。

输入映射已经支持 SDL 手柄（包括摇杆和扳机键），键鼠可以通过 anyps5-input.ini 配置。这意味着游戏体验已经基本可用——不是技术 demo，是能玩的状态。

结语

AnyPS5 提出了一个有趣的问题：模拟是运行 PS5 游戏的唯一方式吗？ 答案似乎是否定的。通过重链接 + 原生系统库 + 着色器重编译，你可以在运行时消除所有间接性。代价是链接时的翻译必须足够准确——但这是一个可以渐进改进的问题，不像运行时性能那样有硬上限。

当更多游戏被验证通过，AnyPS5 可能会成为一个实用的游戏保存工具——让 PS5 游戏在 PS5 硬件淘汰后仍然可以原生运行在 PC 上。这比模拟器更优雅，也更符合"保存"的本意：不是保存一个能模拟 PS5 的环境，而是让 PS5 游戏本身变成 PC 原生程序。

项目地址：https://github.com/boykopovar/AnyPS5