Switch模拟器Ryujinx进度报告2023-5月
我们可以在这个美好的月份为您提供进度报告
王国之泪，恢复了君主制，我们已经看到了一艘功能齐全、多级可拆卸的飞船，在塞尔达游戏中配备了巡航导弹系统和肉烤架。确实，大自然正在治愈。如果你还没有猜到，这个月几乎完全被那个讨厌的金发公主垄断了，但不要害怕，我们确实在游戏会议之间找到了时间来处理大量的更改、修复和改进。
我们将为最后保存一些特别的东西，但现在，让我们开始吧。
我们从这个月开始，不是某个AAA版本，而是最近发布的恶魔*手 - Kimetsu no Yaiba。 虽然该节目的艺术风格以电子游戏格式非常忠实地再现，但粉丝们很快注意到许多模型和纹理看起来很模糊，几乎具有电视静态效果。
如上所示，这种雾度是由着色器操作中非常小的浮点误差引起的。在编译器优化的输出中，在“gl_FragCoord.w”及其倒数（1/gl_FragCoord.w）之间发生了冗余乘法运算。虽然在纸面上，这些应该取消，但不幸的是，计算机并不像纯数学那么简单。删除此乘法步骤后，浮点误差随之消失。
我们现在如何谈论塞尔达？但就目前而言，它必须是《荒野之息》。正如上个月提到的，这款游戏的大部分性能优化是在 5 月份进行的，其中有一系列变化，实际上也确实在其他几款游戏中开始运行。
没有任何池引用的渲染纹理现在保持活动状态，以避免重新创建。BotW 的 1.6.0 版本开始清除/写入纹理，但从未实际采样它们，这给 Ryujinx 的纹理缓存机制带来了很多麻烦。
顶点缓冲区更新，现在在 Vulkan 中批处理。避免单个顶点缓冲区更新以减少绘制调用。小幅改进，在游戏和GPU驱动程序上会有很大差异。
现在允许从常量缓冲区更新进行粒度缓冲区更新。常量缓冲区更新过去作为完整的 4096 字节块上传;通过跟踪自上次更新以来的偏移量，我们只能上传代表最新缓冲区更新的范围。这大大减少了 Korok 森林中每帧上传的字节数近 50%。
Vulkan fence Manager 和 MultiFenceHolder 被简化。MultiFenceHolder内部使用了许多瓶颈和缓慢的数据结构，这些瓶颈和数据结构被大幅削减。改进了任何后端瓶颈游戏的性能（这是特定于系统和游戏的）。
已删除 CPU 区域句柄容器。这是一个相当愚蠢的加速，因为我们通过中间访问 CpuRegionHandle 对象，而不是简单地直接引用它们。这是一个非常小而简单的变化，但由于每帧使用量巨大，我们看到《超级马里奥奥德赛》的性能提高了 5%（原始绘制计数性能的良好基准）。
经常刷新的纹理现在会预先刷新到主机导入的内存（如果可用）。《荒野之息》是浪费从线性纹理中读回数据的巨大罪犯;脚在地形上的位置，物体/链接位置的水位，甚至一些用于为水下地形着色和填充草地的信息。如果你做得不好，游戏基本上会中断。将此类纹理预先直接刷新到 CPU 可访问内存会跳过 GPU 在复制数据时执行的大量等待。在理想情况下，当纹理布局为线性时，它甚至可以跳过另一个步骤，通过直接导入内存直接复制到 GPU。塞尔达传说：天空之剑HD也是读取纹理数据以检查太阳是否被遮挡的恶魔，并且在这里也看到了显着的收益。
毕竟，让我们看看几个标题的结果：
作为过去 2 个月中大多数与性能相关的更改的测试标题，在《荒野之息》中看到我们的测试系统非常健康的 30% 提升也就不足为奇了。如前所述，仅从先发制人的同花顺变化来看，《天剑HD》就看到了25%的不成比例的提升。还记得它用来回读太阳遮挡数据的纹理吗？那东西是全脂1920x1080 RGBA8！像往常一样，《异度之刃编年史》DE不知何故从我们所做的任何事情中偷偷地取得了一点改进，但XC2在主要城镇中心也实现了28%的提升。
关于Xenoblade的话题，DE和2设法成为修复一些烦人但简单的图形错误的催化剂。在从522.XX开始的Nvidia驱动程序和几乎所有AMD驱动程序上，XC：DE，XC2和Bayonetta 3都表现出主要的图形伪影。这通常仅限于《异度之刃》游戏中的UI元素，但在刺刀中表现为完全成熟的神射线，遮挡了大部分屏幕空间。
由于非常具体的渲染方案，在某些情况下，由于检查的顺序，无法正确设置正确的障碍。通过调整屏障检查的时间，可以正确插入屏障。
手续上已经够好了。王国的眼泪...*鼓掌*...女士们，先生们，我们又做了一次。我们的第 1 天可玩游戏奖杯柜获得了可能是迄今为止最大的荣誉。团队对此感到非常自豪，因为它继续向我们保证，我们正在正确地完成整个仿真工作！不过，自我奉承已经足够了，体验肯定不完美，所以让我们讨论一下出了什么问题，以及我们如何解决它。我们将尽量保持本节无剧透，但与使用屏幕截图的领域一样，请自行承担风险。
最直接的图形问题几乎可以立即被发现。岩石和墙壁纹理散落着白色方形文物，如下所示：
这些斑点是由ASTC解码器中的一个错误引起的，该错误在LuminanceDelta模式下设置了不正确的端点。这影响了所有不拥有具有本机 ASTC 支持的 GPU 的用户;具有讽刺意味的是，基本上除了Mac用户之外的所有人。
眼尖的读者可能已经在上面的两个屏幕截图中发现了下一个问题。这些文本框在《荒野之息》中看起来肯定不是这样，而且在《王国之泪》中，它们似乎设置了错误的旋转纹理。通过显示失败完全匹配条件，我们可以强制创建正确旋转的 D32 纹理。此更改还解决了Mario Kart 8 Deluxe中一个非常古老的错误，其中返回角色选择屏幕有时会破坏角色模型立方体贴图，导致它们显示为纯银色。
在最明显的错误列表中向下移动，游戏在发布时会遇到看似随机的崩溃，理由是游戏时间一小时左右后出现无效的内存区域错误。这实际上是由着色器缓存将当前着色器使用与不同着色器的地址匹配引起的。当不同的着色器被部分取消映射时，就会出现问题，从而导致崩溃。通过仅读取着色器的映射部分，这将立即使比较条件失败，而是编译/查找正确的着色器。
回到你实际可以看到的东西，Vulkan 后端在使用数组纹理的深度比较时禁用了显式 LoD。室内设计和许多基于阴影的照明受到严重影响。这似乎是 Vulkan 过去从 GLSL 交叉编译时遗留下来的一些遗留代码，因为那里不支持扩展。通过消除这种多余的阻塞，问题就消失了！
就供应商特定的错误而言，王国的眼泪带来了很多包袱。对于Nvidia用户来说，Vulkan后端的性能比应有的要差得多，在某些情况下比OpenGL慢57%。当缩放到更高的分辨率时，差距只会扩大。这里的问题具有疯狂的讽刺意味;几个月前，我们实施了一个系统，在设备和主机内存之间迁移数据，这几乎帮助了所有游戏。不幸的是，《荒野之息》受益于完全相反的缓冲位置，因为《王国之泪》和实现显然是针对前者而不是后者进行调整的。通过设备映射任何写入多于刷新的缓冲区，Nvidia GPU不再在这里屈膝。
AMD也未能幸免聚光灯。深处的阴郁似乎通过计算发出 LoD 纹理采样指令来发挥作用。虽然这在Nvidia特定的Vulkan扩展中在某种程度上是有效的行为，但在AMD Windows上，这会导致来自计算的纹理采样失败并造成“阴郁损害”，即使Link显然没有站在它附近的任何地方。
似乎其他驱动程序只是忽略了这种无效行为并将 LoD 采样为 0。通过检查指令是否专门用于片段，幻影阴郁已成为过去。
导致问题的深度似乎是一个主题，因为许多用户在随机探索后报告了显著的性能波动。在那里，王国之泪使用全局内存访问，地址在常量缓冲区插槽 6 上。这不是标准，因此不是我们期望的大小;这导致我们读回的垃圾大小最终非常大，这将每帧同步大量数据。调整我们计算缓冲区大小的方式应该将其绑定到合理的大小并阻止它进入其他内存。
每个人都可以享受的东西，Z-fighting。Z 轴战斗是 3D 场景中的一种现象，如果两个“对象”非常接近，它们在 z 轴上看起来具有几乎相同的深度值。当这种情况发生时，相机可以有效地看到两者的随机几何形状，作为闪烁效果，因为两者都“战斗”以“处于领先地位”。
在TotK中，这种效果可以在远处的几何体上看到，其深度值不如靠近相机的物体精确。
添加对“VK_EXT_depth_clip_control”的支持，可以显着减少大型几何战斗的体积。还有工作要研究剩余的战斗，但现在应该隔离放大镜头。
唉，如果游戏拒绝以超过 20FPS 的速度运行，那么上述渲染和性能的所有改进都毫无意义。《荒野之息》和《王国之泪》都使用双缓冲 VSync 实现，可以根据切换的性能在 30FPS 和 20FPS 目标之间动态切换。如果它开始丢帧，游戏可以简单地切换到 20FPS 模式并保持其速度。它怎么知道它的表现是否糟糕？通过使用当前帧处 GPU 的时间戳。似乎 Ryujinx 错误地报告了它的时间戳，因为通过简单地强制游戏启动时的第一个时间戳为 0，从而使所有未来的时间戳都偏离 0，TotK 似乎终于意识到它不是在土豆上运行！
为了完成这个广泛的塞尔达部分，一些新的着色器格式以p2rc，p2ri，p2rr和 r2p.cc 的形式实现 。 我们实际上不确定它们的用途，但日志控制台似乎偶尔会发出“不支持的格式”警告，因此它确实在某处使用了它们！找出地点，我们将为您提供奖品*。
*我们允许您沾沾自喜不超过 3 秒。
苹果操作系统开发：
本月，macOS的上游工作继续快速进行，包括合并一些相当庞大且重要的更改。
正如我们上个月提到的，通用 macOS 软件包现在是我们主构建管道的一部分。这允许 macOS 上的用户从我们的发布页面下载完全最新的前沿版本的 Ryujinx。请注意，并非我们为“macos1”版本所做的每个 Apple Silicon 特定优化都已合并，因此许多游戏的性能可能更差/渲染方式不同，这就是我们仍然链接到我们网站上的原始版本的原因，因为它目前具有更大的兼容性配置文件。这种情况应该很快就会改变。
一些不同，多样和有趣的MoltenVK错误在五月份得到了解决方法，最终结果是像Xenoblade Chronicles 3这样的游戏现在可以在macOS上非常体面地呈现了。
我们希望你不会厌倦王国之泪，但似乎所有的道路都通向那里。出于某种未知和诚实的奇迹原因，游戏不仅在第 1 天运行，而且更有趣的是，与其前身不同的是，它并没有立即*死虚拟机监控程序。这对每个人来说都是个好消息，因为直到今天，《荒野之息》仍然需要使用慢得多的JIT，而《王国之泪》可以原生地执行其所有代码。我们感谢任何改变它的游戏开发商！
这并不是说苹果用户没有逃脱错误爆炸。巨大的顶点爆炸困扰着游戏，当林克穿着特定的衣服或根本没有衣服时。通过截断任何超过步幅的顶点属性格式，我们阻止 MoltenVK 向 Metal 提供不正确的顶点值。
第二个问题再次与服装有关。在这里感觉到一些偏见...某些服装和世界几何体上会出现闪亮的亮白点，虽然看起来很酷，但显然是着色器中某个地方的垃圾值。
有时，游戏可能会向值添加非常小的偏移量，以完全确保它永远不会用于可能导致除以零的操作中。这是有道理的，除以零对于计算机来说肯定是相当糟糕的。如今，计算机也非常智能，着色器的编译器通常会尝试优化任何它认为不正确、浪费或效率低下的东西。随机向东西添加微小的值是编译器毁掉你一天的主要领域，就像这里发生的那样。幸运的是，值可以在SPIR-V中被定性为“精确”，这使得它们在优化阶段可以很好地保持独立。
虽然渲染在最新版本上进行了相当的排序，但许多更密集的游戏（包括TotK）仍然需要实现缓冲镜像才能表现良好。我们在最初的博客文章中介绍了这一点，但作为TL;DR，他们试图弥合桌面类型GPU（如Switch中的GPU）和移动型GPU（如M1 / M2芯片中的GPU）如何渲染图形之间的差距。目前正在进行合并的工作正在进行中，而不会对Windows和Linux用户产生负面影响，这对于macos1来说，我们真的不需要担心这一点。
虽然这些变化肯定是华而不实的，但 gdkchan 一直在忙于在多个拉取请求中有效地重新设计着色器后端的大量内容。这项工作的最终目标是以比macos1中使用的方法更简洁、更易于维护的方法实现转换反馈和几何着色器的仿真。
梅为这项事业带来了三个部分的最后基础：
将着色器上的常量缓冲区访问替换为新的“加载”指令。将“ConstantBuffer”操作数和“LoadConstant”指令压缩为单个“Load”指令，从而降低后端复杂性并提高灵活性。此更改还修复了 AMD GPU 用户在超级马里奥银河（3D 全明星）中 Windows 上面临的顶点爆炸问题。
在 IR 上生成缩放帮助程序函数。此更改将所有分辨率缩放代码从 SPIR-V 和 GLSL 后端移出，并移动到单个同构帮助程序函数中。这最终意味着更少的代码，更少的工作在未来实现更多的后端，并降低任何当前或未来后端之间发生差异的可能性。
将 ShaderBindings 替换为 Vulkan 的新 ResourceLayout 结构。ResourceLayout 用于在 Vulkan 上创建 PipelineLayout，而不是具有 2 个硬编码布局（一个用于游戏着色器，另一个用于后端的辅助着色器，称为“最小布局”）。由于我们需要为转换反馈和几何着色器模拟保留额外的存储缓冲区，因此 PipelineLayout 也需要有所不同。此更改允许以简单的方式完成此操作。
随着这些现在已经到位，转换反馈仿真的第一个拉取请求是开放的（现在已经合并了，但是嘘，把惊喜留到下一个报告），随后是地理着色器。我们知道这花了相当长的时间，但与我们第一个macOS版本采用的相当复杂的解决方案相比，团队对重塑允许的实现更加满意。
回到我们通常的时间表...
当模拟仍在积极开发的操作系统时，很容易被扫地出门，忘记自从最初进行逆向工程以来，事情可能已经发生了变化。因此，是时候重新关注...时间服务。通过固件 15.0.0 中这些的完整 RE，我们不仅能够确保至少另外几个版本的准确性，而且还偶然发现了一些旧错误。此更改最终修复了剑/盾中完全静态定时的神奇宝贝作业，以及可能使用定时事件的其他游戏。如果你问我们，是时候了。
除了 RE 工作之外，我们的常驻音频大师 Marysaka 回到了音频渲染器，修复了《王国之泪》中的一些音频错误，并在将 SDL5 后端与兼容的游戏和扬声器系统一起使用时实现了对全 1.2 环绕声的支持。
大多数第一方 Switch 游戏实际上都支持环绕声，因此对于有空间的人来说，这一变化是受欢迎的！
为了完成我们的最后，让我们通过一个快速的回合来嘎嘎作响，以获得一些更利基但奇怪的有用改进：
游戏的 BuildID 现在通过作弊管理器公开。这应该可以使您更容易制作自己的作弊/相应地命名您的作弊文件，而无需求助于 JKSV 等自制软件。
现在，如果认为 vm.max_map_count 在 Linux 上太低，它会自动增加。一些游戏，大量的UE4游戏，在运行时会分配大量的内存，在这里需要更高的限制。
DelegateHelper 已替换为 CPU 重新编译器中预生成的委托。 这将从 ARMeilleure 项目中删除所有对 System.Reflection 的使用;离与 NativeAOT 兼容更近了一步。
最后但并非最不重要的一点是，“停止仿真”，一个感觉介于无用和俄罗斯轮盘赌之间一段时间的按钮，现在终于应该起作用了......在大多数情况下。本月，从GUI，ServerBase，CPU和大多数GPU代码中分离并解决了另外四个死锁原因。噩梦应该大部分结束了。
结语
我们说我们有什么很酷的东西吗？对此有所了解。
这就是我们这个月为你准备的全部内容！如果您喜欢我们的工作并希望向我们提供帮助，您可以查看我们的 Patreon，在我们的 GitHub 上漫步，或加入我们的 Discord。按照我们通常的说法，开源软件是由世界各地的人推动的，他们发现一些烦人的东西，并修复它。我们烦人吗？好吧，你知道该怎么做。
谢谢大家的阅读，我们会在一个月后回来！
