在前一篇文章中，我们介绍了Neptune，这是一个为VirtIO设计的Direct3D协议转发层。Neptune使我们能够跨越虚拟机边界序列化Direct3D API调用，这样我们就可以在Linux主机上以比在来宾中直接使用DXVK更快的速度在Linux来宾中运行Wine游戏。诚然，这里的回报并不是那么激动人心，但它为我们的真正目标奠定了基础：为Windows来宾提供现代图形加速。我们现在通过构建一个全新的Windows驱动程序Triton来实现这一目标，Triton与Neptune一起为QEMU虚拟机带来了完整的DirectX 11支持。 Crash Bandicoot三部曲（x64）在Windows 11 ARM64上通过QEMU虚拟化在macOS上运行。 Triton是什么？你可能会想：如果Neptune可以序列化Direct3D API调用，而Windows使用Direct3D，那么我们不是已经完成了吗？如果Direct3D在Wine中有效，它在Windows中也应有效，对吧？毕竟，Wine不就是Windows模拟器吗？ 简短的答案是：你在某种程度上可以。Neptune Mesa驱动程序构建一个d3d11.dll和dxgi.dll，它们完全实现了Direct3D API集，所以如果你只是把这些文件放在游戏的可执行文件旁边，它应该会加载这些文件，而不是Windows自带的驱动程序，这样你可以通过这种方式让一些游戏运行。这也是之前使用DXVK→Vulkan→Venus在应用程序内部运行Direct3D的尝试所采用的方法。但这种方法有几个缺点。首先也是最重要的一点是，你无法获得良好的性能，因为窗口合成器（DWM）“看到”的你的帧是图像，因此它需要使用CPU绘制将GPU图像缓冲区复制到正确的窗口位置。对于全屏应用程序，你可能能够执行一些技巧进行原生扫描输出，但你永远无法获得流畅的桌面体验。其次，由于d3d11.dll和dxgi.dll是Windows的核心组件，你不能替换系统文件并期望Windows继续工作。即使你确实设法让它工作，你也将无法玩许多专门检测这种修改的反作弊游戏。这就是为什么只能在每个应用程序的基础上加载DLL（而兼容性因情况而异）。这就引出了最后一点：需要将文件复制到每个需要工作图形加速的应用程序并不是一种用户友好的体验。正确的方法不是实现DirectX API，而是实现DirectX DDI（设备驱动程序接口）。 DDI用户模式应用程序Direct3D 11（d3d11.dll）用户模式驱动程序（DDI）DXGI（dxgi.dll）内核模式内核模式驱动程序硬件/虚拟化 在Windows中，应用程序与系统Direct3D和DXGI库进行通信。d3d11.dll（以及以前的版本）执行复杂的状态跟踪，并向实现DDI的用户模式驱动程序（UMD）发送更干净的命令流。应用程序还与dxgi.dll通信以初始化图形适配器，设置交换链等。UMD还通过DXGI与内核模式驱动程序（KMD）进行通信。KMD由图形供应商（我们）实现，以驱动实际的硬件（或在我们的案例中是虚拟硬件）。对于Wine，我们实现了一个自定义的d3d11.dll和dxgi.dll以拦截API调用，而现在对于Windows，我们需要实现UMD和KMD。 所以这就是挑战：实现UMD与DirectX DDI接口，并且还与KMD设置一个私有接口，与VirtIO设备进行通信。幸运的是，我们的第二部分已经得到解决。anonymix007和arehnman都在独立地为Venus（Vulkan）工作。由于Vulkan是一个完全独立的图形API，因此它不需要实现DirectX DDI，而它的UMD与“替换d3d11.dll”的方法相似，因为它直接与KMD交谈，以驱动命令到QEMU。由于Neptune是基于Venus建模的，因此高层次的内核接口（DMA、命令缓冲区等）非常相似，UMD与KMD之间的接口是完全相同的。最终，我们选择使用anonymix007的分支作为基础，因为他们的实现具有更多在KMD方面工作的功能。 这让我们面临困难的部分。我们必须实现DirectX 11的DDI。当你在设计一个新系统时，了解前人如何解决类似问题总是明智的。不幸的是，开放源代码的DDI实现不多，值得借鉴。Windows图形驱动程序是一个非常小众的话题，而大多数专家在为少数几家图形硬件供应商工作。这也是QEMU在Windows GPU加速方面从未走得很远的原因之一。幸运的是，我们有两个可以学习的开放源代码实现。首先，Mesa有一个DirectX 10的UMD。如果你没有阅读上一篇文章，简短的说法是Mesa在Linux上实现OpenGL。Mesa对OpenGL进行状态跟踪，并发出Gallium API调用。