看到 Faith Ekstrand 在 XDC 2024 那场演示，我回去补了后续项目。这条在讲怎么把 RADV 从 Linux 原生搬到 Windows。出处是 Faith 的可行性研究，后续项目在 Collabora 的开发分支上，Valve 赞助了移植工作。
我一开始以为又是个“开源驱动登陆 Windows”的口号。读到中段才确认值得点——Faith 没等 AMD 给文档，她写了个 wddm2-pdd-re，记录 D3D12 应用实际发出的 WDDM2 调用和私有数据，把查询适配器信息、分配缓冲区、建队列、提交命令这些关键接口逆了出来。这等于不是读说明书装机，是把旁边师傅装机时敲的每一下都录下来了。
这个细节不点开看不到。WDDM2 从 Windows 10 起确实给第三方用户态驱动留了条缝，但 D3DKMT 调用里塞满了供应商私有数据，接口没文档，还跟内核驱动紧紧耦着。Faith 用这套逆向成果让 RADV 在 Windows 上成功往 AMD 专有内核驱动提交了工作，跑出一个旋转的 3D 模型。她那份研究最诚实的部分是：她承认这只是一层逆向出来的皮，底下的内核驱动随时能把结构改了。
后续项目把目标写得挺实在——少写死硬编码值、原生 Windows 不用 WSL、别跑两分钟就崩。第三点不是玩笑，他们的第一个版本测试两分钟就挂。
真正让我确认这条值得推的地方在 RX 7900 XT 那段。Faith 在 RX 7800 XT 上跑通的路径，换到 7900 XT 上长时间复现不出来。不是环境漏了变量，是两代 GPU 架构变了，简单清除表面以外的操作直接导致挂起。团队后来把逆向工具升级成完整的 WDDM2 日志层，能分析任何用官方 Vulkan 驱动跑的应用，转储命令流、寄存器和着色器代码。这个升级方向是对的——逆向工程不是一次性工具，得一直跟着硬件代际走。
还有个很多人不会写出来的坑：MSVC 在枚举处理之类的地方跟 GCC/Clang 语义不一样，Mesa 搬到 Windows 编译就出意外行为。这种细节只有真把代码挪到 MSVC 下的人才碰得到，所以后面那些“未通过 Vulkan 一致性认证但能跑《反恐精英2》”的结果，我信他们是真的在跑，不是拿截图喊话。
性能部分我先持保留。目前 RADV 在 Windows 上只能走比较慢的 CPU 路径呈现，要接 DXGI 交换链还得能从 D3D12 导入图像；零拷贝交换说能给非 GPU 绑定的应用带来 3 倍提升，但前提是 AMD 和微软都得参与解锁。这个 3 倍我暂时记着，因为前置条件太长，不点开的人可能会把它当成“装上就能快三倍”的承诺。
这条链接最该带走的不是某个功能列表，是 D3DKMTEscape 那个接口的现状。它支持供应商自定义钩子，内容完全由供应商决定，目前看起来聚焦在多 GPU 渲染之类的功能上，可以先忽略。但只要 AMD 那边结构一改，这边逆向出来的私有数据立刻作废。所以项目想从“演示能跑”走到“生产可维护”，只有两条路：AMD 给一份稳定文档化的接口，或者有人写一个 shim 库去调解 RADV 和内核驱动之间的通信。没有这个，现在能动，内核驱动一改就挂。
AMD 那边其实已经停掉了基于 PAL 的替代方案，把开源工作统一到 Mesa。也就是说 Linux 用户有 RADV 这个事实标准，Windows 用户却只有专有驱动。这个割裂反而是这条移植最微妙的地方——不是技术上没有可能，是 AMD 在 Windows 这侧没有动力配合。Faith 的研究相当于把这条路走了一步，然后指给所有人看前面那道墙长什么样。
这条值得点开。不是因为它把 Windows 版 RADV 带到了生产可用门口，是因为它把“Linux 开源驱动为什么不能直接搬到 Windows”这点写透了。最值钱的段落不是旋转模型跑出来了，是那个私有数据版本不定的问题从一开始就写在前头。