破解Windows：将RADV移植到Win32

# 撬开Windows：将RADV移植到WIN32 来源：https://www.collabora.com/news-and-blog/news-and-events/cracking-windows-open-porting-radv-to-win32.html Louis-Francis Ratté-Boulianne 头像 Louis-Francis Ratté-Boulianne 2026年7月28日 RADV 是面向 AMD GPU 的开源 Mesa Vulkan 驱动。多年来，它已成为 Linux 图形栈的基石。如今，它实际上已成为 Linux 上 AMD 硬件的默认 Vulkan 驱动。AMD 甚至终止了其基于 PAL（平台抽象库）的替代方案，转而将开源工作统一到 Mesa 上。 然而在 Windows 上，AMD 用户仍然只能使用专有驱动。但**别慌**，我们有解决方案：将 RADV 移植到 Windows，把已在 Linux 上证明自己的同一套开源 Vulkan 实现带给他们。这听起来有些不可思议，但我们或许真的能做到——甚至比光速还快（剧透：其实没那么快）。 在 Windows 上拥有开源 Vulkan 驱动将带来许多可能性：跨平台的统一代码库、更便捷的调试和实验、更快的修复迭代，以及社区（例如游戏开发者）报告问题或贡献改进的途径——这些改进将惠及所有操作系统用户。 ### 从第一个三角形开始…… 这项工作直接建立在 Faith Ekstrand 铺设的基础上，她首先探索了在 Windows 上运行 RADV 的可行性，并在 XDC 2024 上展示了她的发现。我们强烈建议你去观看她的[演讲](https://www.youtube.com/watch?v=q8KHm5TPrbc&t=44s)，不过这里先做个简要总结。 她演讲的一个核心观点是：自 Windows 10 以来，WDDM2 接口为第三方驱动提供了比之前版本好得多的基础。它定义了用户态驱动（UMD）如何与操作系统及内核态驱动（KMD）交互的清晰模型。 然而，当然存在一个重大障碍：许多 D3DKMT 调用会携带*私有驱动数据*——不透明的、厂商特定的二进制数据块，其内容完全由驱动决定。这意味着 UMD 和 KMD 仍然紧密耦合，而且这个接口完全没有文档记录。 为了解决这个问题，Faith 创建了 [wddm2-pdd-re](https://gitlab.freedesktop.org/gfxstrand/wddm2-pdd-re/) 工具，用于记录一些 D3D12 应用程序的 WDDM2 调用和私有数据内容。通过这种方法，她成功逆向工程了足够多的私有接口——包括查询适配器信息、分配缓冲区、创建队列和提交命令——从而使 RADV 能够向专有内核驱动提交工作负载。最终，她甚至成功让一个旋转的 3D 模型在她的屏幕上完美显示。 ### …到第一个游戏 Faith 的工作证明了这是可行的，而本项目则接过了接力棒。目标是进一步改进：使其更灵活（通过减少硬编码值来支持不同硬件）、更可移植（摆脱 WSL，实现原生 Windows 支持），以及更稳定（不再在 deqp-vk 测试两分钟后崩溃）。 我们改进了命令流处理和同步，并增加了对稀疏绑定、细分与任务着色器、以及 GPU 属性动态查询等功能的支持。目前仍未完全符合规范（尽管成功率已大幅提升），但真正的亮点是能够用 RADV 运行我们的第一个游戏：**《反恐精英 2》**。任何人只需使用 `-vulkan` 参数切换渲染器即可尝试。 《反恐精英 2》在 RADV 上运行 ### …穿越黑暗 与任何移植和/或逆向工程项目一样，我们也遇到了一些挑战： - **新一代芯片太敏感了**：我们是在第 11 代硬件（RX 7900 XT）上进行实验，而 Faith 使用的是第 10 代 GPU（RX 7800 XT）。由于这两代之间的架构变化，我们在相当长一段时间内无法复现 Faith 的结果。主要问题是，只要尝试做比将表面清除为硬编码颜色更复杂的事情，就会挂死。不幸的是，在 Windows 上缺乏调试此类挂死的工具，这迫使我们改进工具，以尽可能减少与专有驱动的差异。我们将逆向工程工具升级为完整的 WDDM2 日志层，能够分析任何使用官方 Vulkan 驱动运行的应用，并增加了转储命令流、寄存器和着色器代码的支持。 - **编译器不配合**：Mesa 主要针对 GCC 和 Clang 开发，其代码库依赖于许多在使用 MSVC 编译时不成立的假设。例如，MSVC 在处理枚举类型时与其他编译器不一致：它可能将枚举值解释为有符号整数并限制为 32 位，这会导致一些非常意外的行为。 - **听说你喜欢不透明二进制块**：那就让我们在不透明的 API 调用——`D3DKMTEscape` 中放入不透明数据吧。WDDM2 通过该方法提供了厂商特定的钩子，其中整个内容完全由厂商决定。没有定义结构，唯一的限制是不应复制已有的“标准化”调用功能。对我们来说幸运的是，目前看来我们可以安全地忽略这些，因为它们似乎专注于高级功能，例如多 GPU 渲染。 ### …走向未来 要使这项工作达到可生产状态，最大的悬而未决的问题是与专有内核驱动的接口。开发我们自己的 KMD 并不可行，因此我们需要与 AMD 的 KMD 通信。目前，这依赖于逆向工程得到的私有数据结构知识——这本质上是不稳定的。更糟糕的是，UMD 和 KMD 是作为匹配对一起发布的，没有任何向后兼容性保证，因此这些结构可能在不同驱动版本之间不加通知地更改。 为了使 RADV 在 Windows 上真正稳定且可维护，我们需要满足以下条件之一： - 一个**稳定、有文档的接口**，用于与专有内核态驱动通信，或者 - 一个**垫片库**，通过私有数据通道调解与 KMD 的通信，为我们提供一个稳定的构建表面，即使底层二进制块不断演变也能正常工作。 在**呈现**方面仍有大量工作要做。虽然 Jesse Natalie 在 Windows 上针对 WSI 做了一些工作（在 Dozen 驱动的背景下），但 RADV 目前仅支持较慢的 CPU 路径进行呈现。需要进一步工作才能利用 DXGI 交换链提升性能，但这需要能够从 D3D12 导入图像（又是不透明元数据，万岁！）。要实现零拷贝交换（图形管线的顶峰）则需要更多工作。对于不受 GPU 限制的应用程序，这可能导致高达 3 倍的性能提升。要完成这最后一步，还需要 AMD 乃至微软的直接参与（因为存在与图像共享相关的一些限制）。开源项目在生活质量改进方面有过先例，所以还是有希望的！ 我们希望这项工作能够展示 Windows 上开源 Vulkan 驱动的价值，并激励所有相关人员朝着那个稳定基础努力。有兴趣的朋友可以查看当前工作所在的[这个分支](https://gitlab.freedesktop.org/lfrb/mesa/-/tree/wddm2?ref_type=heads)。 同时感谢 Valve 赞助了我们这一阶段的工作，推动开源驱动进入 Windows。