免模拟器让PS5游戏原生跑在PC上：AnyPS5转译层原理深度解析

前阵子社区里关于一个叫 AnyPS5 的转译项目的讨论突然热起来。核心卖点就一句话：PS5 游戏不用模拟器，直接在 PC 上以原生进程的方式跑，演示用的是《死亡细胞》，一款 2D 像素风格的 Roguelike 动作游戏。

很多人的第一反应是“这又是哪个模拟器的抢先版”，但把技术细节翻完以后你会发现，它和模拟器根本是两条路线。它更像把 Proton 那套逻辑搬到 PS5 上——Windows 游戏能在 Linux 跑，靠的不是虚拟化，而是一层层 API 翻译；那么 PS5 游戏能跑在 PC 上，也可以走同样的路：不翻译 CPU 指令，只翻译系统调用和图形接口。这篇文章我想把这里面的原理掰开讲清楚，顺便聊聊验证这类项目时真正该注意什么。如果你只是来图一乐看“跑了什么游戏”，可以直接看第三章；如果你是真想理解转译层和模拟器的区别，或者以后想自己上手测试这类项目，建议耐着性子顺着读下去。

1. 转译层不是模拟器：它根本不碰 CPU 指令

1.1 模拟器的本质：用软件再造一台主机

把 Switch 模拟器 Yuzu/Ryujinx 或者 PS3 模拟器 RPCS3 打开，观察它们的运行时行为，你会发现一个共同点：它们都在“假装自己是另一台机器”。

CPU 方面，Switch 是 ARM 架构，PC 是 x86_64，所以模拟器必须把 ARM 指令一条条取出来，翻译成 x86 指令再执行；GPU 方面，需要把 Switch 的 Maxwell 指令集转成 PC 显卡能吃的东西；系统服务、内存布局、手柄输入，全都要在宿主机上重新搭一遍。这个过程几乎是把整个主机环境做成一个虚拟化实例，代价是巨大的性能损耗。RPCS3 哪怕跑通了《战神》系列，也得靠高端 CPU 硬顶，原因就在这里。

这个思路当然可行，但有个绕不过去的痛点：它要复现的是一整个生态系统，而不是某个软件的运行条件。任何一个系统组件模拟得不到位，游戏就会以奇怪的方式崩溃。想靠这类方案把 PS5 游戏大规模带到 PC 上，复杂度可想而知。

1.2 Proton 的思路：当翻译官，不造主机

Proton 是 Valve 在 Linux 上跑 Windows 游戏的解决方案。我第一次在 Steam Deck 上跑 Windows 版 3A 游戏时，印象最深的不是帧率，而是系统监视器里 CPU 占用远低于预期。原因不复杂：Windows 游戏本身就是 x86 格式的可执行文件，Linux 在 CPU 层面上可以直接加载运行，根本不需要翻译指令。

需要处理的只是“游戏想调用的 Windows API”和“Linux 实际提供的接口”之间的差异。Wine 负责把 kernel32、user32、d3d 这些 DLL 的调用转成 POSIX 接口；DXVK 和 VKD3D-Proton 再把 Direct3D 的渲染请求翻译成 Vulkan。游戏进程从头到尾都是原生进程，翻译只发生在 API 边界上。这就是转译层，也叫兼容层。

用翻译来打比方：模拟器相当于把一个只讲日语的人放进一个全部讲日语的小镇，你需要把小镇里每个人的日常习惯、生活方式全部复制一遍；转译层则是给这个人配一个随身翻译官，他自己怎么生活还是怎么生活，只有和外界打交道时才需要有人帮他递话。

1.3 PS5 和 PC 是近亲：免模拟的前提条件

AnyPS5 敢说“免模拟”，底气其实来自 PS5 和 PC 在硬件上的高度同构。PS5 的 CPU 是 AMD Zen 2 架构，8 核 16 线程，主频 3.5GHz，指令集就是标准 x86-64；GPU 是 RDNA 2 架构的 Oberon 芯片（36 CU），跟 RX 6000 系列桌面卡同源。

换句话说，一颗 PS5 游戏的可执行文件拿到 PC 上，CPU 指令无需任何翻译就能被 Intel 或 AMD 的处理器直接解码执行。这和 Switch 游戏必须在 ARM 与 x86 之间做二进制翻译截然不同。真正阻隔 PS5 游戏在 PC 上运行的，不是硬件，而是软件：Orbis OS 的系统库、GNM 图形接口、Tempest 音频引擎。只要有个东西在这些接口上做翻译，游戏就能以原生进程的方式出现在 PC 上。

所以“免模拟直连 PC”这个说法的准确含义是：不复制 PS5 的整套运行环境，只在系统 API 边界上做翻译。中间层一定存在，但它的角色是翻译官，而不是替身。

2. AnyPS5 到底在翻译什么：四堵必须翻过去的“方言墙”

2.1 系统 API 层：把 FreeBSD 味的后台换成 Windows 后台

Orbis OS 是索尼基于 FreeBSD 定制的操作系统，游戏拿到的是一大堆 sceXxx 打头的系统函数。AnyPS5 要在 Windows 上提供一套等价的封装：把线程创建、文件读写、Socket 网络、内存映射这些调用全部转接到 Win32 或 Windows NT 的对应接口上。

这一层很像 Wine 里的 ntdll 重定向，难度不算高但非常琐碎。它需要处理线程优先级语义、文件路径规则、异常处理模型的差异。体感工作量占整个项目的两到三成，但几乎所有血泪崩溃都会先出现在这一层。因为系统调用太底层了，一个参数映射错，轻则文件打不开，重则整个进程直接段错误，连给你 debug 的机会都不留。

如果你玩过早期版本的 Wine，那种“游戏能启动但一进菜单就崩”的状态，绝大多数都是这一层没写利索。转译层项目最劝退人的阶段不是图形，反而是这种毫无画面成就感的系统层体力活。

2.2 图形 API 层：GNM 和 Vulkan 的对接是真正的硬骨头

这是我个人最关心的一层，也是 AnyPS5 这类项目成败的关键。PS5 游戏用 GNM 图形接口，这是索尼给开发者提供的底层渲染库。它的风格和 PC 上的 D3D12/Vulkan 很像，也是命令缓冲区、资源状态、barrier、fence 那一套，但它没有公开标准文档，靠的是游戏包内嵌的调试符号和逆向分析。

转译层要做的，是把 GNM 的资源描述、管线状态、绘制命令转成 Vulkan 对象；更麻烦的是着色器。PS5 着色器是 RDNA 2 ISA 的 GPU 微码，PC 上如果恰好是 AMD RDNA 2 架构的显卡（RX 6000 系列），还算能直接吃；换到 N 卡或者新一代 AMD 卡，就必须先把 RDNA 2 ISA 反编译成中间表示，再重新编译成目标 GPU 的指令。这一步没有任何官方工具链，全靠转译层维护自己的编译器后端。性能好不好、兼容性高不高，全看这层做得到不到位。

有一个细节值得顺带提一句：PS5 本身并不支持 D3D12 意义上的 Mesh Shader，它的 Primitive Shader 是更接近传统 VS/PS 管线的一套硬件方案。这意味着转译层处理顶点和像素着色器时，不需要为 Mesh Shader 单独开分支，反而省了不少事。

2.3 存储、音频、输入：三个容易被忽略的外围模块

游戏进程跑起来最显眼的是画面，但让画面“不别扭”的往往是外围模块。

PS5 有专用的 IO Complex，加载场景的速度对 PC 来说属于“容量不大但延迟极低”。转译时最常见的做法是把异步读文件的路径直接映射到 Windows 的 overlapped I/O 上，用多条线程模拟主机的高效调度。如果这层没做好，你会看到游戏帧率不低，但切场景时卡到怀疑人生。

音频方面，Tempest Engine 是硬件加速的 3D 音效单元。《死亡细胞》这种 2D 游戏对它的依赖低，转译层先降级成普通立体声输出问题不大，但如果换成重度利用 Tempest 的游戏，转译层就会面临一个尴尬：没有对应硬件，软件算法能补到什么程度，直接决定玩家耳朵受不受罪。

输入相对最轻松，DualSense 在 PC 上有官方驱动和 Steam 的映射层，只要把 PS5 游戏里读取 DS5 状态的 API 转换成 Windows 平台的标准 HID 读取即可。顺带一提，PS5 手柄的触觉反馈协议在 PC 上能不能完整还原，也取决于这一层的翻译质量，而不是游戏本身。

2.4 给句坦白：工程量的 80% 都压在图形层

把四层纸拉通估算一下：系统层琐碎但架构清晰，外围层大多是耐心活，唯独图形层是深水区。单说 shader 重新编译这一件事，就要覆盖 GNM 的多种资源类型、多种 binding 方式、多种封包格式；再加上 PS5 游戏的渲染风格差异巨大，引擎之间的抽象习惯完全不同，几乎每一款 3D 游戏都要单独调配置文件。

这也是为什么《死亡细胞》能跑起来并不稀奇，稀奇的是它能不能在“没有官方文档、全靠逆向”的前提下持续扩大适配范围。转译层项目最容易被低估的就是这个“每款游戏单独适配”的长期成本，它决定了项目的天花板。

3. 首奔《死亡细胞》是聪明的选择：轻量 2D 恰好卡在验证甜点上

3.1 着色器越简单，转译层越不容易露馅

《死亡细胞》是 2D 像素风游戏，主要画面由精灵图、程序化粒子、以及少量全屏特效构成。它的顶点着色器数量少、计算着色器几乎用不到，光照模型简单。对转译层来说，这意味着需要重编译的 shader 种类很少，而且每个 shader 的结构都很规整，不容易触发反编译器崩溃。

拿它当第一个验证目标，等于先用一张低难度的卷子测试整个管线通不通。如果一上来就选《战神：诸神黄昏》，光是 shader 缓存爆炸和资源状态错乱就能把开发者淹没在 bug 里，根本看不出核心架构是否可行。另外这款游戏的内容深度并不浅，关卡、敌人、武器、程序化地图统统都在，跑它不亚于跑一个中等规模游戏的全部逻辑，对系统 API 层的覆盖测试很有价值。

3.2 有原生 Windows 版，等于白送一个性能对照组

《死亡细胞》早就有 Windows 原生版，Steam 上一堆。这给验证工作提供了太方便的基准：同一台 PC、同一规格的硬件配置，先跑原生版记录帧率、帧生成时间、CPU 占用；再跑 AnyPS5 加载 PS5 版，对比同样的指标。

如果转译层损耗在合理范围内，两边的差距就能被量化出来；如果哪一组数据异常，也能顺藤摸瓜找到是系统层还是图形层的问题。没有原生版做对照的话，项目方说“帧率 60”，你根本不知道它是转译得漂亮，还是 PS5 版本身就轻量。对照实验永远是验证性能损耗最直接的手段，没有之一。

3.3 轻量游戏反而更能暴露转译开销

很多人觉得，2D 游戏肯定对转译层友好到看不出开销。其实恰恰相反：正因为画面压力小，CPU 和 GPU 都处于低负载，任何一次多余的拷贝、一次同步点错位、一个 descriptor 泄漏，都会在帧生成时间曲线上留下明显毛刺。

你在 60 帧的 2D 游戏里看到每几秒一次卡顿，那大概率不是游戏本身重，而是转译层某个同步逻辑在路上堵了一下。用 2D 游戏测转译层，就像用示波器测电源——负载轻，波形上任何杂讯都会原形毕露。这种“低负载高敏感”的特性，恰好能让开发者用最小的游戏体量验证最多的底层逻辑。

4. 如果拿到一个可用构建，我会这样验证它的真实水平

4.1 环境准备与取舍

跑这类项目，我的建议是先别急着上大作，尽量准备接近 PS5 特性的硬件。CPU 核心数量不要太少，毕竟主机版游戏的业务逻辑是按 8 核 16 线程的规格调度的；内存 32GB 起步会更从容，因为统一内存模型和多任务调度在转译过程中会产生额外临时缓冲；系统盘和数据盘都建议用 NVMe SSD，避免加载体验差异让人误判性能。

显卡方面，主流测试者会优先看 AMD RDNA 2 或更新的 RDNA 3 显卡，因为 GNM 着色器的 RDNA 2 ISA 在 AMD 卡上的重编译路径更短；N 卡能不能跑，更多是给转译层做“有没有兜底编译器”的测试，而不是首发目标。软件环境要确保驱动是新的，同时准备 Vulkan 验证层或者 RenderDoc，方便抓帧分析。越接近这个配置，越能减少“工具不行”和“环境不行”之间的混淆。

4.2 一套可执行的对照测试流程

我的做法是：同一台机器上放两个版本——《死亡细胞》Steam 原生版和通过转译层导入的 PS5 版。先各跑 15 分钟同一个关卡的流程，用 PresentMon 记录平均帧率、99% 帧时间、1% Low 帧率，同时用 HWiNFO 记录 CPU 与 GPU 占用曲线。

对比时重点看三件事：

• 平均帧率差距是否在 15%-20% 以内；
• 帧生成时间曲线是否频繁出现超过 50ms 的毛刺；
• CPU 多核负载是否出现某几个核特别忙、其他核在看戏的问题。

如果平均帧率接近但毛刺很多，问题往往出在转译层的同步原语上；如果 CPU 负载不均衡，说明系统层的线程映射没跟上主机调度模型。这两类问题的修复路径完全不同，所以数据记录得越细越省时间，别等翻车了才想起来没留基线。

4.3 最容易踩的五个坑

不管是实际用还是看别人跑，建议重点盯这几个症状：

这些坑不光 AnyPS5 会踩，任何做转译层的项目都会踩。我当年折腾 DXVK 早期版本时，花了一个周末查贴图闪烁，最后发现是 descriptor 池大小按旧版 API 配置、新队列分配时直接被拒绝。这类问题的共同点是：拷文件不会崩，跑起来才崩；要看帧，更要看帧生成曲线的形状。

4.4 怎么量化性能损耗：别只盯着平均帧

转译层的真实水平，建议用“帧率差距 + 帧时间毛刺数 + 负载均衡度”三个维度一起评判。

帧率差距反映的是每帧的指令开销，毛刺数反映的是同步开销，负载均衡度反映的是线程映射质量。三个指标里任何一个极度难看，都说明转译层还没到能日常使用的阶段。尤其注意 1% Low：转译层做得差时，1% Low 会比平均帧难看得多，这是“偶尔卡一下”的直接证据。拿《死亡细胞》这种本来就该稳定 60/120 帧的游戏来说，转译版哪怕平均帧到了 90，只要 1% Low 掉到 20，结论也就很清楚了。

5. 天花板在哪：从《死亡细胞》到大作的距离

5.1 每一款新游戏都可能是一次全新适配

Proton 能在 Linux 上覆盖大量 Windows 游戏，一个重要原因是 Windows API 有完整的公开文档，而且历史版本兼容性极好；社区里还有 ProtonDB 这类数据库做众包测试。AnyPS5 面对的 GNM 没有同等条件，PS5 游戏的底层实现五花八门，不同引擎调用 GNM 的方式差距极大。

哪怕《死亡细胞》跑顺了，也大概率意味着“适配完一款跑一款”。每换一个引擎、每换一种渲染架构，转译层都可能要重新调配置、打补丁。这也是为什么发行商和玩家对这类项目多是观望态度——它的长期维护成本比模拟器项目低不了多少，只是性能上限更好。真正决定这类项目命运的，不是首发能跑什么，而是三个月后能不能跑第二款。

5.2 没有文档的逆向工程，终归是在流沙上盖楼

PS5 的系统更新会带来新的系统服务接口、新的加密与签名机制，每次更新都可能导致转译层某个节点失配。更关键的是，GNM 本身是 NDA 受限的技术，社区只能拿游戏包和日志做黑盒分析，没有一个稳定的规格书来对照。

这种项目的进展速度，往往取决于开发者团队里有多少人能坚持做逆向。Proton 之所以成熟，是因为它不需要逆向 Windows 的未公开 API，大部分接口都有文档；而 AnyPS5 几乎每一步都要和“没有文档”搏斗。进度快不快，说白了不是看热情，而是看逆向工程投入。

5.3 使用边界：技术探索和内容授权之间的分寸

最后说点所有玩家都该心里有数的事。兼容层、转译层这类技术本身是中性的，研究“PS5 游戏能否以原生进程方式在 PC 上运行”是有技术价值的课题；但当你实际运行一款游戏的 PS5 版数据时，涉及的仍是你是否合法持有对应内容、是否符合平台授权协议的问题。

我的建议是：关注原理、讨论技术没问题，实际测试时只碰自己合法获取的内容，不要传播任何未经授权的游戏数据。技术能力解决的是“能不能跑”，授权协议决定的是“能不能这样用”，这两件事始终是分开的。

说实话，我看过太多模拟器演示视频，对任何“跑起来了”的片段都会多留几个心眼。但 AnyPS5 这个方向不一样的地方在于，它在原理上站得住——PS5 和 PC 的硬件同源性是真实的，Proton 验证过的 API 翻译路线也是成熟的，剩下的纯粹是工程量问题。什么时候它能在《死亡细胞》之外再连续拿下几款不同引擎的 2D 甚至轻量 3D 游戏，我就会真的拿它当个正经项目来追了。在那之前，先把原理弄清楚，比守着视频激动更有价值。