Switch模拟器YUZU进度报告2023-6月

Switch模拟器Yuzu进度报告2023-6月

再次向大家问好，yuz-ers！我们的新老开发人员没有放缓的迹象。本月，我们将进行总体性能和稳定性改进，修复了许多图形错误，Android获得了第一波改进，等等！戴上头盔，让我们出发吧。

在我们深入研究报告之前，我们有一些重要的消息要分享。我们收到报告称，一些用户在尝试使用 Vulkan 或更改设置时遇到崩溃。罪魁祸首是 Overwolf ，一个带有错误和过时的 Vulkan 层的 mod 管理器/覆盖层，弄乱了 GPU 的 Vulkan 驱动程序。我们强烈建议用户卸载 Overwolf，直到他们修复了他们的 Vulkan 层。

现在我们已经清除了这个问题，让我们开始吧。

虽然我们实现了 Switch 操作系统的许多功能，并且可以在没有固件转储的情况下启动大多数游戏，但有些游戏仍然需要一个。这对于Mii模型或正确呈现外部脚本和按钮字体是必需的。固件文件还包括正确时区支持所需的资源。

感谢 ToastUnlimited的出色工作 ，柚子现在附带了Switch默认拥有的几乎所有时区数据！

过去，柚子会假装系统处于格林尼治标准时间，然后通过客人的本地偏移量调整世界时。虽然这通常有效，但它对 Switch 报告时间的方式并不准确。

默认的“自动”时区设置现在将使用合成时区存档向访客发送位置准确的时区（而不是遵循旧的 GMT 规则）。新系统还会发送世界时间的正确表示形式，无论是否存在固件转储。

现在，虽然Linux在新系统上几乎没有问题（除了Flatpak令人沮丧的问题），但Windows有一些特定的要求。有两件重要的事情要记住：

当更改发布时，用户需要至少运行2019版本的Windows 10，而1809不再兼容。对于 LTSC 用户，这意味着只有最新的 2021 版本才能使用。我们后来为此实施了一个解决方案。如果您运行的是 Windows LTSC 1809，或者由于某种原因阻止了常规 Windows 版本的 Windows 更新，请记住更新到最新的 yuzu 版本。

你需要最新的C 2022 可再发行组件。

这个月充满了GPU的变化，所以让我们从一个简单的开始。

恶人永远不会休息，所以 Blinkhawk 充分利用了额外的时间做他最擅长的事情：凭空做出重大改变。在这种情况下，他研究了如果内存页同时由 GPU 使用并由 CPU 写入会发生什么。可爱的小虫子已经困扰了我们五年，这就是发生的事情！

Blinkhawk 在这里添加的是一种机制，用于注册在 GPU 访问页面时潜入的小型 CPU 写入，并在需要时正确使页面无效。因此，以下错误现已得到修复：

修复了影响 Pokemon Scarlet & Violet 宝可梦朱、紫的闪退。使用高 GPU 精度。

修复了 The Legend of Zelda: Breath of the Wild & The Legend of Zelda: Tears of the Kingdom 塞尔达旷野之息和王国之泪中的慢雨和雪粒子。

修复了一些特定于 Tears of the Kingdom王国之泪中的粒子损坏，例如，在传送时。

修复了 SUPER MARIO ODYSSEY 超级马里奥奥德赛中某些粒子的不稳定运动。

修复了影响 Xenoblade Chronicles 3 异度之刃3中某些角色的滑稽错误的眉毛，如诺亚和塞纳。作者注：我会想念这个，它很棒。

修复了 Xenoblade Chronicles: Definitive Edition 异度之刃终极版中损坏的保存缩略图。

对于低 RAM 的人来说，这里有一些好消息！

由于原生 Switch 游戏着色器不能直接在用户的 GPU 上运行，因此 yuzu 必须将它们重新编译为中间表示 （IR），这是一种可以优化的中间格式，然后转换为用户的 GPU 驱动程序可以实际处理的着色器（SPIR-V/GLSL/GLASM）。出于性能原因，预分配了大量内存来存储这些 IR 块，旧实现将为每个线程使用 34MB 两次。

每个线程 68MB 可能看起来不多，对吧？但是，此分配的次数与 CPU 的总线程数（包括 SMT）一样多。通过一些快速的maff，您可以看到Ryzen 3600将吞噬816 MB的系统RAM，Ryzen 7950X或i9 13900将需要2.2GB，许多具有8线程SoC的手机将损失544MB的这些分配。当然，对于拥有32GB系统内存的用户来说，这不是什么大问题，但对于16GB或更低的用户，尤其是8GB RAM用户来说，这是一个非常高昂的代价。例如，只有8GB RAM和配备12线程的Ryzen 5500U或8GB手机和平板电脑的笔记本电脑并不少见。

byte[] 对这种行为不满意，所以他用一个对内存更友好的行为替换了它。现在每个线程的当前使用量约为 134KB。这是惊人的99.6%的减少！

使游戏看起来更好的方法之一是强制使用更高值的各向异性过滤，从而使陡峭角度的纹理看起来更清晰。旧的实现必须跳过 mipmap 图像上的最近邻采样器，以避免在 Fire Emblem: Three Houses 和 ASTRAL CHAIN 等游戏中出现渲染问题。这个决定意味着许多像 Metroid Prime Remastered 这样的游戏不会看到使用更高值的各向异性过滤的好处，以至于Wollnashorn会创建模组来强制 Breath of the Wild 和 Tears of the Kingdom 的纹理进行三线性过滤，从而允许柚子的各向异性过滤设置完成其工作。

虽然这是一个很好的解决方法，但 Wollnashorn 对这个解决方案并不满意，因此他们改进了用于允许对任何纹理格式进行各向异性过滤而不会出现渲染问题的启发式方法，提高了图像质量，并且作为奖励，甚至修复了影响 Mario Kart 8 Deluxe 的旧渲染错误！

现在，您可以安全地选择 16x 过滤并享受结果，您可以在 Emulation > Configure… > Graphics > Advanced > Anisotropic Filtering 中找到：

在Blinkhawk修复的另一批旧问题中，他设法查明了虚幻引擎4游戏在使用Vulkan运行时纹理损坏和崩溃的原因，这个问题主要影响NVIDIA卡。

虚幻引擎4是稀疏纹理的忠实粉丝，以至于真正突破了纹理缓存代码的极限。在稀疏内存转换为常规映射内存后，影响NVN虚拟映像如何重新映射的错误导致 SHIN MEGAMI TENSEI V ， Bravely Default ， Pikmin 4 Demo 等游戏随机显示损坏的纹理。

光学伪装出了问题，显然这里的普罗塔君不如元子少校（真女神转生V）

说到 Pikmin 4 Demo 皮克敏4试玩版，游戏告诉我们，虽然你可以做到，但3D纹理真的不需要通过DMA操作来加速。为了避免在虚幻引擎4游戏中出现这样的崩溃，将改用LLE慢速代码路径。

此拉取请求引入了影响 Metroid Prime Remastered 中渲染的回归。值得庆幸的是，Gidoly通过合并新旧两种方法迅速解决了这个问题。

在处理这些崩溃时，byte[] 将 Vulkan 内存管理器的行为更改为首选（而不是要求）使用设备本地内存 （VRAM） 作为图像内存，最终允许 GPU 使用多达 50% 的共享内存（系统 RAM）。这个简单的技巧使大多数虚幻引擎4游戏变得稳定，但一旦VRAM接近满，例如，在具有4GB VRAM或更少VRAM的GPU上运行 The Legend of Zelda: Tears of the Kingdom 塞尔达：王国之泪时，它很可能会使VRAM密集型游戏更频繁地卡顿。

考虑到 Tears of the Kingdom 是迄今为止柚子上玩得最多的游戏，这是一个高昂的代价，但我们认为受益于稳定游戏玩法的大量游戏超过了最新的塞尔达在带有专用 VRAM 的低端 GPU 上口吃更多。

有什么比继续写 The Legend of Zelda: Tears of the Kingdom 更好的方法来证明这个陈述！自发布以来，模组社区一直在不知疲倦地努力提高游戏的渲染质量。在测试过程中，他们发现任何高于 1008p 的渲染分辨率模组在分辨率超过 1 倍时都会破坏环境光遮蔽效果。

byte[]，在Wollnashorn初步调查的帮助下，调整了重新缩放大小阈值，现在游戏可以使用模组安全地升级，以达到光荣的真实1080p渲染 - 然后可以使用Yuzu的内部分辨率缩放器缩放到任何所需的分辨率。

现在，您可以享受游戏的所有辉煌，而不会牺牲任何细节。

在分析 GPU 代码时，Maide 找到了一种从游戏中榨取更多性能的方法。通过组合顶点和转换反馈缓冲区绑定而不是单独绑定它们，可以避免每帧数千次 API 调用。这通常会导致帧速率略微提高 1-3%，但它设法将 Tears of the Kingdom 提高了 17%。这些测试是使用 Ryzen 5 5600X 进行的，因此较新的 CPU 很可能会看到更大的收益。

通过在查找正确的渲染目标时添加一些额外的示例检查，vonchenplus 修复了在手持模式下玩游戏时影响 Fire Emblem Engage 的设备丢失崩溃，以及影响某些系统的压扁角色肖像。此更改还修复了 SpongeBob SquarePants: The Cosmic Shake 中不正确的颜色和阴影。

vonchenplus 还修复了影响 Titan Quest 和 Crysis Remastered 的分辨率缩放问题;故障的画中画错误消失了！

由于Epicboy的努力，OpenGL也再次得到了一些优化。

在一个令人惊讶的发现中（或者如拉取请求描述中所述，“这是一个有趣的发现”），Epicboy 发现，如果之前执行的着色器使用大量本地内存，NVIDIA 的 OpenGL 驱动程序在使用本地内存的着色器中会显着提高性能。这似乎是NVIDIA驱动程序中OpenGL特有的怪癖，因为Vulkan不受影响。

这个漂亮的驱动程序技巧使性能提高了 2-10%，具体取决于 GPU 的大小。

但OpenGL的收益并不止于此。 Persistent Buffer Maps 已经被纹理缓存使用，但将它们的使用扩展到缓冲区缓存会使 OpenGL 在 NVIDIA 硬件上的性能提高一倍以上！

我们期望在Linux上使用Mesa驱动程序时会有类似的改进。

虽然建议大多数 NVIDIA 用户现在坚持使用 Vulkan，因为它仍然更快，着色器卡顿更少，但这些更改应该极大地帮助费米和开普勒（GTX 400 到 GTX 700 系列）用户，由于驱动程序支持的原因，他们仍然必须使用 OpenGL。或者那些只是喜欢危险生活的人。

随着分辨率缩放器的引入，我们添加了 FXAA 作为可能的抗锯齿过滤器，对于看起来已经过于清晰的游戏，或者只是对于无法承受 SMAA 性能损失的用户，这是 SMAA 的首选选项。自发布以来，它的 Vulkan 实现一直存在色带问题。对此不满意，byte[] 通过使用更高的颜色位深度解决了这个问题。 有时，解决方案不需要很复杂。

许多 Switch 游戏支持动态帧率，或者获得支持动态帧率的模组，这意味着解锁帧率（默认情况下按 Ctrl U）是在模拟这些游戏时获得更好、更流畅体验的好方法。顺便说一下，这里有一个这样的游戏列表，适合那些好奇的人。

这样做的一个不必要的副作用是视频播放将无法跟上增加的帧速率，通常会使音频不同步，同时仍然必须等待视频结束。为了缓解这种情况，byte[] 在 Emulation > Configure… > Graphics > Advanced 中添加了一个名为“同步到视频播放帧速率”的切换开关，启用后，将在播放视频过场动画时动态重新启用帧速率限制。

在深入研究AccelerateDMA代码时，Epicboy发现了一个影响缓冲区到纹理副本的错误检查。修复它可将性能提高多达 1%，但正如任何狂热的游戏玩家所知，平均帧率只是故事的一半。这一变化还提高了帧时间的一致性，尤其是在突然的峰值中，这可以说是游戏过程中最明显的。

用户喜欢在各种设备上测试柚子;一个特别有趣的例子是NVIDIA的Tegra X1产品线，与实际的Nintendo Switch相同的架构。由于有可用于这些设备的驱动程序，因此yuzu可以在Linux环境中运行，但由于某种原因，这些驱动程序不包括 VK_EXT_robustness2 扩展名，而{扩展名到目前为止是强制性的。新人mrcmunir决定改变这一点，并将扩展标记为可选，使用于Switch仿真的最佳ARM板能够享受柚子的游戏玩法。

为了关闭图形部分，我们把最好的留到最后：toastUnlimited删除了使用仅限Windows的外部存储器Vulkan扩展。为什么？使柚子在使用Vulkan的同时与Wine兼容！为什么有人会在 Wine 上运行 yuzu 当原生和更快的 Linux 版本可用时？不知道！但是你现在绝对可以做到，因为你自己从源代码构建 Wine，并支持 Vulkan 子窗口。我们只打算使用它来调试 MinGW 版本——对于最终用户，我们不会为在 Wine 中运行版本提供任何支持。

这是一个有趣的案例，所有开发人员都要求您的作者跳过提及此更改，因为它对于此报告来说是多余的。我对他们说：YOLO。

支持的新平台有很多改进值得夸耀，但最重要的是我们有幸开始该部分。

感谢byte[]和GPUCode的共同努力，以及允许我们使用Skyline的BCn纹理解码器的章程的帮助，yuzu现在可以正确地宣传对Mali GPU的支持！

这意味着联发科、旧三星 Exynos 和谷歌Tensor CPU（以及其他）的用户只要拥有 G 系列 Mali GPU ，例如 Pixel 7 系列上的 Mali-G710。

从理论上讲，这增加了yuzu Android版本的兼容性，因为Mali是Android生态系统中最常见的GPU系列。

对 Mali 的进一步测试表明，虽然驱动程序在较旧的 Mali 驱动程序中实现了对 VK_EXT_extended_dynamic_state2 扩展的支持，但 VK_EXT_extended_dynamic_state 的实现功能不完全正常，并且 yuzu 在这种情况下行为不正确。这很可能是谷歌从Pixel驱动程序中删除这两个扩展的原因。为了避免受影响驱动程序的用户完全没有渲染输出，byte[] 禁用了在 Mali 硬件上使用该扩展。

应该注意的是，虽然Mali驱动程序比其他驱动程序更擅长遵循Vulkan规范，但缺乏物理硬件规格。目前只有高端设备才能达到可播放的帧速率。低端 Mali 产品对于 Switch 仿真来说太弱了，即使它们满足运行仿真器的驱动程序要求也是如此。但是，嘿，欢迎您尝试一下，看看效果如何！

Android用户界面也做了很多工作。

首先，PabloG02 再次帮了我们一把，这次是将叠加控件的位置存储为百分比，因此，如果窗口尺寸发生变化，例如通过使用可折叠设备或在平板电脑上旋转屏幕，叠加控件将保持在大致相同的位置。

为了帮助用户将所需的文件传输到柚子并进行调试，PabloG02 还添加了导入固件文件的 UI 选项、运行和正确显示某些游戏的要求以及快速共享最后一个日志文件的选项，这可以帮助我们的支持成员尝试诊断崩溃的原因。谢谢！

用户对覆盖控件的配置可能非常讲究。有些可能只使用Switch的触摸屏就可以了（取决于游戏），有些对按钮的不透明度级别有不同的偏好。对于此类情况，t895 添加了一个对话框来调整叠加控件的比例和不透明度。

柚子包含一个通知，以确保在切换应用程序时不会关闭应用程序。我们需要这样做以确保用户不会丢失他们的进度，但它也可以用来包含一些很酷的功能。

一种可能性是在最小化应用程序时支持画中画.t895做了初步工作以允许更改纵横比，而新来的AbandonedCart做了实际的魔术。

后来，在画中画叠加中添加了一个静音/取消静音按钮。

Android不仅在手机和平板电脑上运行。你也可以找到疯狂到在电视上玩柚子的人！对于那些疯狂的人，新来的qurious-pixel增加了对Android TV横幅的支持。谢谢！

自发布以来，用户报告说游戏看起来奇怪地模糊，并且在翻转设备时渲染窗口的纵横比和覆盖控件的方向存在问题。

这有点尴尬：所有这些问题都是由 Vulkan 表面与前端层的旋转解耦引起的。这就解释了为什么在旋转设备时纵横比失真，叠加层反转，但模糊问题的解释值得特别提及。游戏使用横向外形规格和 1920x1080 分辨率以停靠模式呈现在屏幕上，但手机通常具有纵向模式外形规格。如果窗口开始以 1920x1080 渲染，然后被设备修改为 1080x1920 并拉伸以适应屏幕，会发生什么情况？嗯，这个：

通过保持旋转同步，无论是用户有意还是无意，所有提到的问题都得到了解决。哎呀！

为了继续努力实现与桌面版本的功能对等，German77 增加了对将更新和 DLC 安装到 NAND 的支持，就像在 PC 上一样。

通过添加支持以允许此选项一次安装多个文件，再次提供帮助。不断重复该过程来安装每个 thicc Atelier Ryza: Ever Darkness & the Secret Hideout DLC 并不好玩，但这非常值得。

Big Boss bunnei 对默认图形设置进行了一些更改，以改善开箱即用的体验，并添加了解决渲染问题和/或提高性能所需的选项。

从桌面版本加入 Android 上的柚子是 Reactive Flushing ，这个选项会以渲染精度的名义显著降低性能。为了提供最佳性能，默认情况下禁用该选项，但如果您想在 Bayonetta 游戏中获得准确的阴影或正确保存缩略图，请记住启用它。

Force maximum clocks 现在默认处于禁用状态，因为当主要瓶颈在仿真过程的 CPU 端时，它不是很相关。实现本机代码执行后，我们将重新访问此切换。

Nintendo Switch的一个经常被遗忘的功能是触摸支持。在手持模式下，某些游戏允许您在没有控件的情况下玩游戏，只需使用屏幕即可。自 Android 版本发布以来就存在支持，但它并不准确——触摸事件将发生在用户触摸手指的一侧。German77 修复了这种敏感的行为，使播放没有叠加按钮的视觉小说成为一种乐趣。

Android 13 的一个很好的补充是设置每个应用程序的语言的选项，因此正确声明可用的语言翻译允许用户利用此功能。谢谢弗托比！

稍微扩展了“调试”部分，t895 添加了禁用 CPU Fastmem 的选项。这将降低性能，但对于调试目的很有用。

此外，还添加了选择音频后端的选项。

由于它仅在高通设备上受支持，因此如果用户运行的是非高通设备，t895 现在会隐藏 Install GPU driver 选项。由于我们不提供在这些设备上运行不同驱动程序的选项，因此没有理由显示它。当然，如果Mesa将来可以为Mali硬件提供良好的驱动程序，那么我们将支持它的自定义驱动程序。

为了警告使用可能无法稳定仿真的设备的用户，AbandonedCart 添加了警告，如果它没有至少 8GB 的 RAM。即将推出的 14 之前的 Android 版本不会让应用程序知道设备的确切 RAM 数量，因此使用可用的可用 RAM。

说到这里，t895增加了对Android 14的支持。 最好提前做好准备！你永远不知道谷歌什么时候会给我们带来惊喜。

在结束本节之前，让我们澄清一些事情。Android 版本不仅限于此处提到的更改，还包括本文中提到的任何其他核心改进。例如，前面讨论的GPU更改，以及将要讨论的内存和ARM优化也包含在Android版本中。例如，这些更改使最新版本的性能提高了 30-70%，但没有一个是特定于 Android 的。

我们还在 GitHub 上完成了我们的版本备份！你可以在github上找到它们。 如果您想下载以前的版本、测试实验性功能或避免使用 Google Play 商店，请随时从那里获取 APK。

早在 3 月，我们解释了为什么 Windows 在需要非常高精度的计时器时不够准确，因此为了提高 CPU 的性能、功耗和温度x86_64需要特定的 CPU 指令来减少 CPU 不正确地空闲的时间。我们这里有一个很大的错误需要纠正。我们说只有英特尔提供了从Alder Lake开始的此类说明，而AMD没有提供任何说明。

幸运的是，我们错了！AMD 确实有自己的实现，即 monitorx 和 mwaitx 指令对，自 2015 年以来一直存在，早于 Ryzen！

通过执行他惯用的黑魔法，Morph实现了对这些指令的支持，提供了以前只有英特尔用户才能享受到的相同好处，即功耗受限的产品（笔记本电脑、手持设备）或内核数量较少的CPU的性能和电池寿命改进。

由于运行 Windows 的 AMD CPU 现在可以在等待时正确空闲更长时间，因此功耗和/或性能数字会得到改善，具体取决于首先达到哪个限制：CPU 的功率预算或帧速率上限。可悲的是，您的作者（负责测试此更改）无法使用华硕 Rog Ally 手持设备，甚至无法使用 Ryzen 笔记本电脑来进行适当的基准测试，因此请接受使用台式机 Ryzen 5 5600X 收集的数字。使用适当的移动平台，结果应该会更好，但是唉，我们只能显示我们测试的内容。

功耗降低了 10-16%，这意味着这种特定的 CPU 型号降低了约 10W。在模拟功率受限场景（将PPT限制为40W）时，性能提高了60%，但平均而言，通常预期增益为20%。

现在，我们可以猜测你们中的一些人可能会在想什么，“这对 Steam 掌机有多大帮助？这是一个只有四个内核的功率受限系统！在掌机上没有区别。让我们解释一下。

默认情况下，Steam Deck运行Linux发行版。Linux并没有从这些变化中受益，因为它的内核与Windows不同，实际上是不错的，可以运行高精度计时器事件，没有任何问题或未记录的SDK使用。如果根本不需要旋转 CPU，它会正常空闲。因此，除非您将Windows安装到Steam Deck上，否则您已经拥有了它可以提供的最佳性能。

Android版本教会了我们一些非常重要的事情：使用Dynarmic会增加ARM CPU的大量开销。虽然这不会对苹果硅M1和M2 Mac构成任何重大障碍，但对于Android设备来说，这是一个大问题，这些设备一直受到功率限制，几乎没有浪费的空间。

为了减少这里的开销，我们计划实现Skyline， native code execution 或NCE的功能，让游戏的代码直接在处理器上运行，而无需翻译。这将适用于大多数 64 位游戏，但 32 位 Switch 游戏有一些特殊要求，使情况复杂化。

NCE是一个需要一些时间的项目，但就目前而言，byte[]已经实现了一种将Dynarmic与ARM接口分离的方法，从而允许将来使用单独的CPU后端。让我们看看未来会带来什么。

我们仍然称它为尼斯项目，对吧？

关于 32 位游戏，值得一提的是，在幕后，Merry 不断致力于优化和修复 Dynarmic 中的错误。最近，Merry能够为ARM64主机硬件启用优化。块链接允许直接跳转到彼此的来宾代码块在重新编译时直接跳转到彼此。启用它后，这导致 Android SoC 上的 Mario Kart 8 Deluxe 等 32 位游戏的性能提高了 60-70%。这再次提醒我们，仿真非常注重 CPU。

长时间的游戏会话有时感觉像是一场关于稳定性的赌博。对于模拟器来说，这是一个非常普遍的问题，因为它们必须以独特的方式处理内存以匹配两个完全不同的系统。对于 Linux 用户来说尤其如此，他们不得不依靠增加某些游戏的 vm.max_map_count 内核参数的大小来避免内存不足崩溃。由于模拟器需要创建占位符内存映射以跟上游戏的虚拟内存要求，因此不难使默认值饱和，一旦占位符映射数量超过最大映射计数，就会崩溃。

新人kkoniuszy有一个简单但非常有效的想法。通过跟踪此类占位符映射的创建，并使用该信息创建较少的较大映射而不是几个较小的占位符映射，可以减少 vm.max_map_count 上的压力，并且通常不再需要修改。这导致在玩几个小时时游戏会话稳定。谢谢！

使Amiibos及其近场通信（NFC）的行为与真实Switch硬件相同的工作仍在继续。随着上个月的正确实施完成，German77专注于清单上的最后一项。

首先，备份支持。在交换机上，每次加载或保存数据时，Amiibo 数据都会存储在控制台中。这旨在帮助游戏在出现错误时恢复损坏的 Amiibo 标签。 通过这种实现，yuzu现在可以对Joy-Cons和Pro控制器做同样的事情。备份将存储在 %appdata%\yuzu\amiibo\backup 中。

我们的输入开发人员添加了对 Foomiibos 的支持，空白但可配置的 Amiibo 转储，末尾包含签名，方法是将它们的大小添加为有效输入。

动视为 Skylanders 游戏传奇发布了配备NFC的玩具（又名非Amiibos），并且它们与Nintendo Switch兼容，因此当然，它们也必须在柚子上工作！ 执行应该是透明的;只需连接并映射控制器，即可扫描玩具。

为了完成NFC部分，错误修复和对第三方控制器的支持在一个拉取请求中统治它们。

配对时，控制器有时无法正确恢复到以前的状态。当控制器无法使用 NFC 传感器时，这可能会使柚子失去输入。如果游戏在射程内停止轮询Amiibos，Amiibo将丢失，但不会发出信号。此拉取请求解决了此特定方案。

许多第三方控制器不接受所有命令。减少获取有效数据的尝试次数并在发生错误时禁用大多数命令，将最大限度地减少设置 NFC 接口时由配置过程引起的卡顿。

最后，如果控制器正确报告了对 NFC 的支持，但用户从二进制转储加载了 amiibo，我们将错误地显示错误。此问题现已修复。

现在，定期输入更改呢？好吧，我们也有一些话要谈。

SDL，这里用来处理输入的外部库（它可以做的远不止于此），确实会获得更新，当然，在验证它们是否稳定之后，不时跟上这些更新并没有什么坏处。 更新到版本 2.28.0 改进了官方 Switch 控制器上使用的校准配置文件，增加了对索尼新 DualSense Edge 控制器的支持，修复了 Pro 控制器的一些问题，并添加了其他有利于模拟器的小更改和修复。

鼠标控制得到了更多的调谐喜爱。这次对其校准进行了一些小的调整。返回中心将考虑分配的死区，运动输入具有更好的灵敏度。

对于那些不知道的人，如果您将输入设置为键盘/鼠标，或手动将摇杆映射到鼠标，您可以使用鼠标来控制移动。 Ctrl F9 是在播放时获取和释放鼠标控制的默认热键。

最后，对于健身爱好者来说，Ring-Con有一些改进。

German77 改进了振铃检测，增加了超时，让扫描过程在固定时间后重试。

新人 kiri11 改进了帮助文本的措辞，以正确启用 Ring-Con，使其不那么混乱。谢谢！

是的，在我们等待 Project Gaia 时，byte[] 在修复当前文件系统实现方面取得了更多进展。

之前报道的加载模组时的“算法复杂性问题”在 Linux 上就像一个魅力，但 Windows 总是很困难。添加了内存缓存以完全实现Microsoft操作系统的加载时间优势。

在另一个单行代码启示中，byte[] 发现在复制文件时增加缓冲区的大小可以将更新和 DLC 的安装速度提高三倍以上。 为这样的简单修复欢呼！

修改者和用户必须处理的一个常见问题是对每个会话可以加载的文件数量的硬性限制。像 Fire Emblem Engage 这样的游戏有太多的文件，以前甚至不可能用 Mod 替换所有文件。当然，byte[] 对此并不满意，因此通过添加文件 LRU 缓存来控制打开的文件数量，他取消了文件限制。 用户现在可以在他们的游戏中运行任意数量的模组，他们也可以拥有任意数量的文件！

但乐趣并不止于此 byte[]。再一次，Windows需要特别注意... 一些优化和Windows用户现在也可以适当地受益。

负责缓存 RomFS 模组的代码中的疏忽根本阻止了任何缓存生效，这使得 yuzu 在启用它们的情况下加载游戏时通常需要两倍的时间。通过修复此疏忽，byte[] 进一步减少了模组的游戏加载时间。

运行 SDL 音频后端的 Linux 用户报告在使用 JACK 输出时没有音频输出。正如新人 zeltermann 在经过一些调查后发现的那样，问题在于 SDL 如何识别用户硬件的 CPU 特性。

调用 SDL 的 CPUInfo 子系统来报告用户 CPU 的规格。然后，SDL 使用该信息针对将要运行的环境正确配置自身，设置优化并决定使用哪些内部代码路径。我们认为CPUInfo不应该只是音频输出所必需的，所以它在yuzu中被禁用了。

好吧，在正常情况下，这本来没问题，但 SDL 无法确定没有 CPU 信息是否意味着存在或不存在 CPU。 SIMD 支持报告为禁用，但 SSE2 假定为已启用。这种矛盾会导致在禁用 SIMD 支持失败的情况下运行回退，使某些函数返回 null，从而完全破坏音频输出。

通过向 SDL 提供它想要的东西：CPUInfo 的适当报告，可以解决事件的这种连锁反应。 现在，Linux 用户可以在使用 SDL 输出时享受带有音频的游戏。谢谢！

越界，这么多节目的无声*手......柚子当然不能幸免，正如Morph所发现的那样。越界写入会导致音频堆缓冲区损坏，从而导致多个游戏中出现蜂鸣声、扬声器嘎嘎声和崩溃，包括但不限于 Xenoblade Chronicles: Definitive Edition 、 Xenoblade Chronicles 2 、 Super Smash Bros. Ultimate 等。

在音频核心代码中到处进行一些调整，问题就消失了。

开关游戏为启动器提供了漂亮的游戏图标。不用说，柚子在渲染游戏列表时充分利用了它们。在用户界面使用这些图标时没有考虑的是，某些游戏为不同的语言提供了多种选择。柚子只会选择第一个可用的。

输入新人 keve1227，他根据用户在 Emulation > Configure… > System > Language 中选择的控制台语言，按照正确选择正确图像所需的逻辑进行编码。谢谢！

OpenGL API 在 yuzu 中有三个可用的着色器后端，由于知道选择了哪一个的唯一方法是通过检查 Emulation > Configure… > Graphics 中的选项，新手 fastcall 决定是时候将此信息添加到状态栏中了。谢谢！

在开始驱动程序咆哮之前，我们想分享一种可能的方法，通过利用 Windows 11 的每应用图形选择器来节省高达 2 GB 的 VRAM，假设您的系统中有多个 GPU 可用。这有可能帮助像 The Legend of Zelda: Tears of the Kingdom 这样的VRAM密集型游戏，并且还可以改善本机PC游戏的1%低点。

出于某种原因，Windows仅使用大约1-2 GB的VRAM来渲染桌面。对于配备 8 GB 或更小的 GPU 来说，这是一个沉重的打击，甚至没有考虑在后台运行的其他程序。

必要条件是运行最新 Windows 11 的台式 PC、具有两个全长 PCI-Express 插槽的主板或带有集成 GPU 的 CPU，并且所有 GPU 都足够新，仍然可以获得驱动程序更新（GT 710 不适用于 RTX 4070，因为它们运行不同的驱动程序版本，并且英特尔 HD 620 不会收到新的驱动程序更新）。在此示例中，我们将使用 RTX 3060 Ti 和 RX 6600，您可能从之前的文章和图表中熟悉的组合。像GTX 750这样的低端GPU或英特尔第11代（及更新）或Ryzen CPU的集成GPU也可以很好地用于此目的。

应该注意的是，大多数笔记本电脑用户已经在没有用户干预的情况下执行此操作，因为大多数笔记本电脑不包括硬件多路复用开关，只是通过 PCIe 总线传递完成的帧。

这里的主要技巧是将显示器连接到辅助卡，以便让 Windows、您的浏览器、Discord 等专门在辅助卡上花费 VRAM，让柚子和其他程序/游戏完全访问主 GPU 的整个 VRAM。为此，我们将利用 Windows 11 的一些相对较新的新增功能。

设置 GPU（台式电脑可能需要在 UEFI 配置/BIOS 上启用集成 GPU）后的第一步是在显示设置中选择高性能卡：

虽然这对于重启后的柚子来说已经足够了，但您还需要手动设置每个需要使用高性能 GPU 的游戏或程序：

像这样，您可以在高性能 GPU 上获得更多免费 VRAM 的好处，如果辅助 GPU 效率更高，则在使用 PC 时总体上会降低功耗。更多的可用VRAM可提高最小帧速率（例如，低1%）。

使用此方法的缺点是帧数据通过 PCIe 接口传输，该接口可能已饱和。这可能会导致平均帧速率略低和输入延迟更多。但是，嘿，一种让 4GB GPU 以更好的帧节奏运行 The Legend of Zelda: Tears of the Kingdom 的免费方法值得一试，对吧？

新的（在撰写本文时）536.40驱动程序版本增加了对RTX 4060的支持，但没有为yuzu引入任何回归。因此，更新是安全的，只是从旧硬件“升级”还不是安全的。也许RTX 5000系列将是一个更可行的选择。

从刚刚发布的一份有趣的报告中，似乎在将 Xenoblade Chronicles 3 与“使用异步着色器构建”结合使用时，使用 NVIDIA 控制面板的“首选最大性能”选项会导致顶点爆炸，在过场动画中最为明显。柚子自己的“强制最大时钟”切换虽然效率较低，但并没有重现这种有趣的行为。如果您正在使用NVIDIA GPU探索Aionios，请记住一些事情。

自驱动程序版本 23.7.1（神秘的旧版“23.10.01.41 用于其他 Vulkan 扩展”）版本以及仅适用于 Windows Insider 测试人员的测试版驱动程序以来，AMD 官方 Vulkan 驱动程序引入了 VK_EXT_extended_dynamic_state3 扩展如何处理颜色混合的回归。 您的编写器阻止了受影响的位，同时我们监控未来的AMD驱动程序版本是否设法解决此问题。

此更改造成的性能损失非常小，因此请随时更新到最新的驱动程序。

GPU Code 找到了一种通过使用 VK_EXT_depth_bias_control 扩展来模拟 AMD GPU 上的 D24 支持的方法，该扩展目前仅在 Linux 上的 RADV Mesa 驱动程序上可用。在不久的将来，我们将检查此方法是否解决了特定于AMD硬件的其余图形问题。如果它有效，它也可以解决AMD官方驱动程序上的问题，一次/如果扩展也在那里得到支持。

我们知道必须切换到OpenGL才能玩一些游戏并不好玩，因此我们正准备克服硬件限制以击败这个敌人。

英特尔本月也有相当多的修复。首先，正如上个月所承诺的，byte[] 在着色器中使用时添加了 FP64 到 FP32 的转换。这是必需的，因为第 12 代英特尔显卡（UHD 700/Iris Xe/Arc A 系列）取消了硬件级别的双精度操作支持。有了这种着色器转换，游戏在尝试使用这些着色器时将不再突然崩溃，例如在开始新游戏后的 Tears of the Kingdom 的开场过场动画中。

下一个问题是Switch自己的图形驱动程序的独特行为，yuzu的代码错误以及缺乏硬件支持的另一个案例的有趣组合。英特尔的 GPU 允许使用 SPIR-V 指定的控制屏障，这要求调度中的所有线程同时执行相同的屏障，并且不允许任何线程在出现另一个屏障时提前退出。但除了英特尔之外的所有其他GPU供应商，包括移动GPU，都允许线程提前退出，并将根据需要释放剩余线程上的障碍。这种情况导致英特尔 GPU 遭受设备损失，因为来宾计算着色器具有障碍，最终会碰到这种确切类型的控制流。

通过在条件控制流之后消除障碍，英特尔 GPU 不会发生设备丢失崩溃。

最后，还有一个松散的结局，即我们禁用英特尔 GPU 上的计算管道的切换。在发布驱动程序更新之前，此选项是权宜之计。但是，由于英特尔终于发布了解决这些问题的驱动程序更新，因此现在它变得无关紧要。因此，toastUnlimited修改了该选项，使其仅在已知受影响的旧驱动程序仍在使用时才显示在yuzu的设置中。禁用计算管道切换现在是一个传奇的丢弃选项，仅适用于最不幸的第 12 代用户，因为该选项对于未受影响的第 11 代及更早的设备也将保持隐藏状态。 记得更新您的驱动程序！

修复了所有驱动程序和柚子稳定性相关问题后，我们终于可以再次推荐英特尔硬件，尤其是像 Iris Xe 这样的当前一代集成 GPU。虽然配备 80EU 的低端 Iris Xe 可以在最密集的游戏中以对接 1X 模式解决性能瓶颈，但由于它是最后一批支持原生 ASTC 纹理的英特尔 GPU，因此它通过零纹理相关的卡顿来弥补这一点。我们不知道未来的iGPU是否会继续支持ASTCs，但Arc专用GPU不提供它是一个现实。

尽管如此，我们最终可以专注于解决第 12 代架构剩下的几个怪癖。目前，Iris Xe可以在像 The Legend of Zelda: Tears of the Kingdom 这样的ASTC密集型游戏中轻松击败Geforce MX450，使用更少的RAM并且没有纹理卡顿。在这里，E 核心是着色器构建的福音。

希望未来的英特尔产品提供更好的FP16，更高的性能，更长的驱动程序寿命支持，不要像竞争对手那样将定价建立在软件噱头上，并添加急需的专用计算队列。

随着Android版本的发布，整个团队正在了解该平台的生态系统，其功能和局限性，怪癖和优势。前方肯定有有趣的时光。这意味着我们还了解了其 GPU 驱动程序的令人沮丧的状态......

Adreno 硬件具有出色的规格，但其专有的官方驱动程序非常糟糕！我们开始致力于改进在配备高通的设备上默认使用的官方Adreno驱动程序的渲染，但我们能做的只有这么多。你猜对了，真正的解决方案来自设法制造出无法访问机密信息的优秀司机的团队：Mesa。

人们不得不怀疑为什么Android供应商一开始就不只是使用Mesa。在这里，没有什么比提供良好的软件支持更重要的“机密”或“商业秘密”了！

虽然 Adreno 600 系列得到了很好的支持，并且与 Mesa 驱动程序具有出色的渲染效果，但 700 系列太新，无法享受同样的好处。K11MCH1使用目前正在开发的Mesa Turnip的a700分支已经发布了一些打包版本，但这正是锡上所说的：目前正在开发中。我们无法修复正在进行的驱动程序上的回归;唯一要做的就是等待它成熟。

马里与阿德雷诺完全相反。虽然目前没有Mesa支持它，但我们发现他们专有的Vulkan驱动程序在最初的怪癖得到解决后处于良好状态。他们的OpenGL ES驱动程序不能这样说，因为我们在Citra的朋友很乐意告诉你，但幸运的是，这不是问题。主要问题是驱动程序运行的最常见硬件非常不合格，至少对于 Switch 仿真而言。显然，高端设备在GPU方面不会有太大问题，因为它们在硬件规格上并不落后于Adreno，但产品堆栈的其余部分将受到低帧率和GPU瓶颈的影响。

不幸的是，由于内核 API 不稳定，以及这些设备缺乏维护的 Mesa 驱动程序，目前没有任何实用的方法可以将 Mali 设备上正在运行的驱动程序替换为更好的驱动程序。如果设备附带的驱动程序对于 yuzu 来说太旧了，并且供应商没有更新它，那么很可能对此无能为力。

这要么是最好的计划过时，要么是纯粹的无能。我们会让你来评判。

有趣的东西正在烹饪，我们目前不能宣布几个尚未命名的项目，但知道这艘船不会很快放缓。

Blinkhawk 致力于更快的 GPU 仿真、ARM CPU 的本机代码执行、MacOS 获得一些急需的爱等等。我们将来会报告这些项目的进展情况，所以请睁大眼睛。

toastUnlimited开始对每场比赛配置进行大型UI重写。

一些未能及时赶上本文截止日期的更改包括修复影响在NVIDIA GPU上运行的虚幻引擎游戏的崩溃。我们将在下个月介绍这些内容。

这就是所有！感谢您阅读到最后。我们希望下个月见到你！