官网已经可以下载

https://rpcs3.net/download

左侧展示的是在苹果的Rosetta2 x64 -> arm64翻译层下运行的RPCS3 x64版本；右侧则是直接在苹果M1芯片上原生运行的RPCS3 arm64版本，显示出显著的性能提升！

对arm64设备的初步支持始于2021年苹果M1系列发布之后。我们开始探索在arm64上运行rpcs3。感谢RPCS3核心开发者Nekotekina的努力，我们在2021年12月获得了一个能够在arm64上运行的基本版本，尽管它无法运行任何内容。在kd-11的帮助下清理代码，使RSX能够在arm64上工作，并且经过Nekotekina的进一步优化，我们终于在2022年1月成功运行并渲染了一些样本。此时只有PPU/SPU解释器能够正常工作，导致性能非常差，但这是让RPCS3在未来arm64设备上正常运行的第一步。最初的工作仅限于Linux支持，因为Linux广泛可用且开发者无需硬件锁定。几个月后，一位贡献者Jeff Guo提交了一系列补丁，使x64 macOS分支与时俱进。在这一阶段，macOS取得了一些重大进展，例如理解新JIT机制的工作原理。我们曾尝试让LLVM工作，但到2023年底，我们仍然只有没有LLVM支持的arm64工作版本。

自2021年以来，RPCS3的图形开发者kd-11一直在幕后努力提升Asahi Linux上的arm64支持。起初，由于缺乏图形驱动的支持，性能问题并不重要，但随着时间推移，这方面不断改进，最终Asahi Linux甚至可以作为日常使用的操作系统。到2023年底，arm64 LLVM的集成工作被重新提上日程。初期的目标是Linux，因为任何问题都可以通过源码级别进行调试。kd-11很快发现LLVM无法与RPCS3的JIT正常工作的原因是模拟器处理来宾代码的方式。由于RPCS3最初是针对x86架构设计的，某些架构决策依赖于x86特定的行为。其中之一是，在每几个代码块后，来宾会退出回到主机以处理状态检查并释放堆栈。RPCS3为所有JIT代码块使用了尾调用优化的堆栈帧，但x86在调用时会消耗堆栈，这些堆栈需要通过返回链或重新加载堆栈指针来回收。而arm64不同，它使用专用寄存器来“链接”调用，没有堆栈帧的返回链。当JIT代码执行第一个返回时，CPU会进入一个无限循环，跳回当前位置并卡死，因为链接寄存器未更新为上一个位置。

自然地，对于这个问题，计算机科学中总有多种解决方法。2024年初，我们探索了一些方法以实现概念验证。第一个方案比较简单——为每个函数调用提供一个最小堆栈，并模拟x86行为。我们保持帧本身无堆栈，但跟踪上一次调用地址并重新加载以实现回退。不幸的是，这种方法不够可靠，因为基本块假设所有堆栈空间都是可擦写的，并且会不时覆盖返回地址，导致随机崩溃。我们还尝试了几种变体，包括回收一些寄存器作为影子调用堆栈指针。这些方法都有效，但各有优缺点。例如，有些方法需要修改LLVM以适应RPCS3的JIT架构，这并不理想，因为这需要我们维护一个LLVM分支。另一种快速解决方案是将所有返回替换为远跳转到某个主机网关，由网关修复寄存器状态后退出。但这也面临挑战，因为我们的JIT代码块之间可能存在循环或递归调用。这种策略导致的性能损失太大，难以实际使用。

到2024年2月底，kd-11利用定制的LLVM分支成功运行了一些样本。经过3月的进一步改进后，arm64上已经可以运行自制软件。经过短暂的停顿，kd-11在2024年6月底取得了突破，一些商用游戏可以通过PPU LLVM在arm64上运行！概念验证阶段正式结束，是时候选择一种最佳策略并开始实际发布了。

最终，kd-11决定采用一种IR转换器，该转换器分析为x86-64生成的JIT中间代码(IR)，并根据arm64的需求进行调整。这个想法很简单——首先为参考架构（在此为amd64）生成一次IR，然后根据需要将其转换为其他架构目标。由于LLVM在编译前会将所有内容表示为IR，因此这一工作成为可能。LLVM的基本块在流程控制上有一定约束，而我们的JIT块总是可以从一个网关调用，因此实际上存在一种ABI（应用二进制接口），规定了哪些寄存器存储哪些值——例如，来宾线程上下文始终保存在传递到块的第一个寄存器中。这个设置被扩展为在编译时提供额外信息，使转换器能够准确识别对象的位置。例如，我们不需要存储整个调用链，只需知道最近的主机网关位置即可。这种方法效果极佳，到7月底，大多数商用游戏已经能够启动并运行得相当不错，但仍有更多问题需要解决。

默认情况下，基于x86的操作系统提供4KiB的页面粒度。PS3本身也支持4KiB粒度，并且期望操作系统能够正确对齐内存分配。然而，大多数现代arm64平台的最小页面粒度为16KiB。这通常意味着更好的内存性能，因为现代设备使用更多内存并处理更大的对象。

对16K页面的支持在2021年被加入到模拟器中，并在使用解释器时进行了充分测试。大多数游戏并未注意到页面大小比请求的大了4倍，这使得移植工作在这一点上比预期容易得多。然而，当我们最终让LLVM运行起来后，很明显性能影响可能非常巨大。像RPCS3这样的模拟器使用脏页跟踪来处理纹理的缓存驱逐。虽然现代游戏拥有占用大量空间的大型纹理，但PS3则截然不同。不仅许多纹理非常小，所有用户可见的GPU对象通常都以纹理的形式表示，包括纹理缓冲区、统一缓冲区、着色器存储缓冲区等。这些对象的大小差异极大，而驱逐单个16K页面可能会导致我们在每次绘图调用时耗费大量资源重新上传数据。幸运的是，大多数游戏似乎未受此影响，但仍有一些表现极差的特殊案例在16K平台上运行时表现不佳。

挑战PlayStation 3模拟的极限
到现在，你可能会想到：既然RPCS3有适用于Linux arm64的版本，并且需要支持armv8.2-a的CPU、至少8GB的RAM，以及支持OpenGL 4.3或Vulkan的GPU/驱动，那是什么阻碍了它在Raspberry Pi 5设备上运行？我们能在多大程度上挑战这台仍被认为是模拟资源需求最高的主机——发布18年后依然如此？

为了验证这一点并支持arm64开发，AniLeo购买了一台Raspberry Pi 5。这款低成本的arm64设备售价约为68英镑/93欧元/85美元/617人民币，外加4英镑/6欧元/5美元/36人民币用于购买主动散热器。

设备运行了Arch Linux ARM，以利用最新的软件包，并直接在设备上编译RPCS3。此外，为了榨取更多性能，设备被超频：CPU被超频至2900MHz（+400MHz），GPU被超频至1060MHz（+100MHz）。

我们首先尝试使用默认的Vulkan渲染器运行游戏，但失败了，因为Broadcom GPU的Mesa v3dv驱动缺乏完整的textureCompressionBC支持，这是由硬件限制导致的。不过，并非一切都无法挽回，因为v3dv驱动支持BC1-BC3格式，而这正是RPCS3所需的全部。

随后，我们在RPCS3中添加了一个变通方法，即使v3dv驱动未报告支持该功能，也允许Vulkan渲染器启动。通过这种方式，我们成功地使用Vulkan启动了游戏。

不幸的是，Vulkan渲染器只能运行短暂时间，随后系统会完全挂起，必须通过断电重启设备。这迫使我们转向使用OpenGL渲染器进行测试。幸运的是，结果令人满意：Broadcom GPU的Mesa v3d OpenGL驱动能够正确渲染所有测试游戏，没有出现任何视觉问题。

然而，最初测试数十款游戏的结果并不乐观。总体来看，游戏性能非常低，没有任何一款游戏能够流畅运行，即使是简单的游戏。经过调查，我们发现Raspberry Pi 5的Broadcom VideoCore VII GPU不仅性能极其弱小，其性能甚至比PlayStation 3的GPU——RSX——弱了数倍。这意味着Raspberry Pi 5无法以720p分辨率渲染这些游戏。

为了解决这一问题，我们尝试了不同的渲染分辨率。在降低渲染分辨率后，性能有了显著提升，因为瓶颈从GPU转移回了CPU。然而，即便是将3D游戏渲染至360p，这块GPU依然无法应对。最终，我们决定将渲染分辨率设置为PlayStation Portable屏幕的分辨率——272p，通过将分辨率比例缩小至38%来运行游戏。这一设置在性能和可玩性之间找到了一个平衡点。

在这里，我们可以看到《战神1》在720p（PS3）和273p（PSP）分辨率下的测试结果。以PS3的720p分辨率运行时，游戏在渲染时大约只有10帧每秒（FPS），显得非常吃力。然而，在PSP的273p分辨率下，游戏能够稳定地以30帧每秒运行，表现非常流畅。通过这一数据，我们终于看到了几款游戏在Raspberry Pi 5上运行时达到了可玩性能，接下来将展示这些游戏的表现。

令人惊讶的是，尽管分辨率较低，许多PS3游戏在Raspberry Pi 5上仍然可以运行到可玩状态。由于硬件性能的限制，很多可玩游戏在Raspberry Pi 5上的表现并不理想，但我们仍然能够将其推向极限，使一些游戏以30帧每秒的速度在PSP分辨率下运行。

或许我们已经站在开源掌机能够运行PS3游戏的大门前了，期待