Switch模拟器Ryujinx进度报告2023-4月
大家好，又是你们本月最喜欢的时间了。不用说什么，我们知道这是真的！
四月的旅程始于塞尔达传说：旷野之息。真的不可能是别的吧？整个四月，人们突然对游戏的稳定性、保真度和性能非常感兴趣，这并非没有原因。
对于Nvidia GPU用户来说，保真度和图形准确性多年来从未成为严重的问题，但对于AMD和（越来越多的）英特尔用户来说，情况并非如此。草的阴影周围会有主要的伪影，这种效果甚至可以在角色模型和其他物体上看到。
这里的问题是，当选择纹素时，当两个选项正好介于两者之间时，不同的驱动程序是如何打破平局的。英伟达，苹果和梅萨将正确打破平局，而AMD / Intel则相反。通过应用尽可能小的正偏置，我们可以迫使这些驱动器做出正确的选择。
在性能方面，这里的怪癖很多，并将持续到五月。《荒野之息》的主要性能瓶颈之一是其超长的渲染通道，每个通道都有大量的绘制。这意味着后端最终可能会在 4-5 毫秒内构建单个命令（当帧可以短至 16 毫秒时，这是一个非常大的数字）。BotW 极其激进的 GPU 同步要求使情况恶化，这意味着游戏被迫等待每个大命令的完成。因此，减小这些命令缓冲区的大小将减少两个净位对性能的影响。
通过在 Vulkan 后端实现所谓的“快速刷新”模式，如果游戏同步足够积极，我们现在会定期强制提交命令。我们看到 BotW 和其他一些 GPU 受限的情况改进了高达 11%，例如在神奇宝贝朱/紫中使用分辨率缩放时。
暂且不谈塞尔达，我们过去已经提到了《命运/EXTELLA》，本月也不例外。它似乎有一个奇怪的诀窍，可以突出显示GPU模拟器中的一些相当小众的差距，所以我们希望你不会厌倦它的持续客串！事实证明，我们缺少一个多采样<>非多采样深度转换来完成设置的情况，最终导致某些纹理根本无法渲染。通过解决这个最终的转换案例，我们希望（！）最终将这个游戏放在床上。
现在，这些博客文章出现了一个新的重复部分：我们梦寐以求的“本月GPU供应商特定错误”奖。从上个月的获奖者英伟达手中抢走奖品是......AMD！现在，热心的读者可能会问“为什么它不与英特尔在整个草地上联系在一起？让我们告诉你，这很难，小组就这一判决进行了长时间的激烈辩论，但最终是由神奇宝贝传奇阿尔宙斯的彻底和灾难性的崩溃决定的，刚刚将 AMD 推向了领先地位。
从驱动程序 23.x.x 开始，我们希望这个问题能在几个驱动程序补丁中快速解决。小道消息告诉我们，其他程序在这些版本中表现出驱动程序错误，因此，我们等待。一个，两个版本与我们擦肩而过，仍然没有变化。好吧，我们自己做。
他们打破了转换反馈...再一次！我们已经不得不更改两次实现，但希望三次是魅力所在。
红与蓝，一个与时间一样古老的故事。Switch 上的一些客座 OpenGL 游戏利用了 GPU DMA 引擎中的特定功能，该功能导致了一些有趣的颜色交换。该功能本身或多或少是一个简单的随机播放，用于对纹理中的像素组件等内容进行重新排序。Switch OpenGL 驱动程序使用它来执行 BGRA（蓝色、绿色、红色 Alpha）到 RGBA（红色、绿色、蓝色、Alpha）数据转换。正如预期的那样，不实现此会导致永远不会发生此交换。在某些情况下，这似乎没什么问题，但如果你熟悉游戏的外观，它就会变得更加明显。
乍一看，如果认为这只是一天中的时间差异，那将是可以原谅的。其实不然。
为了在GPU部分鞠躬，让我们首先谈谈错误及其发生方式。每个人都是人，每个人都容易犯小错误，后果相当严重。话虽如此，我们讨论一下 Ryujinx 中的帧节奏怎么样？
帧旨在呈现，然后作为“准备就绪”传递到后端队列。从这里开始，可以使用任意数量的演示方法来动态显示它们，并且许多细节可以由 GPU 驱动程序和后端本身处理。理想情况下，在任何给定的帧速率下，所有帧都将准备好以等距时间间隔呈现，以产生流畅的体验。我们已经知道，这种情况已经有几年没有了，并且在此期间一直受到尖峰图的轰炸。
使用G-SYNC/FreeSync的具有VRR功能的显示器的用户显然受此影响较小，我们一直认为它一定只是后端的限制。Vulkan，尽管它的所有优点，没有任何普遍采用的方法从你的显示器查询显示时间，如果没有特定于平台的解决方法，比如Windows上的DirectX互操作层，这在Linux/macos上对我们没有多大帮助。
虽然以上都是正确的，但它没有解释 GPU 引擎代码中缺少的一行。我们最初将系统设计为在命令上等待长达 8 毫秒，作为故障保护，但有一个单独的中断事件，会导致帧在准备就绪后立即释放。有人为了自己的尊严而忘记发出这个中断事件的信号，因此在每个等待事件中有效地增加了8ms的错误。这在上图中很容易看出，因为帧时间偏差永远不会超过 /- 8ms，但严重的是它的波动性。如果编写的代码实际按照设计的方式工作，会发生什么......
仍然有一些时刻，主机：来宾 vsync 略有偏差，但这种情况要少得多。如上所述，每当 Vulkan 标准化查询显示时序的方法时，这应该会进一步改进。
MacOS 上游：
有几个人问我们这个部分上个月在哪里，最终归结为在给定的月份是否实际完成了任何事情。我们在这些进度报告中详细介绍的所有内容都是现在可用的东西，如果需要更大的更改，例如两个月，那么它将产生差距，这正是三月份发生的事情！
另一方面，gdkchan 完成了着色器生成器上属性处理的完整重构，该重构不到 1 行，应该可以解决 MoltenVK 下的大量着色器编译失败。在 macos<> 版本中，曲面细分几乎是不起作用的，除了简单的上游工作之外，我们还试图在某些进程可用之前清理它们的许多更原始的实现。
由于这项工作，曲面细分在使用它的游戏中正常工作，例如使用曲面细分着色器完全渲染的《英雄传说：从零开始的轨迹》。
其他受影响的游戏包括《巫师 3：狂猎》和后续关卡中的《路易吉的豪宅 3》（特别是沙子纹理）。
还对双源混合进行了较小的修复，这应该可以解决某些游戏中的崩溃问题，例如MoltenVK下的Metroid Prime Remastered。
由于这两项更改，更多的游戏最终应该可以在下一个版本中玩！不幸的是，我们没有任何时间表可以做到这一点，因为自 2 月以来所做的一些更改破坏了许多特定于 macOS 的解决方法，例如镜像和几何着色器仿真。考虑到一年中的时间，即将到来的发布时间表和优先级列表，只要我们所有的武器加起来，就不可能给出ETA。我们正试图安排时间来重新调整所有这些更改，但目前我们只能在这方面道歉，并希望当不可避免的“macos<>”发布时，它将是一个相当大的升级。
虽然严格来说可能是五月的变化，但对于那些希望跳枪的人来说，通用 macOS 版本现在是我们 CI 的一部分，可以从我们的 Github 版本下载（带有更新程序）。如前所述，许多性能和 GPU 解决方法尚未上游化，因此请逐个游戏尝试这些方法，风险自负！
转到一些与 CPU 相关的更改，回到每个人最喜欢的主题，荒野之息;最终的“随机”崩溃原因在四月份得到解决，这对我们在稳定性方面来说是一个伟大的里程碑。关于这次坠机事件，我们之前唯一的信息是，它有时发生在Lynels附近，也许在雨中，或者可能在山上，或者其他什么地方。调试不是一个好的开始。
值得庆幸的是，一位不和谐的用户发现有一个特定的神社谜题总是在某些物理交互中崩溃。
有了这些信息，很快就将错误跟踪到 CPU 重新编译器以及它如何处理浮点操作的 FZ/RM 标志。在寻找此错误时，对TPIDR_EL0和TPIDRRO_EL0寄存器进行了额外的小优化，因为 BotW 和 Scarlet/Violet 等游戏每秒访问它们数千次。这确实出现在 CPU 配置文件中，但不太可能显示任何显着的性能改进。
一些自制应用程序，如北欧化工，也需要我们实现剩余的ARM64 HINT指令。这些是未来CPU上使用的保留指令，在较旧的ARM处理器（如Tegra X1中发现的处理器）上不执行。这些通常用于相当平凡的任务，如指针身份验证，因此在自制软件之外没有用。
为了开始通常的“杂项”更改部分，我们想向贡献者 jhorv 大声疾呼，他目前正在 Ryujinx 中减少内存使用的战争道路上。仅在 20 月份，就进行了两次不同的更改，这些更改一起可以将小型/大型对象堆的大小减少多达 10%，从而将总垃圾回收时间减少近 <>%。查看下面的方便表格，了解任何想要查看大量数字的人。
在接下来的几个月里，你应该会看到更多这样的工作，虽然它不像游戏修复或巨大的性能提升那样华丽，但它仍然受到赞赏。
对于那些在索尼或第三方任天堂控制器上使用陀螺仪运动控制的人来说，您可能已经注意到，当保持静止一段时间时，Ryujinx 曾经不断地强行将轴重新居中。这在像Splatoon这样的游戏中引起了很多问题，在这些游戏中，准确的瞄准对于成功至关重要。
完全删除此重置功能似乎是最好的解决方案，因为仔细检查，它只是定期将运动滤镜设置为 1。然后，过滤器将返回到重置前的确切位置，然后再次重置。
为了完成这份报告，我们将对 4 月份发生的较小生活质量变化进行快速分析：
游戏类型（XCI、NSP、NCA、NRO）现在可以通过下拉切换隐藏或显示在游戏列表中。如果您将所有内容保存在一个文件夹中，这将非常有用。
网络接口选择器已从 LDN 内部版本向后移植。这意味着您现在可以主动选择用于访客互联网和 LAN 连接的网络，而不是 Ryujinx 选择默认网络。
主窗口现在将在关机时记住其大小和位置，并在启动时重新启动。这包括窗口是否最大化。
解决了“停止仿真”死锁的另一个原因。我们最终会深入了解这一点...
结束语
2023 年的三分之一已经结束，如果您询问我们完全公正的意见，Ryujinx 的状态从未如此好过。这一切都归功于我们的社区通过在我们的 Patreon 上捐款、为我们的 GitHub 存储库贡献代码或只是在我们的 Discord 上帮助其他用户所表现出的令人难以置信的支持。所有这些都意味着我们的开发团队可以花更多的时间来修复游戏，并使Ryujinx成为一个更好，更通用的程序。
与往常一样，如果您精通 C#（或任何基于 C 的语言），对仿真/现代 3D 图形感兴趣，想要改进程序的任何方面以修复拼写错误，或者只是需要一个大型项目来统计你的 GitHub 为即将到来的工作面试，我们一直在寻找能够带来新东西的人。虽然我们的核心团队可以创造一些奇迹，但开源软件的命脉一直是人们发现烦人的东西，并修复它。
我们期待着五月的到来，以及它可能带来的一切。
