Switch模拟器YUZU进度报告2022-5月

大家好， 这个月我们将介绍对柚子的一些小而渐进的改变。 请放心，我们还在程序中进行了一些重大的重写和改进，我们将在接近最后面看到。

终止对EOL Windows 版本的支持，也就是微软不再支持的版本

主要包括windows 10 1803及更早的版本

我们先说一些总是避而不谈的问题：

在处理动态和内核仿真（包括改进 4 线程 CPU 系统的兼容性）时，我们对dynarmic和fasteme从而破坏了对 Windows 10 修订版 1803 及更早版本（包括 Windows 7 和 Windows 8/8.1）的支持。

虽然 fastmem 仅设计用于较新的操作系统，但对旧 Windows 版本的动态中断支持的更改纯属偶然。 话虽如此，这是另一个时代的标志，柚子的 Windows 10 之前的体验将继续变得更加低劣。 由于我们专注于提高准确性、稳定性和性能，因此将时间和资源转移到维护旧的和不支持的操作系统上没有太大意义。 从主线版本 991 起，只有 Windows 10 修订版 1809 及更新版本、Windows 11 和 Linux 将成为官方支持的操作系统。也就是说柚子的最低系统需求为windwos10 1809版本。

由于 EOL 系统上缺乏 GPU 驱动程序支持（这会影响对 Vulkan 的支持）、最大路径长度的不一致（对文件系统模拟改进至关重要）以及内核级别上更糟糕的内存处理，这一决定得到了加强。需要正确模拟 Switch 及其子系统。

不强迫开发人员将时间转移到支持过时的平台（他们不再使用）上，这意味着他们可以专注于改进核心仿真组件。

最后，像Dolphin也已经走上了相同的道路，并且是出于同样的原因。

一个 13 岁的 Windows 已经足够老了，可以离开了。

对于那些仍然不想升级的用户， 选择主线版 990 和更早的版本可以正常工作。

默认设置改为 Vulkan

就像前面说的，我们必须规避 OEM 锁定驱动程序（在英特尔硬件上很常见， 它有自己的官方程序 ）和第三方软件限制（过时的驱动程序是导致渲染中断的常见原因）等问题，使用 Vulkan 作为默认 API 能更好地达到流畅体验。

尝试启动游戏或打开 柚子 的配置时，导致 Vulkan 相关崩溃的两个主要原因是：

• 当 柚子 和驱动程序添加对新 Vulkan 扩展的支持时，HUD 和驱动程序上损坏的 Vulkan 层可能会导致问题。 使驱动程序保持最新是防止此问题发生的唯一方法。
• 过时的 显卡 驱动程序缺乏运行 Vulkan 所需的功能。 这通常是由Windows 更新来提供驱动程序而不是手动安装最新版本的驱动造成的，或者英特尔笔记本电脑供应商提供了从未更新的OEM驱动程序。 所以，请始终手动安装最新的 GPU 驱动程序，不要依赖 Windows 更新。

值得庆幸的是，我们有一个新系统可以解决我们无法控制的问题。 柚子 现在将在启动时执行 Vulkan 检查。

如果检查通过，您可以使用 Vulkan 或 OpenGL 并选择要使用的 API，或者在 Vulkan 的情况下，选择使用哪个设备来运行柚子。

如果此检查失败，下次启动 柚子 时将显示警告。 如果发生这种情况，您将只能使用 OpenGL 作为图形 API。 您仍然可以选择最适合您需求的着色器后端（GLSL、GLSM、SPIR-V）。

对于那些遇到这种情况的人，图形设置窗口底部会显示一个标有“检查工作 Vulkan”的按钮，允许重新测试 Vulkan 支持。

以后OpenGL 作为默认的图形 API 的时代已经不复存在了。 与旧同出，与新同进。

展望未来，Vulkan 将是我们开发人员的首要任务，但他们仍将继续支持 OpenGL。 建议 OpenGL 用户使用 GLSL 着色器后端，因为 GLSL 和 SPIR-V 从​现在开始将获得有限的支持。

图形变化、驱动程序问题和怀旧的任天堂64

在过去的一个月里，继续为 超级马里奥3D全明星. 的 DMAcopy（ 直接内存访问 任天堂 Switch GPU ）

DMACopy是许多游戏用来将纹理数据发送到 GPU 的一种机制，它处理从“间距”（逐行像素）到“平铺”（网格）图像的格式转换。 此过程通过将音高图像数据写入 DMA 引擎可访问的 GPU 内存来工作。 接下来，通过 DMA 引擎驱动程序请求 DMAcopy，将图像数据转换为 GPU 可访问的单独缓冲区。 然后，此缓冲区将用作最终绘制的纹理。

修复后的bytes per pixel, 超级马里奥银河 现在有了适当的镜头光晕。

还改进了 OpenGL 解释面部翻转深度的方式，取代了之前报告fix。超级马里奥3D全明星 和 超级马里奥 64 模拟使用的面部翻转是显卡上不常见的配置。 之前的模拟在 OpenGL 中渲染不好，完全黑屏。

虽然在使用 Vulkan（性能除外）时这不是问题，但现在 超级马里奥 64和 超级马里奥银河 可以在两种API种进行模拟 ，ermi架构的 显卡 用户应该很开心。

柚子 图形仿真的重要部分之一是需要翻译少量 显卡 指令，称为 macros宏指令. 柚子 使用即时 (JIT) 编译器以高效的方式执行这些宏。 在大多数情况下，它提供了大约 10% 的性能提升。

由于仿真不准确，有时宏可能会尝试访问超出其应访问范围的参数。 在某些情况下，这可能会导致模拟器崩溃，而无法找到原因。此外，还添加了转储所有宏来用于游戏的调试目的。

那么，为什么宏这么重要，值得拥有自己的转储机制呢？

原来， 任天堂 64模拟器，包含在 任天堂 Switch 在线(NSO) 订阅服务，多次重新分配相同的宏，每次使用不同的代码。 在这种情况下，柚子 错误地将新代码附加到宏的末尾，而不是替换现有代码。正确清除该代码上载地址分配允许 NSO 任天堂 64 模拟器可运行。 是时候重玩那些经典了！

NSO 任天堂 64 模拟器的未来图形修复将为AMD 和 Intel 用户可以免费运行 Vulkan，但建议 NVIDIA 用户使用 OpenGL。也就是说从柚子模拟器中运行N64模拟器程序时候N卡用户最好使用OpenGL的渲染模式。

Polaris AMD Radeon 用户（RX 400 和 RX 500 系列），驱动程序 22.3.2 和更新版本导致多个游戏崩溃，最明显的是 塞尔达传说:旷野之息 和 集合啦!动物森友会. 驱动补丁说明中提到了VK_KHR_workgroup_memory_explicit_layoutVulkan 扩展。 简单的的结论是 AMD 发布了新驱动程序的坏扩展，这不是第一次，但事实并不是这样。 该问题仅影响 Polaris架构的显卡，并且该扩展也适用于较新的架构，例如 Vega 或 RDNA2（我们不谈论 RDNA1)。

经过几次调试，我们发现 yuzu 的 VK_KHR_workgroup_memory_explicit_layout 实现假设所有兼容的 显卡 都支持 16 位整数运算。 虽然在 AMD 实施扩展之前所有兼容的 显卡 都是这种情况，但 Polaris 架构因其缺乏最近流行的 16 位精度支持而臭名昭著（它已经老了，也可以说，Polaris架构 已经 6 岁了现在），正如预期的那样，强制 GPU 执行它不支持的操作将导致崩溃，太棒了。。。

toastUnlimited禁用了在 Polaris架构的 显卡 上的扩展，等待专门的 显卡 开发人员有时间实施对它的修复。计划在未来允许扩展以老式的 32 位精度工作。

虽然仍然是关于 AMD Windows Vulkan 驱动程序的主题，但我们不得不谈论另一个扩展问题。 自驱动程序版本 22.5.2 起，添加了VK_KHR_push_descriptor，过去 5 年一直在其它所有驱动程序中运行的旧扩展，无论是 Intel、NVIDIA 还是 Mesa。

虽然我们还不知道问题的根本原因，但只有 AMD 的 Windows 驱动程序在调用 VK_KHR_push_descriptor 时会崩溃。 由于此扩展对整个渲染过程至关重要，因此任何 AMD 显卡 都会在任何游戏中崩溃。

似乎这一次，AMD 可能只是发布了一个损坏的扩展程序。 此扩展以前与 yuzu 的 Vulkan一起使用，没有问题。 如果是这样，那么轮到 AMD 来解决这个问题了。 同时，toastUnlimited阻止了该扩展在受影响的 AMD Vulkan 驱动程序版本上。

在 显卡 模拟方面的其它地方，asLody 在禁用两个面时实现了模板修复。这应该会改善一些原生使用 OpenGL 的游戏的渲染。

HLE改进

转到 HLE 仿真的主题， 开发团队一直在努力提高 柚子 内核仿真模拟的准确性和性能。

这一次，游戏和模拟操作系统“锁定资源”的方式发生了很大变化。 这几乎可以提高每款游戏的仿真性能，并且在不同程度上提高了任何 CPU 上的仿真性能。

在软件工程中， 自旋锁 是一种锁，它导致试图获取它的线程只是在循环中等待 （“旋转”）同时反复检查锁是否可用。

存在另一个具有类似功能的mutex 。

单词“mutex”代表提供对象的对象 MUTual EXclusion线程之间。 互斥锁通过使用锁定和解锁等操作确保只有一个线程可以访问关键部分或数据。 临界区是许多线程想要访问的共享资源。 虽然如果多个线程想要读取同一个临界区没有问题，但在前一个线程完成自己的写入之前，没有新线程可以修改该部分。 在这种情况下，第一个线程锁定该部分，并将保持这种状态，直到锁定被释放。

理论上，当一个线程试图锁定一个互斥体并且它没有成功时（例如因为互斥体已经被锁定），它将被暂停。 然后，操作系统将借此机会安排一个可用且就绪的线程在其位置运行。 暂停的线程将继续休眠，直到它能够获取互斥体。 一旦持有互斥锁的当前线程释放它，这可能会发生。

因此，为了获取锁而“旋转”的线程将浪费的（也许是宝贵的）系统资源。 虽然 Switch 自己的操作系统使用自旋锁，但在低端硬件上进行仿真时，这种资源消耗可能会出现问题。 使用主机操作系统（Windows 或 Linux）互斥锁允许 柚子 在其它可用线程上继续模拟任务。

有用的是，大多数现代操作系统都使用混合互斥锁和混合自旋锁。 自旋锁方法可以在有空闲线程的系统上正常工作。 但是，对于仿真模拟，我们需要很多线程（用于 UI、音频、GPU 仿真、日志记录等），因此这种方法不太理想，尤其是在内核/线程数较少的 CPU 上。

因此，通过从自旋锁转向互斥锁，我们能够改进 柚子 在内核数量较少的系统上的运行方式。 我们的测试结果表明，柚子现在在 4 线程系统上的可用性更高，解决了 4 核/4 线程 CPU 上的稳定性问题（最明显的是 宝可梦剑/盾)，并显着提高（以前完全不可行）2 核/4 线程 CPU 的性能。 也就是说现阶段4线程的CPU也可以具备相对较好的性能提升，低端CPU的有福了！

用户界面更改

改进用户界面 ，例如，如果 Windows 系统区域设置为某些语言，则自定义 RTC 设置会出现一些问题，使其显示不正确（例如缺少 AM/PM 指示符）或完全无法使用。修复显示格式以允许自定义 RTC 现在以任何语言正确显示。

网络选项卡 设置 >系统 > 网络 更改语言后可能仍无法翻译。 这是一个忘记在翻译中包含选项卡的简单案例，因此 Docteh修复了 oopsie并且单独的网络选项卡现在显示正常。

一段时间以来，柚子 的 关于 对话框的布局，尤其是在 Linux 上，出现了一些问题。 虽然我们过去曾尝试修复它，但这些尝试会对 Windows 构建产生不利影响，反之亦然。 通过 qtcreator，Docteh修复了 关于 对话框 UI 文件，并删除了由原始 .png 图像引起的旧警告。 感谢 Docteh 花时间一劳永逸地解决这个问题！

控制器更改

German77 再次成为这里无可争议的王者。 他继续不懈地寻求提供最佳的用户输入体验。

German77 注意到即使被禁用，motion 也会继续报告数据，导致 精灵宝可梦伊布/皮卡丘 垃圾邮件 StopSixAxisSensor日志中的错误。 在处理这个问题时，他还注意到一个缺失的参数， delta_time. 它的正确实施可以让柚子拥有 准确的刷新率。

在一个多合一的拉取请求中，german77 进行了 一些输入更改， 包含：

• 为几个 HID 函数
• 改进以前的实现以更接近地匹配本机硬件。
• 实现所需的功能 任天堂 Switch 运动, EnableSixAxisSensorUnalteredPassthrough, IsSixAxisSensorUnalteredPassthroughEnabled, LoadSixAxisSensorCalibrationParameter, GetSixAxisSensorIcInformation, ResetIsSixAxisSensorDeviceNewlyAssigned.

虽然我们在这方面取得了很大进展， 任天堂 Switch 运动 在我们重新处理音频并进行一些急需的 GPU 修复之前，将无法在 yuzu 上运行。 虽然音频和完美渲染对可玩性似乎并不重要，但如果这些不准确，游戏通常会非常不稳定。 请放心，我们正在努力解决这些问题，很快就会分享更多内容！

改变游戏类型， Arcaea被报告为触摸释放模拟存在问题。 结果这个游戏在发布时检查报告的触摸位置，并且一些输入驱动程序在发布后丢失了它们的位置数据。 此外，发现多点触控在触摸屏上无法正常工作。

在对触摸仿真进行了基本 的小型重写之后， German77 解决了这两个问题。

使用几乎无穷无尽的不同控制器时的障碍之一是它们具有不同的实现质量。 由于 柚子 在发送振动信号后要等待控制器响应，因此速度慢的手柄控制器可能会使整个模拟器停顿，从而导致严重的卡顿。 为了解决这个问题，german77 将振动移动到单独线程中的队列中， 让 柚子 与仿真一起移动，让您的控制器尽最大努力。 这只是通过将阻塞操作移动到异步后台线程以提高整体可用性来改进模拟的另一个示例。 事实上，柚子 使用数十个线程进行仿真，这就是为什么消除自旋锁确实有助于让模拟器丝滑运行的原因！

未来项目

尽管 Project Y.F.C.由于一些 NVFlinger 回归而略有停滞，这些问题已得到解决，并将在下一份进度报告中介绍！ 在 闪鹰 的带领下， Project Y.F.C.正在取得很大进展，并有望很快发布。 提醒一句， Project Y.F.C.对我们的 GPU 模拟的各个部分进行了大修，修复了许多不准确之处并提高了性能和兼容性。

（提示：如果你查看之前的进度报告，你会发现它们的拉取请求有一个共同的主题）

toastUnlimited 正在努力为 Windows 构建 MinGW Clang，这可能比我们现在使用的 MSVC 构建更快。 这项工作与发布相关 Project Gaia，所以需要一点时间。

奖励项目

作为额外的奖励，gidoly，我们的一位团队成员最近拿到了 Ryzen 5800X3D，让我们有机会将它与固定在 4.5GHz 的常规 5800X 进行比较，因此只有额外的缓存应该是相关的。

下面是结果！

虽然 5800X 被手动强制设置为 4.5GHz 频率，但 5800X3D 自然地以 4.45GHz 时钟速度达到顶峰，结果是可观的，但没什么了不起的。 宝可梦 晶灿钻石·明亮珍珠 当然喜欢额外的缓存，而 密特罗德：生存恐惧 则因其额外的延迟而性能降低。

这就是这个月的所有！ 一如既往，感谢您的支持，我们希望您喜欢我们最近进展的总结。 下个月见！ 在那之前，继续模拟，让我们知道我们可以做些什么来让柚子成为最好的模拟器体验！