AMD 的 Linux 图形驱动程序工程师一直致力于为新图形处理器提供驱动程序支持，现在这些补丁正处于发布的最早阶段。但是，由于驱动程序处理的变化，这一次与过去大不相同，他们在过去以一些五颜六色的可疑代号拼凑了大量补丁，以努力隐藏他们的硬件支持工作。

随着 Radeon RX 6000 系列的良好支持（以及更多的 PCI ID，可能会刷新 Navi 2/ 传闻 RX 6×50 GPU）各种 Navi 2 刷新 ID），VanGogh 驱动程序支持在 Steam 甲板上表现良好，黄鲤鱼 / 伦勃朗支持即将到来的 Ryzen 6000 系列移动 APU，毫不奇怪他们内部已经正在研究接下来会发生什么……再加上实际的硬件支持工作通常在产品发布甚至最初的开源驱动程序补丁之前很久就开始了，因为每一代都发生了很多变化，而且需要经历各种法律和发布新的启用代码之前的内部审查流程。

这一次有了新的硬件支持，它的出现更加巧妙，但仍然足以引起我的注意，在一百小时的工作周期间对邮件列表和 Git 存储库的无情监控。近年来，AMD 提供了预发布 Linux 驱动程序支持，对于新的 GPU/ASIC 支持，他们通常会以一些长补丁系列的形式提供初始支持，并提出一些丰富多彩的鱼代号，如 Sienna Cichlid、Yellow Carp、Dimgrey Cavefish ， 和别的。这些特定于 Linux 的代号有助于隐藏底层产品的代号，但也用于 GPU 固件文件名和代码中的其他区域。不过，这种方法似乎在很大程度上已成为过去。

你可能还记得我去年的文章AMDGPU 驱动程序对其设备枚举方法进行了大修。基本的驱动程序更改是基于发现的 IP/硬件块初始化显卡，而不是仅根据显卡 PCI ID 分割驱动程序代码路径。最近的 AMD GPU 支持“IP 发现表”，该表记录了构成 GPU 的不同硬件模块，从图形引擎到视频编码/解码、系统管理/电源管理、安全性和其他 IP 模块。

AMDGPU 驱动程序正在采用基于 IP 的发现的新方法。对 AMDGPU 驱动程序的返工已经被纳入 Linux 内核，因此对于最新的 GPU，在点亮 GPU 以解析该表并采用相应的代码路径而不是明确表示时，它已经采用了这种“基于 IP 的发现”方法根据 PCI ID 完成。基于 IP 的发现路径是驱动程序内更少硬编码信息的胜利，并有效地使驱动程序更加模块化和清洁。如果只是构建现有支持模块的新组合，这可能需要更少的驱动程序更改，这也可以帮助 AMD 在定制 SoC 方面。但正如去年所指出的，这也将有利于 AMD 提供新的硬件支持，因为它可以以更加模块化的方式完成，而不是一些大型的顺序补丁系列。

AMDGPU Linux 驱动程序正在从驱动程序的预定义/静态配置转移到“发现”表，以发现正在加载的 GPU 上发现的不同硬件/IP 块。最近几天出现了许多不同的补丁系列，用于推出新的 AMD Radeon 图形 IP 块，例如用于其系统管理单元的 SMU 13.0.5、VCN 3.1.2 视频编码、用于安全的 PSP 13.0.5，以及GC 10.3.6 等。

对于他们的新 GPU 而言，这似乎是前进的道路，并且一些提到“向前 ASIC”和未来硬件将出现在小型、独特的补丁系列中，而不是通常被视为新硬件支持的一部分的最初的大补丁系列。

有趣的五颜六色和鱼腥味的“Linux代号”看起来可能已经结束了……

固件文件名也采用块名称/版本，而不是这些新 IP 块中的可疑代号。

长话短说，AMD 似乎正在沿着这种基于 IP 的发现方法为他们的开源 Linux 驱动程序提供新的硬件支持。在迄今为止发布的几个不同的补丁系列中，到目前为止没有发现硬件意外，但仍然没有足够的代码来进行主要的 GPU 更新。至于启用这些不同的模块的用途，可能会在早期针对基于 RDNA3 的硬件开展工作。由于 AMDGPU 驱动程序已经支持已发布的 GPU 硬件，并添加了各种 RDNA2“刷新”PCI ID，并且已经拥有 VanGogh 和 Yellow Carp (Rembrandt)，很可能早期的补丁程序已经开始为 AMD 重申的 RDNA3 流动将于 2022 年下半年推出。

不管最近针对新 IP 块的补丁系列如何，如果 AMD 想要在 Linux 桌面上推出具有上游驱动程序代码的良好 RDNA3 GPU 支持，他们将需要推出他们的下一代 GPU 驱动程序代码并为今年夏天做好准备。由于 Linux 内核发布的节奏（以及用于 OpenGL/Vulkan 的 Mesa）以及著名 Linux 发行版的发布周期，今年夏天我们应该会看到更多明确指向 RDNA3 的补丁活动，如果他们的目标是好的结果在启动时使用上游代码提供开箱即用的支持，而不仅仅是他们以企业为中心的打包驱动程序集。