Switch模拟器Ryujinx进度报告2023-12月（宝可梦睡眠2023）

Switch模拟器Ryujinx进度报告2023-12月

新年快乐！

我们希望每个人都能在 2024 年有一个良好的开端，并且希望你们都能在聆听这些定期漫谈的又一年中恢复活力。我们有相当多的事情要做，包括通常的图形修复，电池供电设备用户想要阅读的一个很好的内容部分，当然，我们通常每年都会总结一些不同的主题，包括 2023 年的兼容性和性能。

我们将从 Monster Hunter Rise （MHR）怪物猎人：崛起中经过认证的复古游戏开始。该游戏于 2021 年发布，在其整个生命周期中都收到了多次更新和 DLC，其中最新的更新自发布以来一直令人痛苦。从“Sunbreak”DLC 和更新开始，MHR 会在到达标题屏幕之前在启动时崩溃，并在缓冲区缓存中出现非常复杂的错误。

旧实现假设缓冲区所在的所有内存区域都是连续的（它们彼此相邻）。在大多数情况下，这个假设是正确的，但如果你能猜到一个标题，那么你可能具有平均的模式识别技能。为了解决这个问题，实现了对 Vulkan 备用映射功能的支持，该功能允许从多个物理缓冲区创建多范围缓冲区。

也许这里明显的缺点是该功能仅限于 Vulkan。OpenGL 在技术上确实支持稀疏映射，但不允许你选择它的映射位置，这使得它对我们的用例实际上毫无用处。macOS 上的 Metal 与 OpenGL 在同一条船上;虽然受支持，但它不能提供足够的缓冲区映射控制，因此限制也扩展到 MoltenVK。

然而，对于完全支持 Vulkan（Nvidia、Intel 和 AMD）的设备和驱动程序，Sunbreak 及更高版本终于可以玩了！

《时装设计师》（Fashion Designer）这款游戏肯定会在全球年度游戏排行榜上名列前茅，但它却出现了一个特别奇怪的故障。

虽然我们都是袜子的粉丝（圣诞节收到了大约 30 双袜子），但这似乎太多了。仔细观察，所有东西都太多了。

如果你是为数不多的玩时装设计师的人之一，那么这些图标中的每一个都意味着一件不同的衣服。重复是不好的。

我们的罪魁祸首位于纹理缓存中，在纹理刷新之前，所有内容都有特定的生命周期。首次访问纹理时，以及最终将其换成新纹理时，会设置每个纹理上的某些标志。时装设计师似乎将不同的对象渲染为相同的纹理，因此只有第一次使用纹理才能正确设置缓存标志。当游戏继续请求更多不同对象的绘制时，相同的对象纹理被多次复制。通过解决这个边缘情况，可以查看我们服装项目的完整排列。

暂时保持对纹理的古怪使用，当你在《妖怪手表 1》中捕捉到一只蝉时，一个漂亮的 2D 虫子图像将占据屏幕的很大一部分。不幸的是，由于一个可疑的声明使一个日志警告沉默，该警告会立即告诉我们问题所在，因此花了相当长的时间来追踪......错误。

无论出于何种原因，开发 Yo-Kai Watch 1 的团队决定在宽度为基本格式四分之一的纹理上执行图像存储，但将每像素存储的数据是 RGBA32 纹理的四倍。如果这听起来毫无意义，那就是，因为立即对该图像做了什么？它以 RGBA8 图像的形式访问，这是一种不兼容的格式转换！

向这些格式添加复制依赖项可解决 Bug 并还原 Bug。

这也是导致 Wet Steps 中严重图形损坏的原因。游戏仍然存在一些其他问题，但差异很大。

超级马里奥RPG在11月下旬发布时几乎没有错误，但我们眼尖的用户立即注意到马里奥本人和一些环境物体略显沉闷。虽然马里奥已经过了好几年，并且可能已经失去了他 GameCube 年轻时的光彩，但事实证明，在一些情况下，无绑定消除无法正常工作。如果着色器句柄通过不同的路径分配两次，则无法扩展无绑定消除，因为它无法找到句柄操作。但是，即使存在不同的路径，该值实际上也始终相同，因为一旦进入着色器通道，就无法修改任何相关数据。通过修复此问题，如果存在多个路由，则只需选择第一个值，超级马里奥 RPG 就可以正确渲染。

另一款突出了无束缚消除中未处理的边缘情况的游戏是《大侦探皮卡丘归来》。这个更微妙，但通过随机播放扩展可以解决整个游戏中的立方体贴图反射。

让我们花一个简短的时间来谈谈过去几个月中发生的一些较小但可能有趣的变化。

首次使用 amiibos 时（通过 AmiiboAPI），API json 将存储在本地，以便 amiibos 可以离线使用。

我们的最低 macOS 版本已增加到 macOS 12 Monterey。我们不确定为什么之前选择了 macOS 11，但它完全不适合 Switch 仿真！

一大堆字符串、时间和日期时间格式更改。修复了对游戏时间、文件大小和上次播放时间的向后排序，最重要的是，如果从未玩过游戏，则删除了大量垃圾日志。

“创建桌面快捷方式”实际上适用于macOS，并且还支持全屏启动。

好了，现在是“Ryujinx 博客教你计算机科学”部分的时候了。

Sleeping 睡眠

我们都知道睡眠很重要，对吧？不幸的是，正如许多人可能所关心的那样，实际上比看起来要睡正确的时间要困难得多。睡眠不足，然后感到疲惫，睡过头和错过火车是现代世界的普遍经历。计算机并没有那么不同。

当他们完成任务后，他们最想做的就是拉起羽绒被，在下一个纳秒的工作前小睡 6 毫秒。

Ryujinx需要在非常紧张的时间表上运作，而最好的方法实际上是不睡觉。没有一个桌面内核是真正“实时”的，从某种意义上说，我们不可能在一瞬间入睡，并在被问到时醒来。我们的请求总是有可变性和延迟（后面有漂亮的图表）。

Alternatives to sleeping 睡眠的替代品

睡眠的替代方法称为“旋转等待”，其中程序保留对 CPU 的控制权，并不断要求它“旋转”，直到触发事件，这将把 CPU 从这个旋转周期中释放出来。旋转可用于非常精细地控制 CPU 何时以及如何停止和开始执行程序中的线程，但有一个主要的缺点：它仍然处于活动状态并一直使用电源。将睡眠与旋转等待视为睡觉和坐在候诊室之间的区别。如果候诊室提出要求，您可以更快地做好准备，但与睡梦中有人打电话给您相比，您的休息时间更少。

The problem 问题

现在我们已经了解了术语，让我们看看问题所在。如果我们有一个线程，监控一个想要一次等待 1 毫秒的事件，我们完全没有问题。

几乎所有三个主要操作系统都将允许我们以 1 毫秒的粒度睡眠，并能够在正确的时间唤醒。但是，请考虑相同的场景，但同一线程上有 10 个不同的等待事件，所有事件彼此不同步 0.1 毫秒。

现在我们开始遇到问题。直到 2023 年底，我们使用的解决方案是简单地在这些等待中旋转，但正如你所看到的，这意味着整个时间都在旋转，因为我们需要处于唤醒状态来处理每 0.1 毫秒即将唤醒的线程。

我们在上一份报告中谈到了对“ServerBase”的更改，该更改每 1 毫秒停止轮询一次。由于上述问题，这大大降低了 CPU 利用率和电源使用率。ServerBase 是我们必须处理的大量并发等待的主要贡献者。不幸的是，它只是请求持续等待的众多线程类型之一;游戏线程也是一个同样重要的问题。

那么，我们该如何向前迈进呢？在过去的几分钟里，CS书们一直在对着屏幕大喊“nanosleep！”，他们说对了一半。

Linux/macOS Linux/macOS 操作系统

Linux 和 macOS 都提供“nanosleep”系统调用来等待精确的纳秒数。纳秒精度足以处理我们上面的场景，所以让我们试一试。

经过测试，我们发现纳米睡眠并不像它的名字所声称的那样精确。在非常低的纳秒值下，我们看到非常一致（且很小）的唤醒误差值，但是一旦达到0.5ms的阈值，就会发生巨大的误差峰值，最终在1.5ms左右趋于平稳。

奇怪的是，macOS再次具有不同的行为。在微小的等待请求中，系统调用非常准确，睡眠请求的误差最小，低至纳秒。不幸的是，该误差与请求的等待时间成正比，并且不断攀升，直到我们看到要求 3 毫秒睡眠时延迟近 0.5 毫秒，而要求 20 毫秒睡眠时延迟超过 3 毫秒。

虽然这些听起来很糟糕，但我们想要的用例已经是针对那些较小的睡眠时间，因此 macOS 和 Linux 都可以通过 nanosleep 获得有效且简单的方法。

让我们来谈谈 Windows...

Windows 窗户

到目前为止，Windows NT 内核是所提供的三个主要选项中最不“实时”的。它没有纳米睡眠等价物，因此在如何处理我们的睡眠问题方面受到高度限制。默认情况下，您可以休眠到 1 毫秒的精度，正如我们希望重申的那样，对于低至两个并发等待（每个间隔 0.5 毫秒）来说还不够好，更不用说 10 秒了。那么所有的希望都破灭了吗？1ms真的是我们能做的最好的吗？我们很聪明，所以答案是：不。

在大多数x86_64系统上，您可以对时钟分辨率执行查询，并发现实际上存在 0.5ms 分辨率的“基本时钟”，也许更有趣的是，默认情况下，您执行的任何等待都将自动与最近的“基本时钟滴答”对齐。如果你睡觉时没有思考，这意味着你的线程可能会因为与下一个基本刻度对齐而醒来得很晚。但是，如果您掌握了这些信息，并且对下一次滴答何时发生做出了非常明智的猜测，则可以将睡眠时间精确到0.5毫秒，并且几乎总是在睡眠之前醒来。

不过，这些都不能解决我们的 10 个并发 1 毫秒等待问题。如果我们检测到等待事件与基本时钟对齐或非常接近，我们可以允许系统对齐等待并在下一个时钟滴答之前唤醒。如果等待不是基本时钟对齐的（或者非常精确，如0.01ms），那么不幸的是，NT内核没有为我们提供任何解决此问题的方法，除了在需要的地方继续使用旋转等待之外。

下课了，让我们看看这一切到底做了什么。我们之前说过，整个事情是关于 CPU 使用率和功耗的，所以更多的图表似乎是有序的。

苹果和Linux设备将在这里看到最大的好处，在相同的帧速率和分辨率下，效率提升非常令人印象深刻。《王国之泪》被削减了近 40%，《荒野大镖客：救赎》和《旷野之息》都出现了非常健康的 15-20% 的转变，而《宝可梦紫》几乎以 75% 的减少减少了一切。从角度来看，这是一款 M2 MacBook Air 模拟 Pokémon Violet 的效率高于 Switch 原生播放的效率。

在游戏领域，如果游戏的功能不太像标题屏幕，或者当模拟暂停时，在 Steam Deck 等设备上会看到一些疯狂的减少。

这些变化可以延长电池续航时间，同时降低热节流的幅度和频率，尤其是在 MacBook Air 系列等无风扇设备中。它还允许设备在实际需要的时候达到并保持其加速时钟，而不是不断被诱骗在菜单上和暂停时加速。如果这些听起来都不酷，那么我们在您的下一次能源账单上为您节省了一些钱，要么接受，要么离开！

最后，对于那些觉得我们决定用 C#/.NET 编写这个东西很有趣的人，我们在 11 月更新了一个新的、闪亮的 .NET 版本：.NET 8（它们发展得如此之快......Microsoft 总是提供一份绝对庞大的文档，说明他们每年带来的所有性能改进，但对我们来说，它们通常可以提炼成我们获得专利的超级马里奥奥德赛杆基准。

在 2023 年 .NET 大会期间，这个博客也得到了一个非常酷的提及，作为他们关于动态 PGO 的精彩演讲的一部分。

2023 roundup! 2023 年综述！

那么，2023 年对我们来说总体上如何？好吧，让我们来看看，好吗？

希望你们都还不厌倦图表。

我们在 2023 年的兼容性列表中添加了 700 多款游戏，这使得在 Ryujinx 上测试（和报告）的游戏总数达到 4255 款。其中超过 83% 的游戏被报告为完全没有图形、技术或稳定性问题，另有 12% 的游戏至少存在一个问题。此类别主要包含具有轻微图形故障或稳定性问题的标题。在其他标记系统中，它们也可以被认为是可玩的。剩下的 4.5% 的标题只在菜单上有所进展，如果有的话。

就性能而言，我们在自己常用的游戏套件中同比平均提高了 36%。像往常一样，这高度依赖于游戏和硬件。