2022 年 6 月进度报告

亲爱的朋友们，我们在 6 月份取得了惊人的进展！ 驱动程序错误正在被消除，内核和 CPU 改进，UI 和输入更改等等！

面向 AMD Radeon 用户的 PSA（以及 NVIDIA 标签）

我们从上个月提到的Vulkan 扩展 VK_KHR_push_descriptor终于到了 AMD 硬件的驱动程序版本 22.5.2 for Windows上，但它并不稳定。 Radeon 用户会告诉您，任何游戏在更新后都会在 Vulkan 中崩溃。 为了缓解这种情况， toastUnlimited 为 AMD 的 22.5.2 win驱动（及其 Linux AMDVLK 驱动包）2.0.226 的特定 Vulkan 驱动程序版本部署了一个扩展块。

最近的一个月，新的 22.6.1 驱动程序发布 VK_KHR_push_descriptor固定的！ 但是，有一个但是，新的驱动程序报告了相同的 Vulkan 版本，2.0.226，这迫使我们的开发人员进退两难。 由于扩展块只能与 GPU 驱动程序报告的内容（22.5.2为 Vulkan 驱动程序版本）一起使用，我们可以保留该块并确保与旧的损坏驱动程序兼容，或者删除该块并强制用户更新到当前版本（在撰写本文时）22.6.1 驱动程序。 我们选择了后者， 因为它使代码库更干净，并且有一些证据表明这可能会解决使用 FreeSync 显示器时发现的输入延迟问题。

具体来说，AMD（Polaris 和更新版本）仍支持显卡的 AMD Radeon 用户必须更新到最新的视频驱动程序，22.6.1 或更新版本，以获得适当的 Vulkan 支持。 不支持旧卡（GCN 1 到 GCN 3）的用户不必担心，硬件已经无法更新到较新的驱动程序（自定义驱动程序也无法更新 Vulkan 以添加新扩展），yuzu 将使用无需支持即可工作的较慢代码路径 VK_KHR_push_descriptor.

好的，这涵盖了 Radeon 用户。 让我们谈谈nvidia方面。 随着 516.XX NVIDIA 驱动程序系列的发布，在 Vulkan（即 3000、2000 和 1600 系列卡）下运行的 Turing 和 Ampere GPU 的性能似乎有所提升。 很棒，但它是有代价的。

Maxwell 和 Pascal 用户（1000、900、750 和 745 系列卡）在 Vulkan 中运行游戏几分钟后会遇到设备丢失崩溃的情况。 设备丢失基本上意味着驱动程序出于某种原因突然没电了。 在我们找到此问题的原因并实施修复或向 NVIDIA 报告之前，Maxwell 和 Pascal 用户应坚持使用 512.XX 驱动程序。

用一堆警告开始一篇文章总是很无聊，但这是我们可以用来接触尽可能多的受影响用户的办法之一。（A卡用户使用22.6.1驱动 N卡用户包括1000系及以下用户暂时继续使用5.12.XX驱动，1600以上使用最新驱动有所提升）

图形变化

我们应该涵盖 第一部分的 Project Y.F.C.在这里，但由于日程安排问题，它被移到下一个报告。 对于给您带来的不便，我们深表歉意，我们将确保在下一篇文章中进行介绍。 好消息是，还有其它有趣的 GPU 改进要报告。

Behunin 回来了， 为我们的 gpu_thread， “一个有界的多生产者多消费者并发队列” 。 这提供了 1 或 2 FPS 的小幅性能提升，但更重要的是，在与负载相关的卡顿尖峰之后有更好的恢复时间。

深爱的 上古卷轴5：天际，曾经被认为是开放世界游戏的标杆，直到更好的游戏问世，即现在可以开机！ Skyline 模拟器 开发者 章程 找到了这个经典直到现在拒绝启动的原因： 第一个值的假定行为 GPU 相关的 信号量 是错误的，它应该执行释放而不是返回一个常量零。 现在，由于章程的这一伟大发现，Dovahkiin 终于可以在那辆购物车中醒来了。

上古卷轴V：天际

你可以看到我们还有一些渲染问题需要解决。

我们最近的一项重要渲染更改是 NVFlinger 重写 ，谁会猜到编写更接近 Switch 的实现会带来更流畅的游戏体验？

然而，在它发布后，用户报告提到了游戏中的时间和帧节奏问题，例如 任天堂明星大乱斗特别版. 比赛时间会越来越慢，在AMD Ryzen 系统上每分钟增加一秒左右，而英特尔 Alder Lake CPU（第 12 代）会加剧比赛时间。

解决方案 bunnei 与人们的想法相反， 实施一种 不太准确 行为。 yuzu 是多线程的，而且非常多线程（即使它没有显示在 CPU 百分比使用图中），并且 NVFlinger 的 100% 准确实现对于模拟器的要求来说不够敏感。

除了奇怪的 CPU 架构，虽然问题得到了解决，但建议 Intel Alder Lake 用户运行最新的 BIOS 和芯片组驱动程序版本。 检查您的主板/笔记本电脑支持站点以获取这些更新。

虽然仍然是关于 NVFlinger 好东西的话题，但我们提出了一个非常需要的功能！ 老用户会记得，在单线程时代，yuzu 可以控制游戏速度。 随着多核（当时被称为 Prometheus 项目 ，该功能仅在单核模式下可用，这让许多人感到懊恼。 时光飞逝！

yuzu 现在可以控制帧时间计算， 允许一种新方法来不受 CPU 仿真模式的限制！ 您可以在 模拟 > 设置… > 通用 > 运行速度限制中找到该选项. 不用说，如果你想让一个游戏跑得更快，游戏应该允许它，你必须有硬件性能才能达到新的目标速度。

和以前版本没有视觉上的变化，但是全新的功能

调试器

现在，我们将在这里潜入一些开发者天堂。

几个月前，yuzu 开发者 byte[] 发现自己试图调试 yuzu 中的一些游戏问题，其中涉及 某只威尔士猫 等。 不幸的是，他很快就遇到了更多的麻烦，因为要查看游戏的内部状态并观察或修改它们的行为，而不需要大量破解柚子，这是非常困难的。

痛苦的根源在于无法在模拟游戏中使用调试器。

原本，柚子继承了一个 GDB-compatible debugger interface来自 Citra ，但它缺少许多重要功能。 期间也不得不弃用 Prometheus 项目 由于其固有的缺点

它仅适用于单核模式

很 慢 - 有时可能需要 30 多分钟才能启动游戏，尤其是在您有任何日志记录脚本的情况下

它有一些重要的代码质量问题

在 Prometheus 重写期间被移除后，yuzu 很长一段时间都没有 任何 调试器接口。

等等，GDB 又是什么？

GNU 调试器 (GDB) 是一个可移植的调试器，可在许多类 Unix 系统上运行，并适用于许多编程语言，包括 Ada、C、C++、Objective-C、Free Pascal、Fortran、Go 和部分其他语言。

– 维基百科

使用 GDB，您可以：

逐条指令逐步执行代码

即时修改内存和寄存器

甚至完全动态地替换运行代码的部分

因此，您可以看到拥有一个 GDB-compatible debugger interface是对于开发人员和模组创建者来说，您现在可以调试游戏、自制软件和游戏模组，而无需每次都摆弄控制台。

一个 32 位示例，在本例中为超级马里奥银河

挑战

在旧的调试器接口被弃用后，社区的一些成员对其进行了分叉并继续对其进行修补和维护。 一些值得注意的是 Hedges 和 astrelsky 。 多亏了这些分叉，byte[] 才能够在 yuzu 中添加 对 Wii Hagi 模拟器的初始支持 。

然而，他很快就遇到了一个更烦人的问题。 最近对柚子 CPU 仿真的更改 导致超级马里奥银河 陷入僵局 。 这个问题只发生在多核模式下，就在第一个视频过场动画结束之后。 他没有想法，需要一个功能调试器来继续调查这个问题。

由于旧的调试器接口不支持多核模式，byte[] 必须从头开始。 出于解决问题的动力，byte[] 开始为 yuzu 开发与 GDB 兼容的新调试器接口，他有非常具体的目标：

它应该可以工作

它应该很快就解决了，这样他就可以更多地关注根本原因

俗话说，“第一步总是最难的”。 而对于 byte[]，确实如此； 他最大的挑战：“不知道从哪里开始”。

byte[] 编写并运行了网络代码，但最初并不了解如何将其与线程代码联系起来。 在与其他开发人员进行了一些有效的头脑风暴会议后，他最终找到了解决他所面临挑战的解决方案。

变化

由于他是从零开始，byte[] 借此机会对界面进行了一些急需的改进。

旧的调试器界面基于“步进”仿真 CPU 内核。 Stepping这里的意思是一次执行仿真程序的一条指令。

这带来了许多问题，因为几乎所有游戏都有多个线程，如果您正在步进并且一个线程要求等待，那么另一个线程可以开始在同一个 CPU 内核中的位置运行，所有状态都发生了变化。 这会破坏连续性，甚至会使调试器崩溃。

新的调试器界面 通过在线程上执行调试单步而不是单步仿真 CPU 内核来克服这个问题。 在 yuzu 的上下文中，当一个线程被单步执行时，调试器会要求该线程单步执行，然后 Dynarmic 接口会检测到这种情况并告诉 Dynarmic 单步执行，当线程再次被调度时，它会标记该线程已单步执行并再次通知调试器。

超级马里奥奥德赛，乱码形式

有什么好处？

除此之外，我们还有一些更显着的效果 (QoL) 增加。 调试器接口现在是线程稳定的，现在可以处理步进和暂停中的边缘情况，并且它具有大量有用的调试功能，例如：

支持 32 位和 64 位代码

能够随时修改任何内存和寄存器

来宾线程名称的读取

支持无限数量的指令断点

支持多达 4 个内存观察点

用户界面更改

在谈论用户界面和体验时，您总是可以依靠 Docteh 。

在重复 Morph 在 2 月份修复的内容时 ，Docteh 发现在崩溃后，柚子主窗口可能会以某种无边界全屏的方式重新打开…… 事件 。 罪魁祸首 是 UILayout\geometryyuzu 的 qt-config.ini 文件中的值。 现在，这个问题应该永远消失了。 非常好。

为了帮助新用户适应柚子，Docteh 将状态栏改名为 DOCK文本（过去只改变颜色以反映其状态）到 主机/掌机模式更为直观. 现在当前的模拟状态更加清晰，用户在使用深色或浅色主题时不会混淆它。 永远不要低估让事情更容易理解的重要性。 汽车制造商总有一天应该尝试一下：）

状态栏细节变化

翻译的错误总是设法偷偷跑掉。 第一次打开 yuzu 时，它会显示一个带有加号图标的大文件夹，要求用户添加游戏转储的位置。 如果用户将界面语言从 模拟 > 设置… > 通用 > 界面 > 界面语言. 解决这个问题 需要对窗口处理重新翻译的方式进行一些更改。

翻译的变化

Docteh 也在偷偷地 做一些迁移到 Qt6 的初步工作 。 这 QDesktopWidget类 现在已正式弃用 ，所以 QScreen取而代之。

此外，一些影响 Web Applet 的类也已被弃用，因此 进行了一些调整以确保未来的兼容性。 希望 Qt6 将意味着默认情况下 Web Applet 的回归？

一旦我们准备好迁移，这应该会提供更好的动态 DPI 缩放，例如，允许 4K 显示用户最终了解控制设置窗口中发生的情况。

输入改进

按键输入 是 German77 的 专长，是一颗“未加工的钻石”，一次只打磨一个 PR，直到永恒……。

继续工作 Ring Fit Adventure, German77 打断 了 PerformSystemButtonPressingIfInFocus服务 , 解决了按 ZL 或 ZR 时发生的 SVC (Supervisor Call) 崩溃。

随着固件版本 13.2.0 的官方 Switch 更新，任天堂实施了新的 GetVibrationDeviceInfo. 虽然 German77 致力于实施这些更改，但其中一款游戏尤其拒绝工作， 颜料宝贝. 当这个游戏发送一个控制器断开信号时，它使用一个 -1值，这是无效的，因为在 Switch 上只接受无符号值。 也许这是某个地方的仿真问题，或者这个游戏只是喜欢这样做，而 Switch 只接受无效值。 无论如何，我们的解决方案是 复制这种特殊行为。 最终结果是 颜料宝贝现在可以进入游戏！

颜料宝贝

内核和 CPU 更改

可能是 yuzu 代码中最沉默的部分，但也是最关键的部分。 内核仿真是使所有部分协调工作的引擎块，因此您可以预期，即使更改其中的一小部分也会在任何地方产生连锁反应。 一定要小心翼翼。

反正这个月byte[]在这个微妙的领域特别忙，手里拿着螺丝刀，什么都不怕。 一些变化包括了解最新的逆向工程发现，但还有更多。

为了帮助实现暂停和恢复功能，他 实现了 KProcess 暂停， 正如拉取请求所解释的那样，“为此而设计的内核机制”。 当您不得不离开电脑去做其它事情时，干净的暂停和恢复总是一件好事。

在致力于 简化卡顿 对于单核和多核仿真，byte[] 发现如果禁用异步 GPU 仿真和多核 CPU 仿真（我们强烈建议不要这样做，但对于 CPU 线程匮乏的用户或 FX 用户来说这是一个有效的选项），就会发生竞争情况在初始化 CPU 和 GPU 线程时。 几个单线程仍然是多线程。 byte[] 攻破了一些障碍并修复了这个特定的崩溃。

暂停是本周的关键词，而这一次，它可能会导致特定的游戏崩溃。 旧的 StallCPU 行为将等待所有线程执行停止。 它很慢，但很安全。 火焰纹章:风花雪月 使用新方法会进入 GPU 线程竞争状态。 告诉内核等待所有线程在暂停时停止 避免崩溃。

如果由于某种原因 yuzu 会跳转到一个无效的地址，仿真会挂起，并且日志会被无限量的垃圾邮件 Unmapped Reads. 在 Dynarmic 和 yuzu 上修复此所需的工作，导致 停止对未映射地址的 ReadCode 回调。

exlaunch 是一个用于将 C 或 C++ 代码注入 Switch 应用程序和模块的框架。 exlaunch 可以在未打补丁的单元上工作，允许开发人员使用它“进城”。 yuzu 不支持，但是 comex 实现了所需的功能 让它启动并运行。 谢谢！

新人 DCNick3 加入战斗！ 对于他们的第一次争吵，他们 实施了 ExitProcessSVC, 这允许自制应用程序在关闭时优雅地退出。

第三方防病毒软件的问题

用户最近报告了从 Mainline 版本 1075 及更高版本开始的崩溃。 原因似乎是第三方防病毒软件，更具体地说是 ESET/NOD32。 发出 HIPS 误报，将 yuzu 沙盒化并阻止其访问系统页面文件。 基本上，如果 fastmem 无法确保 4GB 的页面文件正常工作（如果启用了扩展内存选项，则为 6GB），模拟器将崩溃。

目前有三个选项可以解决这个问题：

用户可以在yuzu的设置中禁用fastmem，设置在 模拟 > 设置… > 通用 > 调试，从那里，启用标记为的选项 启用CPU模拟器调试，并从 CPU 选项卡中，禁用两个 主机MMU仿真 选项。 这将产生在某些游戏上高达 30% 的性能损失。

向两个 yuzu 文件夹添加 HIPS 例外， %appdata%\yuzu和 %localappdata%\yuzu. 用户报告显示这种方法的结果好坏参半。

还不如直接卸载 ESET 并改用 其它防病毒软件。

可以解决第三方防病毒软件的方案之一

未来的变化

toastUnlimited 一直致力于 使 yuzu 与 LLVM Clang 下 MinGW-w64 。 考虑这种方法的原因有很多：

我们用于 Windows 构建的默认编译器 MSVC 目前在其最新的 2022 版本上不稳定，迫使我们恢复到 2019 版本，并且使 yuzu 在此过程中失去了一些编译器优化，损失了一些性能。

yuzu 使用的默认 Linux 编译器 GCC 12 存在优化错误和一些警告问题，使其目前无法使用。

Clang 允许进行积极的优化，从而提供良好的性能提升。 一个例子是 波莉 。

与 GCC 一起，LLVM 使生成帧对 SSE4.2 指令集优化的代码变得更加容易。 没错，Core 2 Duo 用户，所有没有SSE4.2指令集的用户，您就是下一个被放弃的对象。

我们默认没有切换到这个新系统的主要原因是 Project Gaia，或者，嗯，目前缺乏Gaia。 为了让 Clang 构建并在 Windows 上运行，它的一些更改是强制性的。 虽然这个拉取请求已经完成，但它的完整实施将被搁置，直到 Gaia 出来，现在不远了。

一个水壶，煮一些 wotah ，然后给自己泡杯茶，因为 Project London已经开始血腥了。

这就是所有的！ 谢谢你一直坚持到最后。 下个月见！