QEMU 終於補上 Windows 3D 加速：Triton 如何把 DirectX 11 帶進 UTM

发布于 2026-07-27 00:06:14（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 8901 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）

11带進UTM original we×x7ce EI V1ajero 2826年7月27日 86:86德国

一直以来,在 Mac 上用 UTH 或 QEMU 敦行 WIndows,真正解的显不是CPU,而是

GPU.现在,UTN 圈除公了一套名為 Triton 的 Windows 示卡显熟程式,配合 Neptune 国形得输族定,旗Windovs 11ARM64虚授第一次可以透通QEMU完整走通 DirectX 11 国形堆叠,

?

墨:x64 盛CCrash Band1coot N.Sane Tr1logy> 执行於 Windows 11 AR54 虚凝据,智 主系统為macOS,置片来源:UTM官方烯客。 如果只看董面,遗似乎只是「QEMU終於能跑3D避越:。但Triton真正重要的地方,不是馆某

一款逊截熟强示出来,而是它遇握徙Windows颤示卡扇数唇解决同题

这意味著 Windows 自己的 DirectX.DXGI、桌面合成器DWM,以及一般藻用程式看到的都是一张 正常的虚损题示卡,而不是某個逊就目操理被愉愉替换的DLL。 这是QEMU Windows圆形虚提化長期缺失的一境拼图 問題來不只是「把置面示出來」 QENU很早就能机提题示装置,Windows也可以在其中顯示桌面。但能顯示桌面,與摇有现代 CPU 加速,是南回事。 傅统的 QEMU W1ndows 虚凝模通常依强基能鳞示驱起、QXL、V1rtI0-GPU 的有限功能,或者直接 由CPU进行敢疆渣染。用录安装系統、操作一般視窗没有同随,但只要应用程式要求DirectX

11.Shader Model 5.0或赖完整的 3D 功能,同显就會立刻出现。

遇去也有人需试把 Wine、DXVK 等票案產生的 d3d11.clLl和cxg1.dlL放造Windows 逝截 目錄,截逝载的 DirectX 呼叫。再博成 VuLkan. 这種方法能旗部分道款的数,部有费回根本缺陷:

1.每個离用程式都要摇放置DLL,無法成為系统级解决方离

2.W1ndows桌面合成器DMM 不會把這些重面管成正常的 GPU共享瓷源,經常需要CPU 额外

3. d3dl1.dll

和cxgi.dL1本来就是Windows核心元件,直接暂换會带来大量相容性同题。

4.逝截反作系统可能把這種DLL注入或替投視為具常行益。

因此,UTH图陈没有耀停留在「替换 D1rectX DLL遭德路,而是决定置作真正的 W1ndows 示卡盟動程式介面。 Triton、Neptune和QEMU,各自負黄什? 整量方案由展国部分组成。它們的名稿很多,但分工其官很清楚。 Triton 是安装在 Windows 虚凝檬性的 DirectX 11 示卡驱动程式。它接收 Windows 国形 系接送給硬耀廠商鉴勤程式的DOI呼叫。 Neptune 是一芒 Direct3D虚凝化像定,负青把 Direct3D API 呼叫序列化,穿遇VirtI0 员 虑澄碳遍界,送到宿主系统。 virglrenderer 位於宿主系统,负青摇收Neptune鑫令,管理不同溢染内容园資源,然後把 Direct3D呼叫交绘真正的富主端谊染後端 DXVK、DXMT 或 D3DMetal 才是最拒命令概拍為Vulkan 或Metal、交给實體GPU 韩行的元 件。 把整條键路摊開,大致如下:

• DirectX 11 / DXGI APIWindows 系统 d3d11.dll, dxgi.dll

windovs 说截或展用程式 复制 所以,道不是把Mac的GPU 直接!直通給W1ndows。W1ndows 虚凝操看到的是一张V1rtI0 虚期示卡;淤截產生的Direct3D斋令被送到缩主系统,再由宿主系純的国形API教行。 遗更接近置形API 通露铁行,而不是傅 PCIe GPU Passthrough. 為什一定要做真正的Windows動程式? Windows 的 DirectX 架桶大致分成三凰。 显上是游感使用的 Direct3D API; 中显是 Windows 自确的 d3d11.dll 和 dxg1.dlL :最 下唇刚是题示卡商提供的使用者模式驱数程式UMD买核心模式驱融程式KMD

一般进截呼a叫 DirectX 11時。d3d11.dLL曹負费状感造蹈,参数验和资源曾理,再把整理過

的DDI命令交鳍示卡驱勤程式。 真正的 NVIDIA、AMD、Intel 勤程式含在遗理把 DDI命令特成硬體措令:Triton 别把它們师 回 Neptune 能期何输的 D1rect3D API, 也就是战,資料在 Windows 理走了一次: Direct3D API - Mindows DI 复制 进入Triton ,又被反向换: Windous DOT ~ Direct3D API 复制 看起来像续了一圈,但遗正是Triton最聘明的般計。 UTN围隧不完要再塗明一套鹿大的虚凝GPU招令集,也不案要在宿主端重新育一DDI解器。 Triton 只要把 DDI 呼叫到回 Direct3D API,就能直接重用已经完成的 Neptune 傅输墨。 VirtualBox 的源DirectX 11鉴勤程式探用另一種方式:先把DDI聘成自己的中限命令格 式。得到宿主端後再解湿回DirectX、这條路可以谨作,但多一屑博换就多一唇相容性凰险,而且 VirtualBox 的 GPLv3 授也不遮合直接整合进 QEMU, Mesa 與virglrenderer 的现有程式 因此,UTM图陈主要把 VirtuaLBox 当成行為参考,用来殖蕊哪些DDI 函式是必要的。以及 Windows實期待驱动程式如何回虑,而不是置接移通其程式础。 最棘手的一關:重新拼回DXBC著色器 DirectX 11 時代的 HLSL 著色错通常鲁被编环成 DXBC, 避藏最初交绵u3d11.dl1的不只有著色翻指令,還有一但完整的DXContainer,其中包含输人 签名、输出签名、省源瓷讯等中瘤瓷料。 周题在於,W1ndows 呼叫示卡辅动程式的 DDI特,遗些中疆囊科已题被D1rect3D Runt1ne 治耗掉了。Triton拿到的往往只剩核心著色器位元码。 但Triton 接下来要重新呼叫宿主端Direct3D API,而宿主端又指待看到完整的 DXContainer。 於是Triton必须分析DXBC指令,推幕出已经逼失的输入、输出签名和其他榴位,再重新组装一 可用的DXContainer。真正的若色器指令可以保持不曼,但外圈结椭必须被里新建立。 这是整個方案理最胞弱的跟的。签名或格式推弹稍有错换,就可能表现為:

• 字型或通示示罐误;

• 红色舆绿色通道交换:

• 粒子效果武常;

• 視窗适明遗失;

• 視窗选明应通失:

• 某些避越著色器编理失败;

• 题示辐动程式亚设,基至演虚摄機盈蛋面。

• 期示驱助程式重设,甚至操虚摄概蓝盖面。

UTN围陈也明硬表示,DXBC容重建是目前實作中最容易出猫、仍需要大量相容性润就的部分。 能跑游還不,Windows桌面合成才是真正的考驗

iajere 显: Windows 11 在 Ubuntu/KVM/QEMU 中航行, DxDiag 已辨噬 Red Hat VirtI0 GPU 3D controller,Direct3D Acceleration 顯示為 Enabled,露片来源:UTM 官方博客。 全量幕遵戴可以示,不代表虚提示卡已翘完整可用。 Windows桌面单不是爆每個愿用程式直接把墨面送到蟹幂。每個程式先在白己的GPU纹理中增裂, 然後交给 Desktop Window Manager,也就是 DWMDwM 再把磨用程式视窗、除影、适明效果、 工作列、游檬和動量合成为最终董面。 这要求虚GPU支援跨程序共享纹理。 例如,激震器程序奎生一张纹理,DWM 程序必须能在另一個 GPU 内容中阴敏同一张紋理,银测 器已经董完,再把它合成进桌面。 因此,Triton/Neptune 不只要傅返继国命令,通必须解決商件事: 共享敏理:同一份GPU董应如何被不同程序、不同染内容,甚至不同宿主端鞋动程序存取。 共享Fence:生者和消资者如何碰到方已經完成 GPU 工作,避免DMM在愿用程式遗盖完時 篇取纹理,遗成新裂、黑帕或半成品董面。 UTN 最初把 Swapchain 遥辑放在宿主,後来登现遗 Windows 的 DXGI、DiM工作方式不 合。最终方案是把 Swapchain 管理移回虚疑機内,旗Windows 和 Neptune 驱勤程式管理背景 疑街區,宿主端只负责匯入、睡出共享资源和最终揭描输出。 这個改融壤架椭更接近 Vulkan 虚提化方案 Venus,也减少了virglrenderer 中事属於 Neptune 的特殊遥辑。 在Linux上相對直接,在macOS上要多走步 Linux 宿主端可以使用 DXVK,把 Direct3D 11 畅成 VuLkan,再交给原生 VuLkan 驱勤程 式。現代 Linux GPU 驱融的 VuLkan 支缓已链相當成。因此遭路相對清楚: nd5 xnuT1 - uey1nA - XAX - TT 05sT0 + sunsdan 复制 macOS 的情况不同Apple 有提供原生 VuLkan 疆数,主力国形 API 是 Metal. UTM 围陈估了三條路. 方案一:DXVK+MoltenVK 这是最直裂的组合: Direct30 11 ~ DxvK ~ vuLkan - MoLtenVK ~ Metal 复制 但每多一唇API翻理,相容性就童受最弱的一限制UTM基账的测实結果是,DXVK 加 MoltenVK可以轨行部分内容,但仍存在程定性阅国形功能缺口,不通合作為目前的主要方案。 方案二:DXMT DXNT 直接把 Direct3D 11 疆成 Metal,省掉 Vulkan MoltenVK: Direct30 11 ~ DXMT ~ Metal 复制 DXNT 原本主要服務 Wine。為了爆它能被 virglrenderer 蓄作原生 macOS 函式摩使用,UTM 圈除摘充了libdat-native.dylib,加人跨程序共享效理、事件和Fence 等介面。 DXMT是用源方案,而且可以原生编深高ARM64,遗對末来盈合进UTM事常重要。 QEMU 3DMARK

8920 Fire Strike 10 143 10 047 4 305

盈:DXMT後端下的F1reStr1ke测试墨面,此可證明完整烈试流程能购胞通,但不同截置未 必使用相司硬赠资测腻段定,不癌只按墨密分数置描比殿。黑片束源:UTM官方语客。 方案三:AppleD3DMetal Apple 的 Gane Porting Toolkit 内含 D3DMetal.framework, 可以把 Direct3D 11. Direct3D 12 直接嵊成 Metal,兼包含 DXBC、DXIL 到 Apple GPU 中間碼的幅器。 D3DNetal 的效能通常侵於目前的DXMT。UTM媒為它鞭作了d3dnetaL-native包装,旗原 本面向 Apple Wine 環境的 D3DMetal可以在一般macOS 程序中使用。循上跨程序共享资源 等能力。 不退,它有两回现宵限制。

第一,D3DMetal.framework 目前只有 x86 64 薇本。在 Apple Silicon 上,联人它

的virgl_render_server 必须透退 Rosetta 2 软行。令人意外的是,即使多了 Rosetta,制 航效能仍然高的原生 ARM54 的 DXMT。

第二,也是更大的周題:Apple 的授權保款限制 D30Metal只能用於在 Apple 品牌品上登、

测或估逝截,而且懂允非商满放布。UTH因此期法直接把D3DMetal打包造正式庭用程式。 QEMU VI 11 534 Fire Strike 14 068 10 035 5 423

:D3DMetaT 下的Fire Strike 源腻蛋面,D30Metal由 x86_64 染程序透返 Rosetta 2敦行。圆片来源:UTM富方博查。 UTN 围隙提到,育業版 CrossOver 可以散布 D3DMetal,據稽是因為 Codeieavers 與 Apple 另有熔。如果UTM未来拿不到频似授框,正式版更可能以開源DXMT為主要macOS後端。 AppLeSiLicon的共享記憶體,也被用来解决跨程序 纹理 virglrenderer 预股量為不同渣染内容敬握立的virg_rencr_scrver程序。遗核做可以展 雕锚损:其固进截或治染器增溃,不至於指均整固虚凝機。 代情是,不同程序不能直接共享一般的MTLTexture物件。 Apple 官方建播的 MTLSharedTexturcHandle 需要 XPC,但 QEMU virglrenderer 原本 大量使用 Unix 榕案描述符和SCNRICHTS博通资源,如果為此把QEMU、virgLrenderer、 SPICE的程序通部全部改造成XPC,工程范室會大幅接张。 目前方案利用AppleSilicon的一記博體架横UMA:

1.使用shn open()建立共享记憶體:

2.把榴案握述符透通5CM_RIGHTS傅給另一個清桑程序;

3.每個程序都把同一段起憶體映射成MTLDutfer:

4.GPU 和CPU因為共享實赠記博,可以看到同一份瓷料。

这個方法的限制是只能方便地建立德性效理,記憶體效率不如GPU最佳化的排列方式。但只要真正需 要跨程序共享的理数量有限,它仍是一因實用的初期方案。 Fence同步也探用频似的折衷。生者GPU在完成绝装後,把時绚综数值意进共享记德疆:消背者 CPU输物胶数值,確超继装已完成後,两提交合成命令。 它可以保铅正確性,但CPU 确现提交等待會需来额外延逻。長期来看,便用XPC和真正 的MTLSharedEventHandLe仍可能是效能亚理想的方向。 效能到了什程度? UTN 的伴髓删登记降公布了一组同一宿主模上的最 Fire Strike 潮腻: 渲梁路径 Fire Strike 分数 Windows 腺握硬 + DXYMT ARH64 5124 windovs 虚+ D3DMctal x85_64/ Rosctta 5682 闵 Linux/ Wine 募考路得 换算後,DXNT大的達到参考路径的67%,D30Metal的为75% 这是一有情值的禁果,但需要正随理解:

• 参考對象是同一台橡器上的 Linux/Wine,不是原生Windows,也不是Parallels,

• Fire Strike 只是單一基测腻,不能代表所有游截。

• 不同道殿的瓶頭可能出现在CPU指令轉辉、著色器、共享紋理、同步、驱勋程式或宿主端

API, ,「测就可以跑完:比單一分数亚重要,因它耀明Direct3D、DkM、共享資源和董面输出已握完 整走通 值得注意的是,UTH的最終测试仍记族到不超通0.8%的需幅率。造已辉比開登初期明葡改善,但也 明整套方案仍處於需要继缅打磨的陪段。 「完整DirectX11不等於所有避都能玩 UTN 官方把Triton描述為益QEMU傅来完整DirectX 11支援。造裸的「完整:,亚適合理解 為DirectX 11疑勤程式架和主要 DDI路径已继打通,而不是一份所有 DirectX 11逝截的 相容性保验。 目前仍有策项明硬限制:

• 核心目标是DirectX 11,亚不代表Windows虚挺機已须得DirectX 12驱勃程式

• macOS後端的共享效理关Fence仍包含效能折表。

• DXBC容器重建可能造成特定老色器相容性開题。

• W1ndows脂前程式仍被官方標记为‘非常不程定:

• 官方特剧警告,不要把测试版疆動安装到任何重要的虚授中。

• 日前需要自行编靠多個分支,還不是UTM正式版程的一但首通用鼠。

• 使用正式显動程式架精可以逾替投 DLL的部分反作瞬同题,但虑凝榜跟境,Windows on

ARM和實验性驱物本身仍可能被核心级反作辨拒能。 另外,官方展示的是x64逝截执行於Windows 11ARM64.造代表游整的CPU 指令還需要由 Windowson ARH 畅,而国形命令再由Triton/Neptune博到宿主强。它榴明整修路径具有相 當强的實用性,但也意味著宵察效能不只取决龄GPU 這不是一個孤立的補丁,而是一整套開源圖形堆叠 Triton 亚不是只繁改一個 QEMU 榴案。公附程式碼分布在多他專案:

• QEMU:加人 Neptune VirtID-GPU 能力與相虚凝示装置;

• virglrenderer:加入 Neptune 蜜主端奥溶染何服器支援;

• Windows UMD: 實作 DirectX 11 DDI Triton 遵辑:

• Windows KMD:管理配恒疆、命令嫌衡區、Fence 和 VirtIO 通讯;

• DXMT:加入原生nacOS函式库和跨程序共享资源:

• 3dmetal-native:把 Apple D3DMetal包装成一般mac0S 程序可便用的後端;

• 動程式础置即本:负费ARM64、ARM64EC、x64疆封装

UTN围隙正在管就把能狗通用化的修改送回上游票案。请一步非常重要:只有显脱大量私人分支,进 人QEMU、Mesa,virgLrenderer 等正式發流程,後绩维摄、浏试與微布才可能真正辑定。 另一個值得注意的部分:大量程式碼由AI完成 原文署名除了UTM發者osy.還包括claude-cpus-4-。伴髓文章波露,Triton的開發大量 使用多 AI 程式设計代理。 公例统計包括:

• 40活灌用日:

• 2,178次使用者据令;

• 豹6,740 离出Token;

• 估算API成本14,768美元;

• 期發者表示,白己次有期手擦高最终程式碼

但这效不是「输入一句提示。AI就自己做出示卡驱数程式。 人验者仍然负舞退握能、拆解同题、我断API合约、客查希票、崭察實胞量面、投计到方 法。以及否决看似合理但實隐锚误的方案。開發记条甚至提到,AI最初座生造一套愚空隐测的DXBC 實作,後来被完整拾案,改为依挑已知可工作的参考實作重寫。 圆形驱劲程式最大的鞋黏之一,是「温面看起束不對:很群直接化為機器可输盗的條件。黑躺、微卡 弧、赖色继联、遗失的桌面圆唇,都密要先建立霍圈、追戏、著色器储印或董面取楼工具,AI才能造

一步定位。

因此,图專案更草確的意兼是:一名熟悉QEMU、Windows显融奥图形架的工程师,利用大量代 理谨算,把原本可能需要数月的實作买除工作整缩到数遇,而不是AI取代了圆形動工程的。 Triton對UTM和QEMU意味著什? 遇去,UTH在 Apple Silicon 上的霍势是源、自由、支援大量架横,也能很好地執行 Windows ARH 和 Linux. 但只要涉及 Windows 3D 医用程式,它翼 Paralel.s Desktop、 Triton證明了這個差距非無法跨越。 它已經完成個關鍵里程碑:

1.WindowS能把VirtI0-GPU當成正常的3D顯示装置;

2.DirectX11DDI可以穿過VirtI0界;

3.WindowSDWM能使用共享GPU紋理完成桌面合成;

4.Linux宿主可以透過DXVK/Vulkan渲染;

5.macOS宿主可以透過DXMT或D3DMetal/Metal渲染;

6.實隙x64避和3DMark可以在WindowS11ARM64虚機中執行。

接下來真正困難的,不再是證明「能不能做到」,而是把它成普通使用者可以長期依赖的產品:

• 建立更廣泛的游相容性資料;

• 修正特定DXBC著色器問题;

• 降低跨程序共享和Fence同步的延;

• 完成穩定的WindowS動章與更新流程;

• 镶修改逐步進入上游;

• 解决D3DMetal的散布授權;

• 最終把整套元件包進UTM正式版本。

Triton最值得重視的地方,不是某一張游截圖,也不是某一個跑分。 它第一次證明:QEMU可以透過一套開源、可跨宿主平台的架構,為WindowS虚凝機提供真正整合 進作業系統的DirectX11顯示卡動程式。 現在的Triton還不適合安装進重要虚機,也不能取代成熟商業產品。但技術路線來看,UTM 已經跨過了「Windows3D加速是否可行的門楹。 剩下的問题,是穩定性、相容性、效能和產品化,而不再是零開始。 對開源虚凝化來,這可能是近年最值得關注的Windows圖形進展之一。

UTM Blog: Introducing Triton: DirectX 11 driver for QEMU UTM Blog: Bringup Notes: Building Triton

https://blog.getutm.app/2026/introducing-neptune-direct3d-virtualization-for-qemu/ UTM QEMU:utm-edition-neptune 分支 https://github.com/utmapp/qemu/tree/utm-edition-neptune UTM virglrenderer:neptune 分支 https://github.com/utmapp/virglrenderer/tree/neptune Windows UMD: virtio-win-mesa/neptune https://github.com/osy/virtio-win-mesa/tree/neptune https://github.com/osy/kvm-guest-drivers-windows/tree/neptune UTM DXMT https://github.com/utmapp/dxmt UTM d3dmetal-native https://github.com/utmapp/d3dmetal-native

原始排版图