面向英伟达用户的PSA:第3部分
还没有结束.
如你所知，常规的NVIDIA台式机和笔记本电脑GPU不支持解码ASTC纹理，因此yuzu利用GPU的计算能力来并行化该过程。然而，最近发布的511。XX驱动程序引入了一个影响我们基于计算着色器的加速ASTC纹理解码的问题。


脆皮(超级马里奥奥德赛)
经过一番调查，epicboy发现bug的原因是新驱动引入的过度优化(一个场景的优化会导致另一个场景的问题)。行为上的小小改变就解决了这个问题。您可以在请求中找到更多技术信息。
正在玩的用户Hyrule Warriors: Age of Calamity或者Luigi’s Mansion 3应该坚持47X。XX系列的驱动程序，因为任何新版本都会有几个渲染问题。别担心，我们正在调查原因！

抽象艺术生成器(赫鲁勒战士:灾难时代)
另一方面，511.65版本包括对最近发布的Vulkan 1.3的支持，并且在使用所述应用编程接口时大大提高了性能。一些游戏显示性能提升高达24%！
未完待续......

新传奇
最后，经过二十多年，神奇宝贝系列脱离了它的老套模式，在最近发布的游戏中实现了游戏性的重大改变Pokémon Legends: Arceus.
所有这些都是以图形保真度为代价的。但是，嘿，还有更难看的游戏…在游戏立方体上.
除了令人失望的图形，这款游戏的发布暴露了yuzu的几个问题，甚至帮助我们解决了影响更多游戏的长期问题。
bunnei修复了在用于的代码中发现的死锁在内核间迁移线程，这导致中出现了一些值得注意的软锁Pokémon Legends: Arceus.
这个问题可以总结如下:一个线程(threadA)将会等待另一个(线程B)来释放锁，反之，释放线程B会等待线程A释放另一个锁，导致死锁。
几十年来最好的游戏变化(神奇宝贝传奇:阿尔宙斯)
从内核问题开始，epicboy实现了各种GPU更改。
他发现减少缓冲区分配量在开始时，而不仅仅是在结束时，防止了游戏在某些位置崩溃。
一些Vulkan驱动程序，尤其是英特尔Windows驱动程序，无法处理64位原子操作(可以独立于任何其他进程运行的操作)。epicboy增加了yuzu对无符号2x32位原子操作的支持，因为这是此类驱动程序使用的后备选项。有了这一变化，游戏启动时英特尔图形处理器运行Vulkan。
AMD有一个长期的问题Transform Feedback在他们的官方Windows和Linux驱动程序中，导致了无数游戏中的渲染问题。虽然这个问题最近在Linux AMDVLK驱动程序中得到了解决，但AMD Windows驱动程序仍然需要被告知Execution Mode接下来将被使用。
明确声明使用Xfb Execution Mode在开始使用Transform Feedback之前，在AMD Windows Vulkan驱动程序上解决了所有与之相关的问题，不仅受益Pokémon Legends: Arceus，而且还喜欢游戏Xenoblade Chronicles 2, Xenoblade Chronicles Definitive Edition, Hellblade: Senua's Sacrifice, Donkey Kong Country: Tropical Freeze, POKKÉN TOURNAMENT DX，还有很多很多其他的。


神奇宝贝传奇:阿尔宙斯


异刃编年史权威版


驴孔国:热带严寒
Pokémon Legends: Arceus受到顶点爆炸的影响，呈现出看起来像随机拉伸的纹理。坏消息是这是Buffer Cache，修复它需要相当长的时间。
好消息是Blinkhawk在epicboy的一些帮助下，设法实施了一种临时的解决方法来避免这个问题，同时一个永久的解决方案开始成形。写入前刷新缓冲区以最低的性能成本将我们从多边形地狱中拯救出来。


想象一下从太空看它的样子(神奇宝贝传奇:阿尔宙斯)
在这一天，我们开始计划另一个缓冲区缓存重写。
首先，阿尔宙斯展示了比正常情况高得多的虚拟内存使用，导致2GB图形处理器用户在过场动画中崩溃。Blinkhawk的解决方案是扩展缓冲区缓存增加的特定方向，而不是以前的两倍大小的方法。这允许2GB用户定期播放，4GB用户能够扩展到2倍，而不用担心崩溃。
下面是一些一般性建议:
从以前的Switch Pokémon游戏中进行保存将在教程结束后解锁特殊的服装选项。
我们测量了(当前)最新的22.2.1 AMD视窗驱动程序的微弱性能提升，如前所述，511.65 NVIDIA视窗驱动程序的性能提升了24%。乍得武尔坎1.3伸出援手。
关于图形处理器精度，虽然Normal产生最高的性能，High允许适当的粒子渲染，所以如果你想要额外的精度和性能，坚持High.
效果、粒子和某些攻击似乎在超过原生1x的分辨率下呈现不正确。虽然我们正在调查这种情况的原因，但它似乎也发生在Switch本身上，所以这可能只是这些着色器的性质(感觉让人想起3DS神奇宝贝小游戏.

谢谢瑟弗罗斯特！(神奇宝贝传奇:阿尔宙斯)

yuzu的默认设置是使用GLASM在OpenGL中运行游戏，GLASM通常被称为程序集着色器。这些设置会在人物身上造成诡异的阴影痘痘，解决的办法就是要么用GLSL代替GLASM，要么我们推荐的，完全改用Vulkan。


碎的阴影？零！(神奇宝贝传奇:阿尔宙斯)
运行Windows的400系列以上的镭龙图形处理器的用户将由于过时和不支持的驱动程序而遇到崩溃。即使是经过修改的驱动程序似乎也没有帮助，所以唯一的解决方案是使用Linux及其仍然受支持且速度相当快的Mesa驱动程序。
最后，过度适度使用或高价值的Anisotropic Filtering使用某些GPU配置会导致顶点爆炸。我们仍在调查原因。

其他图形修复
布林卡霍克做了一些对垃圾收集器的更改 (GC)，其中包含了大量的bug修复，改进了算法，使其以更智能的方式清理内存，同时也提高了iGPUs的效率。
的值minimal, expected，和critical阈值被重新平衡，因此它不会在内存更大的GPU上表现得如此激进，同时它仍然在低内存显卡可接受的范围内执行工作。此外，yuzu现在查询GPU内存的大小，而不是估计它GC以便在清洁时做出更好的决定。这些变化寻求对低端和高端图形处理器都有最大的好处，而不会对任何一个产生负面影响。
特别考虑了ASTC纹理，这是众所周知的沉重的记忆。这GC会过早清理它们，导致使用这些资源的标题的图形损坏。由于这个原因，决定何时清洁ASTC纹理的条件变得不那么严格，这应该可以缓解大多数场景中的问题。
虽然这些变化最初是YFC项目中，Blinkhawk决定现在实施这些变革，以缓解与之前相关的问题GC实施。这个项目还有很多东西要做，所以请在未来的更新中继续关注更多信息。
请记住，特殊情况标题如ASTRAL CHAIN仍然需要3GB或更多的VRAM才能正确模拟。
另一方面，一些标题，如Super Mario 64端口(自制)，会在一些GPU模型(尤其是iGPUs)中遇到冻结。
Blinkhawk研究了这个问题，并注意到它位于我们的Vulkan Scheduler中，这是一个抽象命令缓冲区的类，因此它可以在Vulkan环境中执行类似OpenGL的操作。
由于调度程序管理在将图形处理器命令发送到设备之前必须对其进行排队的顺序，因此用于确定这一点的隔离逻辑必须正确计时。
以前，调度程序只会对类型偏移量不为零的命令块进行排队。出现问题是因为存在一种特定的有效命令类型，其偏移量实际为零。不考虑这种情况会妨碍调度程序的隔离逻辑，使其无法正常执行工作。
谢天谢地，解决方案不需要任何困难的改变，Blinkhawk能够通过以下方式缓解这些冻结提交简单的补丁解决了这个特殊的问题。

是他！(超级马里奥64自制)

内核更改
内存管理的代码——内核的功能之一——最初是根据当时可用的信息在2020年初写回来的。从那以后，任天堂Switch的操作系统进行了多次更新，并通过逆向工程获得了新的文档。
因为这个原因，bunnei一直在研究用于管理内存的每一部分代码，重点是提高内核的稳定性和准确性。
这些变化包括复习记忆属性定义和许可，所以它们符合最新的行为HorizonOS更接近。大多数用于映射和取消映射内存的代码是整理好了，各种功能被重新命名以匹配官方命名。同样，用于分配和清除堆内存的代码是回顾就这样。
这种新的实现应该表现得更好，并且使代码更容易阅读和导航。
在调查长期以来与Pokémon Sword/Shield，bunnei发现它们与种族条件有关。
第一种情况发生在向服务打开新会话时:也就是说，yuzu将创建一个host thread(一个非仿真线程)，服务会话请求可以异步调度到其中。当此会话关闭时host thread因为在添加新会话的同时，正在从跟踪列表中删除结束会话，这导致了比赛状态。
当游戏想要发送特定的音频给扬声器播放，请求将特定的图形加载到内存中等等时，服务就会被游戏请求。Pokémon Sword/Shield特别是，非常频繁地打开和关闭LDN服务会话，这就是为什么它是受影响最大的标题之一。
经过引入一个工作线程来管理服务列表，现在只有一个线程能够创建或销毁服务会话，从而防止崩溃的发生。
遵循这一线索，bunnei重新访问了用于退出线程的代码，并发现发生了另一种竞争情况，线程引用正在被销毁，而它们仍然可以选择进行调度，从而导致崩溃。
解决办法是更准确地重新实现线程终止代码，以便与HorizonOS相匹配。yuzu现在等待线程从所有内核中被调度出来，然后再关闭它，这样它只有在不再运行时才会被销毁。
另一个长期存在的问题是Pokémon Sword/Shield与用于高级仿真的代码有关(HLE)服务线程管理。
当游戏请求某些服务时，不是模拟任天堂Switch操作系统的内部逻辑(这将是低级模拟，LLE)，yuzu运行一个由开发人员编写的实现，该实现在用户的计算机上执行相同的工作。
这些HLE服务需要能够与仿真内核交互，以便获取锁和触发器进行重新调度等。yuzu通过利用dummy threads，它们被创建为模拟的KThread实体。
A dummy thread是为每一个host thread运行在用户计算机上的服务接口，以便每当内核需要与host thread，它可以通过这些来做到dummy threads.
以前，这些dummy threads当主线程被破坏时，它们不会被释放，因此，它们会随着时间的推移而积累。由于内核限制了一个进程的线程数量，yuzu最终无法在长时间的游戏会话中创建更多的线程来打开服务接口。此外，这些虚拟线程可能会无意中被调度到仿真内核上，从而导致崩溃，因为它们不是真正要运行的线程。
调查完这些问题后，布内实施了各种修复和检查纠正这种错误行为，防止资源泄漏和崩溃。
下一个，邦尼修正了KThread计数器的递增/递减操作，因为旧的实现是不正确的，偶尔会下溢。这是前面提到的用来记录所有KThread确保内核强加的限制不被违反。
epicboy还看了一下内核，并添加了一个新的关闭方法正确同步线程在它们毁灭之前。此更改修复了在yuzu中停止仿真时可能出现的挂起。

未来的变化
我们的开发项目进展顺利。例如，german77正在享受一些被大量要求的功能。Blinkhawk设法完成了一个绝密项目罗德里戈之前未完成的变绿, Host Conditional Rendering。希望将来能听到更多Project Y.F.C.新闻。
现在是最近一些内部测试的一个小漏洞:Marvel Ultimate Alliance 3: The Black Order从19跳至51 FPS，你的敌人的墨水Splatoon 2工作正常，两个变化改善Vulkan。


性能提高一倍以上，只需几升开发人员的眼泪(漫威终极联盟3:黑色订单)
那都是乡亲们！有你在这里总是令人愉快的，希望我们下个月再见！

补7楼