换了一条技术路线

在 Triton 之前，社区尝试过一种“偷梁换柱”的做法：把开源实现的 d3d11.dll 和 dxgi.dll 直接丢到游戏目录里，让程序加载这些替代文件而不是 Windows 自带的系统库。这种办法确实能让部分游戏跑起来，但代价明显。

UTM 团队在技术博客中列出了三个硬伤：一是性能上不去，桌面合成器把画面当成一张普通图片处理，需要用处理器把显存里的图像逐帧搬到窗口位置，桌面体验不可能流畅；二是这两个文件属于系统核心组件，无法整体替换，带反作弊机制的游戏还会把这种改动直接判定为作弊；三是每装一个游戏就要复制一次文件，谈不上什么使用体验。

Triton 走的是另一条路——不去实现 DirectX 的应用接口，而是实现设备驱动接口，也就是显卡厂商真正要做的那一层。应用程序照常调用系统的 Direct3D 库，系统再把整理过的指令交给驱动，驱动通过虚拟化通道把活儿甩给宿主机。整套链路里，Windows 客户机看到的是一块“正常显卡”，而不是被人动过手脚的系统文件。

为什么没照抄现成方案

开源世界里能参考的样本极少。团队提到，Mesa 项目有一个 DirectX 10 的用户态驱动，但受限于苹果系统上虚拟图形渲染组件的功能缺失，无法直接沿用；VirtualBox 拥有目前唯一可用的开源 DirectX 11 用户态驱动，却被两个理由排除在外。

第一是技术上的顾虑。VirtualBox 的做法是把驱动接口调用先编译成一种中间字节码，再由宿主机把字节码还原成 DirectX 调用。多出来的这道转换意味着更多延迟和更多出错机会，社区论坛上大量游戏在 VirtualBox 中跑不起来，正与此有关。第二是许可协议不兼容，VirtualBox 采用的协议与 QEMU 和虚拟图形渲染组件所用的宽松协议存在冲突，代码无法直接引入。

Triton 的思路更取巧：既然系统的 Direct3D 库负责把接口调用翻译成驱动指令，那驱动这一侧干脆做一次“逆向翻译”，把指令还原回标准的 DirectX 调用，再交给此前已经跑通的传输层送到宿主机。宿主机收到的东西本身就是可以直接执行的调用，省掉了解释器这一整个环节。

苹果电脑上的进展与遗留问题

在 Linux 宿主机上，画面最终由 DXVK 转译成 Vulkan 完成渲染，已经能看到 Windows 桌面合成正常工作。苹果电脑这边情况更复杂：Vulkan 本身要再经过一层转译才能落到 Metal 上，稳定性和兼容性都有欠缺。团队因此把重心放在 DXMT 上——这个项目跳过中间环节，直接把 DirectX 11 翻译成 Metal，团队为它做了原生版本的分支，补上了共享纹理和共享栅栏这两项虚拟化必需的能力。

按照官方说法，目前这套驱动的稳定性还谈不上成熟，部分场景仍会崩溃，也尚未随 UTM 正式版本发布。相关代码已经分散在多个开源仓库中公开，包括 QEMU 的定制分支、虚拟图形渲染组件的分支以及 DXMT 的原生化改造版本，愿意自行编译的用户可以提前尝鲜。

对普通用户来说，这件事的意义或许要等到功能正式集成进 UTM 之后才能体会。但对开源虚拟化生态而言，QEMU 第一次在 Windows 客户机上拥有了完整的现代图形驱动栈，这条路走通本身就比跑起哪一款游戏更重要。

来源：UTM Blog