Switch模拟器Ryujinx进度报告2024-1月

Switch模拟器Ryujinx进度报告2024-1月

二月来了，这一定意味着一月又滑过了。

虽然每年的这个时候对于那些 Twitter 融化的 AAA 游戏来说通常并不那么热门，但我们有时都需要更少的动感十足的时间表。育碧证明了他们仍然有能力制作一款引人入胜的视频游戏，而年度最佳潜力游戏：大头菜小子抢银行，证明了几乎任何想法都可以做到！

撇开对游戏的看法不谈，现在是通常议程的时候了。

正如我们之前所强调的那样，就 3D 图形而言，macOS 作为一个平台有点像一场噩梦。Ryujinx 的一切都需要通过 MoltenVK，虽然是救命稻草，但也不能幸免于挫败感。在所有平台上，如果着色器编译失败（通常是由游戏的无效输出引起的），我们可以尝试跳过绘制以避免程序完全崩溃。然而，在 macOS 上有一个奇怪的情况，一些管道变体是 A-OK，但有些会失败;正是这最后一种情况仍然可能导致《火焰之纹章：风花雪月》等游戏的持续崩溃。

添加条件以在更多失败的情况下返回并不能 100% 修复图形渲染，但它确实避免了崩溃，并且实际上允许用户为我们提供日志以备将来的管道问题！

如上所述，GPU 驱动程序在实际影响几乎所有方面通常被严重忽视。许多人认为它们在某些功能之外通常相对相似，而实际上它们是有史以来最大和最复杂的程序之一。它们都有不同的操作路径，这些路径可能围绕特定硬件设计，也可能不是围绕特定软件设计的。我们，以及通常许多 3D 应用程序开发人员，对 Nvidia 给予很多赞誉的原因之一是，他们的驱动程序对开发人员几乎采取任何路线都具有可笑的弹性。因此，当在纸面上，两个设备可能相等匹配时，通常很容易发现渲染成本的巨大差异。

因此，有一些正在进行的更改试图降低其他驱动程序在操作上的成本，其中第一个是使用模板进行描述符更新。

使用模板的主要受益者是 RADV Mesa 驱动程序，它可以看到高达 5% 的帧速率全局改进，以及 Vulkan 后端时间的大致相同下降。相比之下，Nvidia 的帧率没有提高，后端时间成本降低了 0.6%。他们已经很好地处理了次优路径。

《Citizens Unite！： Earth x Space》联合公民:地球与太空 在一月之前玩是有问题的，除非戴上眼罩，或者类似的东西会损害你的视力。当某些绘制命令触发时，它们可以“内联”传递参数，而不会更新任何 3D 引擎状态。如果请求使用状态变量的另一次绘制，则绘制将包含不正确的数据，用于构建图像。通过在图形类型之间切换时强制更新顶点缓冲区，该问题已得到解决。

不同寻常的是，这突然结束了我们关于 GPU 更新的部分。

然而，这里节省的资源使项目负责人 gdkchan 能够完成一项相当重要的工作。

在苹果公司通过其 M1 系列设备发表声明后，ARM 设备正在经历自己的复兴时期。未来看起来，架构将不再是纯粹的移动和小型产品的领域。Microsoft似乎终于在 Windows on ARM 上加紧努力，Linux 已经处于一个很好的位置，Apple 自 2020 年以来一直全力以赴，我们开始看到像高通这样的芯片设计商进入 PC 市场。

Ryujinx 已经可以通过我们的 JIT 编译器在任何运行受支持操作系统的 ARM 设备上运行，但当您考虑到 Switch 本身也是基于 ARM 的时，这通常是非常浪费的。在 macOS 设备上，我们目前使用 Apple 提供的 Hypervisor 服务，以便（几乎）以接近零的开销原生执行 Switch 代码，但这并不是解决问题的特别全局解决方案。除了 macOS，我们无法在任何地方使用 Apple 虚拟机管理程序，虽然我们可以针对 Windows 和 Linux 实施更多解决方案，但代码膨胀将是巨大的。

我们决定采用一种混合方法，即仍然对代码进行 JITing，但使用新的“闪电”路径。

所有 Switch 代码仍被传递给我们的 JIT 编译器，但是，当在 ARM CPU 上运行时，现在可以查看代码块并检查是否有任何内容确实需要重新编译。在最好的情况下，它可以充当类似于虚拟机管理程序的零成本传递，在最坏的情况下，它仍然会完成 x86 系统所需的一小部分工作。

上图绘制了 Apple M1 芯片在特定条件下重新编译游戏二进制文件中的所有代码所需的时间。

粉色 = 完全重新编译，重点关注速度而不是代码质量。

红色 = 完全重新编译，重点关注代码质量而不是速度。

绿色 = 在需要时进行闪电重新编译。

好吧，所以速度绝对不是问题。但是，由于旧的JIT具有高代码质量和低代码质量模式，因此代码质量本身如何叠加（将其视为二进制大小或“指令数”）？

结论是，新的 JIT 可以生成更好的代码，并且比旧的 JIT 快得多。最显着的差异出现在 Neptunia 上，它具有最大的代码大小。在HighCq模式下使用旧的JIT编译需要4.5分钟，而新的JIT只需要4.64秒。旧的JIT在HighCq模式下产生了633MB的代码，而新的JIT产生了348MB的代码。这几乎是大小的一半，而花费的时间却很少。

许多人可能认识到，《新超级马里奥兄弟U豪华版》（上图中的NSMBUD）实际上是一款32位游戏，如果没有JIT，就无法通过虚拟机管理程序或任何其他方法进行本地执行。通过专注于不仅考虑 64 位游戏的方法，我们可以显着减少 NSMBUD 或 Mario Kart 8 Deluxe 等游戏的开销，这些游戏一直是 ARM64 设备的主要痛点，最简单的展示是启动时间。

视频加载中...

视频加载中...

视频加载中...

有了这个，我们应该在我们支持的平台上为未来的 ARM 设备奠定良好的基础，该平台维护成本低且不依赖于任何特定框架（Apple 用户这次很幸运！新的 ARM64 Linux 版本已经可用，并被用于一些很酷的东西。Asahi Linux 项目（适用于 M 系列 Mac 的 Linux）的人们已经在使用我们对他们的 OpenGL 4.6 驱动程序进行压力测试！

我们确信你们中的一些人会问，为什么我们不采用一种称为“原生代码执行”或“NCE”的替代方法，这种方法已被 Android 设备上的 Switch 模拟器广泛普及。NCE 不是我们挖掘 ARM 设备潜力的首选响应，原因如下：

1. 即使在ARM设备上，也不可能直接运行Switch系统指令，例如服务调用，因为它们特定于Switch操作系统和内核。因此，NCE 方法需要修补游戏 ROM，以将这些指令重定向到主机仿真器调用中。这些修改使游戏能够访问主机，并且对来宾程序完全可见。
2. 中断来宾线程变得有些复杂，因为我们不能在代码中插入“中断点”。我们可以在类 Unix 操作系统上使用 pthread_kill ，但 Windows 没有这样的东西。
3. 该代码将直接访问模拟器地址空间，因此我们需要以一种使游戏满意的方式进行设置，分配的来宾区域完全包含在来宾地址空间中。

对于页面大小为 16KB 的平台，存在额外的挑战，因为我们无法将文本段和数据段分别映射为 RX 和 RW，因为它们是 4KB 对齐的，而不是 16KB 对齐的。如果平台有 W^X，我们也不能将它们全部映射为 RWX。

但是，鉴于 NCE 确实有其优势，因此将来可能值得再次研究。然而，现在，我们重视一种一致的方法，它干净地集成到 JIT 项目中，提供接近原生的执行速度，而且非常重要的是，它还极大地提高了 32 位游戏的执行。

在繁重的部分之后，我们将简要介绍一下 1 月份完成的一些服务更改：

• 在新的IPC上实现arp：r和arp：w服务。这些服务被称为“胶水”服务，因为它们管理启动应用程序和应用程序元数据等流程。将这些迁移到我们较新的服务系统是其他服务遵循的要求。
• 音频服务中已修复下采样环绕到立体声的整数溢出问题。这在使用 SDL2 音频后端时会导致一些噼啪声和失真。
• LayeredFS mod 加载现在是并行执行的，以便在应用许多 mod 时提高游戏启动速度。现在，当需要更改时，修改应延迟加载。

在GUI方面，我们已经看到了Avalonia前端的一些主要补充。

添加了从右到左的语言支持，经过多年和无数次请求，现在实现了一个模组管理器，它将允许用户添加任意数量的游戏模组，并且实际上能够关闭它们！

此外，HLE 控制器小程序也进行了一些重新设计，以提供更直观的内容作为支持的播放器和控制器的指南。

小程序现在将显示游戏请求的控制器类型以及它将接受多少玩家的图标。总的来说，由于“文字墙”效果，这是更令人困惑的小程序之一，而且较旧的游戏机根本不像 Switch 那样关心玩家/控制器组合。

关于玩家/控制器组合的主题，实施了一个更好的系统来识别断开/重新连接的控制器。以前，系统依赖于控制器 ID（针对特定控制器的标准化）以及连接时分配的全局索引。遗憾的是，此全局索引会根据设备的连接时间和方式而更改，从而导致设备未分配正确的配置文件，或者在连接时根本没有分配。除了 GUID 之外，系统现在还使用单独的索引来跟踪设备，从而使添加或重新连接的控制器实际正确加载其配置文件的一致性要高得多。

对于那些非常耐心地等待我们在 UI 开发方面的进一步更新的人，我们上次提到我们的 Avalonia 开关的主要障碍之一是 Steam Deck 用户的 Linux 端。我们终于很高兴地报告说，根本原因是一个令人讨厌的简单单行修复。隧道的尽头近在咫尺！

结束语：

随着我们集体进入 2024 年，我们都非常感谢大家对这个项目的支持。到目前为止已经 6 年了，无论是通过 Patreon、在 GitHub 上报告错误或代码贡献，还是在我们的 Discord 中协助其他用户，因为你们所有人，动力和目标列表仍然和 2018 年一样高。我们对这个项目所取得的成就感到非常敬畏，所以再次感谢你们！