新的一年，还有更多的工作要做！2023 年以大量图形更改、音频和输入改进、TAS 和 LAN/LDN 修复等开始！请继续关注yuz-ers，这只是今年即将发生的事情的开始！
新的挑战者即将到来！
在上个月合并期间，其他一些与GPU相关的更改不得不推迟。 一位新贡献者所做的一项更改溜走了，极大地改善了 Vulkan 的体验，几乎感觉像是在作弊...... 变化很简单：Wollnashorn 决定使用官方 Vulkan API 来存储和验证管道缓存（也称为着色器），而不是依赖 GPU 驱动程序来存储和验证管道缓存（也称为着色器），并且让像 Windows AMD 驱动程序这样的常见嫌疑人由于一些任意的低大小限制而无法存储其中的 95%。Project Y.F.C. 1.5
通过将整个管道缓存存储在 yuzu 文件夹之间的自定义文件中，在 Windows 上运行的 AMD GPU 现在可以在几秒钟内正确加载大型缓存，这是应该的。 这为我在玩 RX 6600 时节省了数小时的时间，因为该游戏具有许多重型着色器的可爱特权。 使用 25000 个着色器启动游戏过去需要近 15 分钟，驱动程序仅提供前 3000 个左右的着色器，其余的始终需要重新编译。这个过程现在只需几秒钟。Xenoblade Chronicles 3
NVIDIA和Intel在着色器构建方面比AMD更快
但这不仅仅是AMD Windows用户的另一个修复程序。虽然目标已经实现，但好处并不止于此。 事实证明，与依赖 GPU 驱动程序相比，本地存储的文件保存速度要快得多。 可能是由于执行的检查较少？ 所有 GPU 供应商在面对新的着色器时都会看到卡顿减少！
通常的限制适用：缓存仍要求驱动程序进行验证，因此将其更新到较新版本或较旧版本将需要重新编译，并且由于缓存是特定于供应商的，因此如果您切换到其他供应商的新 GPU，您将无法保留缓存。（我们很高兴现在有两个以上的选择。
虽然 Wollnashorn 一开始打算将此功能作为可选功能，但我们认为它是完全稳定的，因此现在默认启用它。 任何有兴趣测试禁用它的人都可以在中找到新选项。Emulation > Configure… > Graphics > Advanced > Use Vulkan pipeline cache
仅 Vulkan，OpenGL 在计算工作方面并不那么灵活
Wollnashorn为新的一年提供了另一个惊人的条目，在OpenGL后端实现了对AMD的FidelityFX超分辨率（FSR）的支持。虽然AMD只打算将这种适配过滤器与Vulkan和Direct3D 12一起使用，但它实际上是可移植到OpenGL的，并且与其他过滤器相比，它通常提供更好的结果。 谢谢！
费米用户欢欣鼓舞
火焰之纹章团结
该系列的新条目，除了一些核心变化之外，这是一个很好的！ 此版本最好的部分是在技术方面。 笨重而缓慢的Koei Tecmo引擎已经一去不复返了。 改用更加灵活和优化的 Unity 引擎。Fire Emblem Engage
对于我们仿真爱好者来说，这意味着在非常低端的硬件上可以实现 60 FPS，并且在解锁帧率的情况下也可以合理地玩游戏。只有一些动画和 2D 元素会遇到更高帧率的问题，我们希望模组社区能够解决这一问题。 我们希望看到 120 甚至 240 FPS 模组在相当强大的硬件上运行良好。
另一点，也许更重要，是着色器卡顿。 Koei 的引擎因拥有臃肿的着色器而臭名昭著，如果没有我们方面的大量工作，可以使任何 GPU 驱动程序在超时时崩溃。 另一方面，Unity 具有更轻的着色器，让 Vulkan 的并行构建大放异彩，如果您的 CPU 没有足够的线程来隐藏剩下的少量卡顿，异步着色器构建提供了额外的帮助。
尽管如此，新的游戏发布，新的问题和新的修复。因此，让我们列出到目前为止所做的工作。
byte[]，他可能刚刚发现也可能不是刚刚发现火焰纹章系列，他注意到着色器编译器的一个问题：在着色器中实际有意处理多重采样（MSAA）纹理的唯一地方是在着色器后端，尽管不正确。 在后端，它被完全忽略，而在后端，它为指令生成了无效的参数组合，这导致 Mesa 在处理我们的着色器时中止。传递多样本信息修复了崩溃，但留下了更多的工作要做......GLASMGLSLSPIR-VSPIR-V
...着色器编译器的原始作者之一 Epicboy 注意到了这一点，并提出了一系列快速修复来解决的问题。 他的第一个修复是继续 byte[] 启动的内容，并在后端和后端完全实现多采样纹理提取，使用这些后端清理游戏的渲染。GLSLGLASM
并列JS
从潜行到战术角色扮演（火焰纹章交战）
然后，他又实现了两个更改：防止TXQ指令的翻译产生另一个无效的参数组合，然后使用，实现对多采样图像的完全支持，只有一些小的松散端需要整理 - 这将需要另一个缓存失效。 我们先发制人地向所有《粉碎》玩家道歉（即使它还没有发生）。TXQ instruction
并列JS
现在你最喜欢的角色不会在暗影领域（火焰纹章参与）
此固定菜单呈现在其他游戏中，例如 和 .Dokapon UP!Pokémon Mystery Dungeon: Rescue Team DX
并列JS
以火攻火（神奇宝贝神秘地下城：救援队DX）
正如任何 NVIDIA 玩家都会告诉您的那样，Unity 引擎游戏在 OpenGL 上更稳定，这是首选旧 API 的罕见情况之一。 我们正在努力解决此问题，但现在，如果您在将 Vulkan 与 NVIDIA GPU 一起使用时遇到崩溃，请尝试改用 OpenGL，作为替代方案，看看禁用加速 ASTC 纹理解码是否有帮助。 与往常一样，这两个选项都可以在中找到。Pokémon Brilliant Diamond/Shining PearlEmulation > Configure… > Graphics
涡轮增压模式
如果您遵循以前的进度报告，您可能已经注意到某种模式。 你的作家有一个愚蠢的想法，而byte[]是最终听我胡言乱语并使这个想法成为现实的人。 这个例程成功地与 Vulkan 的 SMAA 一起使用，但没有成功增加暂存缓冲区大小以利用 ReBAR，可悲的是，这一次，它几乎与 ，或其官方/无聊的名称，强制最大时钟一起工作。Turbo mode
你也许能够看到这是怎么回事。一年前，Patreon 的资金让您的作家能够访问 RX 6500 来帮助测试和调试。 那张卡死得很可怕，过早地死了（没有人错过它），但在踢水桶之前，它让我们了解到，如果你不经常把工作推到GPU上，AMD的RDNA和RDNA2硬件就会遭受严重的降频问题。 值得庆幸的是，由于加密采矿崩溃，RX 6600 取代了它的位置，无需额外费用。 在你的脸上，矿工。
咳咳，回到正题。 该卡将尝试尽可能多地空闲以节省电量，因此如果工作负载不是恒定的，它会切换到较低的时钟速度，再次提高时钟需要时间。 这会导致性能降低。 虽然这个问题以一种或另一种方式影响了所有GPU供应商，但只有AMD遭受高达70%的性能损失，同时使用Windows和Linux驱动程序。是的，甚至是 RADV。
由于要求用户应用外部解决方法，例如在后台编码视频以保持VRAM使用率高或超频最低时钟速度不容易沟通，或者可以算作使您的保修失效，因此您的作家试图找到干净解决此问题的方法，因为AMD似乎对此不太感兴趣。
解决方案再次来自超频背景。memtestCL 是测试视频内存稳定性的工具：您可以设置大小、要运行的迭代次数，计算负载将比较结果，通知您任何错误。 同时运行柚子和memtestCL完全修复了AMD卡的降频问题！
后来进行了一些小讨论和原型设计，解决方案开始形成。 并行创建和运行 OpenCL/CUDA 进程被认为是工作量太大，可能会被调度程序发送到后台，从而抵消任何收益。 相反，我们决定使用 Vulkan 自己的计算能力。 无用的虚拟负载将不断在 GPU 上运行，迫使它始终保持尽可能高的时钟，随之而来的是功耗。
四款最耗费 GPU 的游戏。像臭名昭著的RX 6500 XT这样的低端卡可以看到高达70%的跳跃
虽然这是一个简单的解决方案，但它有一些缺点，迫使我们遗憾地默认不启用此选项：
首先，并非所有用户都希望或能够以最佳性能运行他们的 GPU。在移动设备上，它会导致糟糕的电池寿命，或者达到AMD和Intel APU的功率限制，例如Steam Deck，其小型15W默认TDP。
其次，低恒定负载，例如以非常高帧速率运行的旧游戏，或者执行虚拟周期的模拟器，会产生一种称为线圈呜呜声的噪音，这是一种电“咕噜咕噜”，其强度随每个 GPU 而变化。有些几乎听不见，有些可以吓到他们的用户，即使卡没有受到伤害。
第三，虽然这是AMD专用GPU的安全选择，但在NVIDIA和英特尔上，结果变化更大。 较弱的NVIDIA卡（比RTX 3060弱的任何东西）很可能会在Turbo模式下失去相当大的性能，而功能强大，昂贵的显卡将看到类似于AMD的性能提升。 特别是RTX 4090在Turbo上的表现甚至比NVIDIA自己的控制面板中的“首选最大性能”设置还要好。
左边是RTX 4090的默认性能，中间是使用驱动程序的“首选最大性能”，右边是柚子的涡轮模式（神奇宝贝猩红）
英特尔一如既往地是一个特例。 虽然 Turbo 模式肯定有助于桌面 ArcGPU，但集成 Xe 显卡和更早版本只能运行一个队列。 这意味着，根据设计，这些 iGPU 无法同时渲染和运行计算任务。 虽然调度程序似乎做得很好，不会对 Turbo 造成任何性能损失，但在使用英特尔 iGPU 时，您仍然会遇到所有缺点，没有任何好处。
我们努力解决尽可能多的限制，但由于不同供应商和卡的结果差异很大，因此默认情况下该选项将保持禁用状态。 我们强烈建议大家测试它。如果它在游戏中产生性能提升，它应该在各个方面保持一致。 至少所有桌面AMD用户，Big Chungus NVIDIA所有者以及拥有Arc的5个人都将从中受益匪浅。 该选项可在 中找到。 ...我仍然更喜欢称它为涡轮模式...Emulation > Configure… > Graphics > Advanced > Force maximum clocks
让我们重复使用相同的图片，没有人会注意到它
更多 GPU 更改
以轰轰烈烈的方式开始新的一年，天际线成名的章程又回来了，为我们的着色器编译器项目进行了另一轮修复。 是 Switch 上提供的一项 NVIDIA 硬件功能，主要用于选择视口或图层，而无需实际的几何着色器，并且可供 yuzu 与桌面 NVIDIA 卡一起使用。 但是，AMD、英特尔和其他供应商不支持此扩展，并且需要使用几何着色器进行模拟。 Bylaws 添加了对几何着色器直通模拟的支持，修复了 、、 以及许多其他游戏中的渲染问题。Geometry shader passthroughNieR:Automata The End of YoRHa EditionMarvel Ultimate Alliance 3: The Black OrderPokémon: Legends Arceus
并列JS
机器人拍摄非常有趣（NieR：Automata The End of YoRHa Edition）
vonchenplus 实现了 Draw Texture 方法，这是 NVIDIA 独有的另一项功能，包括原生版本和模拟版本。 这就像Switch使用了某种NVIDIA GPU，嗯。
通常，OpenGL 和 Vulkan 等图形 API 需要着色器和一些几何体（至少是一个三角形）来将纹理渲染到帧缓冲区，但这绕过了这一要求，将轴对齐的纹理绘制到屏幕上，仅包含边界矩形的坐标。 在 NVIDIA 硬件上使用 OpenGL 时，yuzu 会尝试使用主机的绘制纹理功能，并在 Vulkan 或其他平台上用着色器进行模拟。 这将修复 上字幕屏幕的呈现。draw texture methodTitan Quest
并列JS
人们问为什么我们“让”游戏在NVIDIA硬件上运行得更快（Titan Quest）
byte[] 纠正了 Yuzu 处理交换间隔方式中的一个错误。在 Switch 上限制帧速率的一种方法是设置一个数字，控制帧的呈现次数，其中演示每秒发生 60 次。 程序可以通过将此数字设置为 30 来将自身限制为每秒 2 帧，通过将此值设置为 20 来将自身限制为每秒 3 帧，依此类推。 柚子错误地将交换间隔视为基于 1 的幂，因此对应于每秒 2 和 60 帧的值 30 和 3 正常工作，但值 15 错误地呈现为每秒 60 帧。 在修复此错误的同时，byte[] 还增加了对 mod 开发人员使用负值作为每秒 <> 帧的倍数的支持。 让（高帧率）游戏开始吧！
epicboy还修复了在OpenGL上构建异步着色器的一个长期问题，迫使着色器在发出可用性信号之前完全刷新并可用于主渲染上下文。 这应该可以缓解旧 API 中异步着色器独有的任何持久性图形错误。
Blinkhawk 回归，为世界上看似优化最少的神奇宝贝游戏带来了另一项重大性能改进。这允许它们在我们更快但精度更低的 GPU 正常模式下渲染，并在此过程中实现一些相关的优化。 玩得开心闪亮的狩猎！
如果你问为什么所有照片都在同一区域，这是最好的基准点之一。左侧为正常精度，右侧精度高（神奇宝贝猩红）
请记住，正常的 GPU 精度会产生帧的顶点爆炸，但持续时间也一样长。永久顶点爆炸消失了！ 高 GPU 精度会更干净，但速度更慢，所以选择你的立场。
作为GPU部分的最后一点，您的作者实现了一项自分辨率缩放器发布以来已经要求了很长时间的功能，但直到现在还没有人真正费心去看 - 额外的分辨率选项。
现在，您可以从 1.5 倍缩放或 7 倍和 8 倍的附加选项中进行选择（如果您对显卡有死亡愿望）。 用户报告证实，RTX 4090 可以在 8x 下玩一些游戏，而 RX 6950 XT 在 7x 下没有太多问题。 添加奇数 1.5 倍是因为我们的指标显示，最常用的非 iGPU 卡足够强大，可以在 1 倍时具有多余的性能，但不足以处理 2 倍。 中间地带非常适合在保持 30/60FPS 目标的同时获得更清晰的图形，或者如果用户有 1440p 显示屏。 我们认为这应该是目前合理的未来证明。
警告，请勿在弱设备上单击此图像：16K 分辨率（超级马里奥奥德赛）
小警告，AMD和英特尔硬件不支持像NVIDIA那么大的纹理，因此在某些游戏中可能会达到此限制并使驱动程序崩溃。 如果您有性能和VRAM备用，并且遇到崩溃，请降低乘数。
新的挑战者即将到来！
在上个月合并期间，其他一些与GPU相关的更改不得不推迟。 一位新贡献者所做的一项更改溜走了，极大地改善了 Vulkan 的体验，几乎感觉像是在作弊...... 变化很简单：Wollnashorn 决定使用官方 Vulkan API 来存储和验证管道缓存（也称为着色器），而不是依赖 GPU 驱动程序来存储和验证管道缓存（也称为着色器），并且让像 Windows AMD 驱动程序这样的常见嫌疑人由于一些任意的低大小限制而无法存储其中的 95%。Project Y.F.C. 1.5
通过将整个管道缓存存储在 yuzu 文件夹之间的自定义文件中，在 Windows 上运行的 AMD GPU 现在可以在几秒钟内正确加载大型缓存，这是应该的。 这为我在玩 RX 6600 时节省了数小时的时间，因为该游戏具有许多重型着色器的可爱特权。 使用 25000 个着色器启动游戏过去需要近 15 分钟，驱动程序仅提供前 3000 个左右的着色器，其余的始终需要重新编译。这个过程现在只需几秒钟。Xenoblade Chronicles 3
NVIDIA和Intel在着色器构建方面比AMD更快
但这不仅仅是AMD Windows用户的另一个修复程序。虽然目标已经实现，但好处并不止于此。 事实证明，与依赖 GPU 驱动程序相比，本地存储的文件保存速度要快得多。 可能是由于执行的检查较少？ 所有 GPU 供应商在面对新的着色器时都会看到卡顿减少！
通常的限制适用：缓存仍要求驱动程序进行验证，因此将其更新到较新版本或较旧版本将需要重新编译，并且由于缓存是特定于供应商的，因此如果您切换到其他供应商的新 GPU，您将无法保留缓存。（我们很高兴现在有两个以上的选择。
虽然 Wollnashorn 一开始打算将此功能作为可选功能，但我们认为它是完全稳定的，因此现在默认启用它。 任何有兴趣测试禁用它的人都可以在中找到新选项。Emulation > Configure… > Graphics > Advanced > Use Vulkan pipeline cache
仅 Vulkan，OpenGL 在计算工作方面并不那么灵活
Wollnashorn为新的一年提供了另一个惊人的条目，在OpenGL后端实现了对AMD的FidelityFX超分辨率（FSR）的支持。虽然AMD只打算将这种适配过滤器与Vulkan和Direct3D 12一起使用，但它实际上是可移植到OpenGL的，并且与其他过滤器相比，它通常提供更好的结果。 谢谢！
费米用户欢欣鼓舞
火焰之纹章团结
该系列的新条目，除了一些核心变化之外，这是一个很好的！ 此版本最好的部分是在技术方面。 笨重而缓慢的Koei Tecmo引擎已经一去不复返了。 改用更加灵活和优化的 Unity 引擎。Fire Emblem Engage
对于我们仿真爱好者来说，这意味着在非常低端的硬件上可以实现 60 FPS，并且在解锁帧率的情况下也可以合理地玩游戏。只有一些动画和 2D 元素会遇到更高帧率的问题，我们希望模组社区能够解决这一问题。 我们希望看到 120 甚至 240 FPS 模组在相当强大的硬件上运行良好。
另一点，也许更重要，是着色器卡顿。 Koei 的引擎因拥有臃肿的着色器而臭名昭著，如果没有我们方面的大量工作，可以使任何 GPU 驱动程序在超时时崩溃。 另一方面，Unity 具有更轻的着色器，让 Vulkan 的并行构建大放异彩，如果您的 CPU 没有足够的线程来隐藏剩下的少量卡顿，异步着色器构建提供了额外的帮助。
尽管如此，新的游戏发布，新的问题和新的修复。因此，让我们列出到目前为止所做的工作。
byte[]，他可能刚刚发现也可能不是刚刚发现火焰纹章系列，他注意到着色器编译器的一个问题：在着色器中实际有意处理多重采样（MSAA）纹理的唯一地方是在着色器后端，尽管不正确。 在后端，它被完全忽略，而在后端，它为指令生成了无效的参数组合，这导致 Mesa 在处理我们的着色器时中止。传递多样本信息修复了崩溃，但留下了更多的工作要做......GLASMGLSLSPIR-VSPIR-V
...着色器编译器的原始作者之一 Epicboy 注意到了这一点，并提出了一系列快速修复来解决的问题。 他的第一个修复是继续 byte[] 启动的内容，并在后端和后端完全实现多采样纹理提取，使用这些后端清理游戏的渲染。GLSLGLASM
并列JS从潜行到战术角色扮演（火焰纹章交战）
然后，他又实现了两个更改：防止TXQ指令的翻译产生另一个无效的参数组合，然后使用，实现对多采样图像的完全支持，只有一些小的松散端需要整理 - 这将需要另一个缓存失效。 我们先发制人地向所有《粉碎》玩家道歉（即使它还没有发生）。TXQ instruction
并列JS现在你最喜欢的角色不会在暗影领域（火焰纹章参与）
此固定菜单呈现在其他游戏中，例如 和 .Dokapon UP!Pokémon Mystery Dungeon: Rescue Team DX
并列JS以火攻火（神奇宝贝神秘地下城：救援队DX）
正如任何 NVIDIA 玩家都会告诉您的那样，Unity 引擎游戏在 OpenGL 上更稳定，这是首选旧 API 的罕见情况之一。 我们正在努力解决此问题，但现在，如果您在将 Vulkan 与 NVIDIA GPU 一起使用时遇到崩溃，请尝试改用 OpenGL，作为替代方案，看看禁用加速 ASTC 纹理解码是否有帮助。 与往常一样，这两个选项都可以在中找到。Pokémon Brilliant Diamond/Shining PearlEmulation > Configure… > Graphics
涡轮增压模式
如果您遵循以前的进度报告，您可能已经注意到某种模式。 你的作家有一个愚蠢的想法，而byte[]是最终听我胡言乱语并使这个想法成为现实的人。 这个例程成功地与 Vulkan 的 SMAA 一起使用，但没有成功增加暂存缓冲区大小以利用 ReBAR，可悲的是，这一次，它几乎与 ，或其官方/无聊的名称，强制最大时钟一起工作。Turbo mode
你也许能够看到这是怎么回事。一年前，Patreon 的资金让您的作家能够访问 RX 6500 来帮助测试和调试。 那张卡死得很可怕，过早地死了（没有人错过它），但在踢水桶之前，它让我们了解到，如果你不经常把工作推到GPU上，AMD的RDNA和RDNA2硬件就会遭受严重的降频问题。 值得庆幸的是，由于加密采矿崩溃，RX 6600 取代了它的位置，无需额外费用。 在你的脸上，矿工。
咳咳，回到正题。 该卡将尝试尽可能多地空闲以节省电量，因此如果工作负载不是恒定的，它会切换到较低的时钟速度，再次提高时钟需要时间。 这会导致性能降低。 虽然这个问题以一种或另一种方式影响了所有GPU供应商，但只有AMD遭受高达70%的性能损失，同时使用Windows和Linux驱动程序。是的，甚至是 RADV。
由于要求用户应用外部解决方法，例如在后台编码视频以保持VRAM使用率高或超频最低时钟速度不容易沟通，或者可以算作使您的保修失效，因此您的作家试图找到干净解决此问题的方法，因为AMD似乎对此不太感兴趣。
解决方案再次来自超频背景。memtestCL 是测试视频内存稳定性的工具：您可以设置大小、要运行的迭代次数，计算负载将比较结果，通知您任何错误。 同时运行柚子和memtestCL完全修复了AMD卡的降频问题！
后来进行了一些小讨论和原型设计，解决方案开始形成。 并行创建和运行 OpenCL/CUDA 进程被认为是工作量太大，可能会被调度程序发送到后台，从而抵消任何收益。 相反，我们决定使用 Vulkan 自己的计算能力。 无用的虚拟负载将不断在 GPU 上运行，迫使它始终保持尽可能高的时钟，随之而来的是功耗。
四款最耗费 GPU 的游戏。像臭名昭著的RX 6500 XT这样的低端卡可以看到高达70%的跳跃
虽然这是一个简单的解决方案，但它有一些缺点，迫使我们遗憾地默认不启用此选项：
首先，并非所有用户都希望或能够以最佳性能运行他们的 GPU。在移动设备上，它会导致糟糕的电池寿命，或者达到AMD和Intel APU的功率限制，例如Steam Deck，其小型15W默认TDP。
其次，低恒定负载，例如以非常高帧速率运行的旧游戏，或者执行虚拟周期的模拟器，会产生一种称为线圈呜呜声的噪音，这是一种电“咕噜咕噜”，其强度随每个 GPU 而变化。有些几乎听不见，有些可以吓到他们的用户，即使卡没有受到伤害。
第三，虽然这是AMD专用GPU的安全选择，但在NVIDIA和英特尔上，结果变化更大。 较弱的NVIDIA卡（比RTX 3060弱的任何东西）很可能会在Turbo模式下失去相当大的性能，而功能强大，昂贵的显卡将看到类似于AMD的性能提升。 特别是RTX 4090在Turbo上的表现甚至比NVIDIA自己的控制面板中的“首选最大性能”设置还要好。
左边是RTX 4090的默认性能，中间是使用驱动程序的“首选最大性能”，右边是柚子的涡轮模式（神奇宝贝猩红）
英特尔一如既往地是一个特例。 虽然 Turbo 模式肯定有助于桌面 ArcGPU，但集成 Xe 显卡和更早版本只能运行一个队列。 这意味着，根据设计，这些 iGPU 无法同时渲染和运行计算任务。 虽然调度程序似乎做得很好，不会对 Turbo 造成任何性能损失，但在使用英特尔 iGPU 时，您仍然会遇到所有缺点，没有任何好处。
我们努力解决尽可能多的限制，但由于不同供应商和卡的结果差异很大，因此默认情况下该选项将保持禁用状态。 我们强烈建议大家测试它。如果它在游戏中产生性能提升，它应该在各个方面保持一致。 至少所有桌面AMD用户，Big Chungus NVIDIA所有者以及拥有Arc的5个人都将从中受益匪浅。 该选项可在 中找到。 ...我仍然更喜欢称它为涡轮模式...Emulation > Configure… > Graphics > Advanced > Force maximum clocks
让我们重复使用相同的图片，没有人会注意到它
更多 GPU 更改
以轰轰烈烈的方式开始新的一年，天际线成名的章程又回来了，为我们的着色器编译器项目进行了另一轮修复。 是 Switch 上提供的一项 NVIDIA 硬件功能，主要用于选择视口或图层，而无需实际的几何着色器，并且可供 yuzu 与桌面 NVIDIA 卡一起使用。 但是，AMD、英特尔和其他供应商不支持此扩展，并且需要使用几何着色器进行模拟。 Bylaws 添加了对几何着色器直通模拟的支持，修复了 、、 以及许多其他游戏中的渲染问题。Geometry shader passthroughNieR:Automata The End of YoRHa EditionMarvel Ultimate Alliance 3: The Black OrderPokémon: Legends Arceus
并列JS机器人拍摄非常有趣（NieR：Automata The End of YoRHa Edition）
vonchenplus 实现了 Draw Texture 方法，这是 NVIDIA 独有的另一项功能，包括原生版本和模拟版本。 这就像Switch使用了某种NVIDIA GPU，嗯。
通常，OpenGL 和 Vulkan 等图形 API 需要着色器和一些几何体（至少是一个三角形）来将纹理渲染到帧缓冲区，但这绕过了这一要求，将轴对齐的纹理绘制到屏幕上，仅包含边界矩形的坐标。 在 NVIDIA 硬件上使用 OpenGL 时，yuzu 会尝试使用主机的绘制纹理功能，并在 Vulkan 或其他平台上用着色器进行模拟。 这将修复 上字幕屏幕的呈现。draw texture methodTitan Quest
并列JS人们问为什么我们“让”游戏在NVIDIA硬件上运行得更快（Titan Quest）
byte[] 纠正了 Yuzu 处理交换间隔方式中的一个错误。在 Switch 上限制帧速率的一种方法是设置一个数字，控制帧的呈现次数，其中演示每秒发生 60 次。 程序可以通过将此数字设置为 30 来将自身限制为每秒 2 帧，通过将此值设置为 20 来将自身限制为每秒 3 帧，依此类推。 柚子错误地将交换间隔视为基于 1 的幂，因此对应于每秒 2 和 60 帧的值 30 和 3 正常工作，但值 15 错误地呈现为每秒 60 帧。 在修复此错误的同时，byte[] 还增加了对 mod 开发人员使用负值作为每秒 <> 帧的倍数的支持。 让（高帧率）游戏开始吧！
epicboy还修复了在OpenGL上构建异步着色器的一个长期问题，迫使着色器在发出可用性信号之前完全刷新并可用于主渲染上下文。 这应该可以缓解旧 API 中异步着色器独有的任何持久性图形错误。
Blinkhawk 回归，为世界上看似优化最少的神奇宝贝游戏带来了另一项重大性能改进。这允许它们在我们更快但精度更低的 GPU 正常模式下渲染，并在此过程中实现一些相关的优化。 玩得开心闪亮的狩猎！
如果你问为什么所有照片都在同一区域，这是最好的基准点之一。左侧为正常精度，右侧精度高（神奇宝贝猩红）
请记住，正常的 GPU 精度会产生帧的顶点爆炸，但持续时间也一样长。永久顶点爆炸消失了！ 高 GPU 精度会更干净，但速度更慢，所以选择你的立场。
作为GPU部分的最后一点，您的作者实现了一项自分辨率缩放器发布以来已经要求了很长时间的功能，但直到现在还没有人真正费心去看 - 额外的分辨率选项。
现在，您可以从 1.5 倍缩放或 7 倍和 8 倍的附加选项中进行选择（如果您对显卡有死亡愿望）。 用户报告证实，RTX 4090 可以在 8x 下玩一些游戏，而 RX 6950 XT 在 7x 下没有太多问题。 添加奇数 1.5 倍是因为我们的指标显示，最常用的非 iGPU 卡足够强大，可以在 1 倍时具有多余的性能，但不足以处理 2 倍。 中间地带非常适合在保持 30/60FPS 目标的同时获得更清晰的图形，或者如果用户有 1440p 显示屏。 我们认为这应该是目前合理的未来证明。
警告，请勿在弱设备上单击此图像：16K 分辨率（超级马里奥奥德赛）
小警告，AMD和英特尔硬件不支持像NVIDIA那么大的纹理，因此在某些游戏中可能会达到此限制并使驱动程序崩溃。 如果您有性能和VRAM备用，并且遇到崩溃，请降低乘数。
并列JS
