吧务
level 13
通知
整个着色器生成过程已从头开始重新设计，因此现有着色器缓存已失效。用户将需要重新构建他们的着色器缓存，从头开始，与项目哈迪斯。
什么是哈迪斯计划？
哈迪斯计划是着色器反编译器代码重写的代码名，尽管在这一点上它已经变得远远不止这些。
对于那些不知道什么是着色器反编译器的人，您需要了解游戏如何渲染（显示/显示）任何内容的过程。着色器是一种特殊的程序，它被编码在gpu上执行各种任务，通常与显示图形有关。着色器通常用高级着色器语言编写，这些语言与所使用的图形API兼容。OpenGL着色语言（GLSL） ,标准便携式中间表示法-V（SPIR-V），和openglarb汇编语言（GLASM）. 游戏通常使用成百上千个这样的着色器来告诉GPU渲染什么以及如何渲染。
yuzu着色器生成在切换游戏的情况下，它们还使用着色器在交换机本身上渲染图形。但是，由于这些着色器是为交换机的GPU预编译的，yuzu无法使用它们直接使用主机GPU（用户的GPU）渲染图形。因此，yuzu首先将这些着色器反编译为IR，或中间表示，然后用于生成高级GLSL/SPIR-V/GLASM公司图形API和驱动程序用于在主机GPU上渲染游戏的着色器。
着色器反编译是将guest（在本例中为任天堂开关）GPU机器代码转换为可在主机（用户的PC）GPU上编译的表示的过程。着色器编译是获取该表示并将其发送到宿主GPU驱动程序以进行编译，然后在用户的GPU上执行的过程。
目标
Hades项目的主要目标是重新设计反编译器和着色器生成代码，重点放在简单性和准确性上。它的目的是使反编译和编译都更快，从而提高性能。重写反编译器可以让我们通过单元测试，采用类似于 动态，允许
正确的
程序分析和快速优化以产生中间表示。
黑暗之魂
勇者斗恶龙11借鉴dynarmic的书，开发人员选择使用SSA代表，因为它与SPIR-VIR用于着色器，感谢它对SSA的本地支持。至于单元测试，罗德里戈写的硬件的自制测试这有助于开发人员准确地模拟硬件行为。
但这只是个开始。在几个月的时间里，开发人员将继续面对并克服代码重写的许多障碍，项目的目标也将扩大，以适应更多的需求。
变更概述
Hades项目是开发人员的一项协作工作罗德里戈 , 鹰眼，和 史诗男孩. 他们将所需的工作分配给他们自己，并花费无数的时间在编码、单元测试、游戏测试和性能验证上。
鹰眼主要致力于实现各种指令，包括反编译所需的纹理采样指令。他增加了对英伟达的支持VertexA shader stage，在Nvidia硬件上可用的非标准着色器后台文件，它在常规VertexB shader stage .
这允许游戏凯瑟琳: Full Body ,勇气默示录2，和时光之帽第一次渲染图形 鹰眼还修复了yuzu的纹理缓存中与虚幻引擎4（UE4）游戏中使用的纹理流有关的问题，解决了许多渲染问题。
注：由于我们的GPU仿真中存在竞争条件，要正确呈现Catherine全身，您可能需要禁用异步GPU仿真。
凯瑟琳: Full Body
时光之帽
勇气默示录2史诗男孩实现了几乎所有的算术、逻辑和浮点指令，并开发了整个GLSL后端。 GLSL公司当在yuzu配置设置中选择OpenGL API时，是默认的后端。
这个 GLSL公司后端重写并不是Hades项目最初计划的一部分，因为开发人员只打算进行工作 玻璃和 SPIR-V型，但后来因为一些OpenGL的缺陷和速度而被包括进来 SPIR-V型编译器是。也就是说，一些OpenGL驱动程序可以从 SPIR-V型着色器，所以选择使用SPIR-V型在OpenGL上留下了一个实验设置。
马里奥疯狂兔子：王国之战
单色世界罗德里戈设计了支持这些变化的整体结构，并开发了多个优化过程以尽可能提高性能。除此之外，他重写了整个 玻璃（GL Assembly）后端，并将现有的前端光栅化器与新的后端集成。
这个 玻璃后端是一个特殊的路径，其中反编译着色器(汇编语言)跳过主机GPU上的着色器编译步骤，从而提高性能。不幸的是， 玻璃仅受Nvidia GPU支持，限制了性能提升的范围。
古惑狼4
最终幻想世界虽然这些是主要的变化，但也有许多其他的小改进。更改着色器的生成方式也意味着更改着色器信息呈现给渲染器的方式。为了简单起见，对其进行了彻底的修改，从而带来了一些新的特性，并易于缓存。
Vulkan管道缓存
从头生成管道所需的所有信息现在都缓存到磁盘上，从而几乎完全消除了Vulkan上的着色器停顿。相反，OpenGL仍然会遇到由于不可预测或未记录的状态更改而导致的着色器停顿。当检测到新的着色器时，Vulkan仍然可以有轻微的结巴，但是在我们的测试中它并没有被注意到。
异步管道创建
玉祖已经支持了Asynchronous Shaders，其中draw调用将被跳过（渲染暂停），直到着色器或在Vulkan的情况下是管道编译。这在某些情况下是很好的，因为它允许更一致的播放会话，最大限度地减少着色器编译中的结巴。但这也有一个很大的缺点：它引入了图形问题，这些问题有时会在整个播放过程中持续存在。虽然在重新启动模拟并缓存着色器后这不是问题，但这不是最佳选择。
为Vulkan实现这一点的更好方法是并行构建管道，而不跳过draw调用。换句话说，在构建管道时继续处理GPU命令。这允许在游戏执行时为每个CPU线程（减去一个）并行构建一个管道。这样可以减少口吃，这在某种程度上类似于跳过draw调用。
这是怎么回事？为了理解为什么这是可能的，有必要解释yuzu的Vulkan命令记录是如何工作的。有时会调用“线程”和“提交”命令。
这个线程与主GPU线程并行运行。这意味着当主GPU线程继续执行时，CS线程可以按顺序构建管道，定期将新命令推送到CS线程。
遗憾的是，目前在OpenGL上这是不可能的，因为比起yuzu在自己的CS线程上，驱动程序等待CS线程的次数更多。如果我们优化整个OpenGL后端以避免在draw调用中调用“glGen*”和“glGetSynciv”，这可能是可能的。甚至更多！！
除了这些大的改进之外，我们还有许多小的优化。以下列出了一些值得注意的问题：
项目Hades跟踪常量缓冲区中使用的字节数，并将此信息传递到缓冲区缓存。这会减少某些标题上载的字节数，从而提高性能。
Vulkan命令提交到GPU现在发生在单独的CS线程上，在Super Mario Odyssey，但仍在同步显示到屏幕。
的同步纹理缓冲区在纹理缓存和缓冲缓存之间，修复了Koei Tecmo游戏中的一些崩溃。
生成专门的Vulkan描述符池，在类似的管道中共享池。这减少了大多数驱动程序的内存消耗和引导时间，与以前的方法相比，AMD上节省了约700 MiB的VRAM。
使用VK_chkhr_push_描述符如果有的话。在Nvidia上更新描述符集的开销减少了57%，在Intel上减少了10%（根据Super Smash Bros. Ultimate最终目的地为1v1）。它还可以减少内存消耗，但这还没有被测量过。
使用保守光栅化和VK_EXT_激发_顶点如果有的话
每个管道使用专门的“预绘制”功能，以减少不必要的工作。
Texture Reaper，它会清除VRAM中最少使用的资源，以减少VRAM的使用。我们将在下一个进度报告中详细介绍这一点和其他方面。
图形修复
![[吐舌]](/static/emoticons/u5410u820c.png)
![[真棒]](/static/emoticons/u771fu68d2.png)
