电脑装配网

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

 人阅读 | 作者xiaolin | 时间:2024-01-16 10:14

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已经开始血腥了。

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


文章标签:

本文链接:『转载请注明出处』