概要
- Neptune は、VirtIO向けDirect3Dプロトコル転送レイヤーの紹介
- Triton は、Windowsゲスト用の新しいDirectX 11対応仮想GPUドライバー
- Wineや従来方式よりも 高性能かつ互換性重視 の設計
- DDI（Device Driver Interface）実装の意義と難しさの解説
- DXBC（DirectX Byte Code）ハンドリングの課題と工夫
NeptuneとTritonによるWindowsゲスト向けDirectX 11仮想GPU加速
- Neptune は、Direct3D APIコールを仮想化境界を越えて シリアライズ するプロトコルレイヤー
- WineゲームをLinuxゲスト・Linuxホスト間で高速動作
- ただし、真の目的は Windowsゲスト向けグラフィックス加速
- Triton は、Windowsゲスト用の新規DirectX 11対応ドライバー
- QEMU仮想マシンで フルDirectX 11サポート を実現
- Neptuneと連携して動作
- 従来の d3d11.dll/dxgi.dll差し替え方式 の限界
- パフォーマンス低下（DWMによるCPUコピーが発生）
- システムDLLの置き換えは困難・非互換やアンチチート検出の問題
- アプリケーションごとにファイルコピーが必要で ユーザビリティ低下
- 正しいアプローチ はDirectX API実装ではなくDDI（Device Driver Interface）実装
- ユーザーモードドライバー（UMD）とカーネルモードドライバー（KMD）の分担
- UMDはDDIを実装し、KMDと通信してVirtIOデバイスを操作
WindowsグラフィックスDDI実装の課題と参考事例
- Mesa DirectX 10 UMD の活用
- MesaはOpenGL向けだが、DirectX 10 UMDも存在
- Gallium APIを介して各種バックエンド（AMD, Intel, VirGL等）に変換
- macOS向けVirGL機能不足のため直接利用は困難だが、統合例として参考
- VirtualBox DirectX 11 UMD の検討
- DDIコールを中間バイトコードに変換し、ホストでDirectX APIに再変換
- 互換性・保守性・ライセンス問題（GPLv3 vs MIT/LGPLv2）で採用見送り
- 実装済みDDIプロトタイプリストやDXBC署名アルゴリズムの知見を活用
Triton方式の特徴とメリット
- DDI→API変換 アプローチ
- UMDでDDIコールをDirectX APIコールに逆変換
- Neptuneプロトコルをそのまま利用できるため、新たなシリアライズ手法不要
- ホスト側で追加のインタープリタ不要、 変換ステップ削減による低遅延・高信頼性
- D3D11の多くのDDIコールはAPIコールと1対1対応、実装が容易
DXBC（DirectX Byte Code）ハンドリングの工夫
- DXBCはDirectXシェーダーコンパイラ（FXC）が出力する中間コード
- Tritonは DDI→API変換 のため、バイトコード自体は変換不要
- ただし、DDIではDXContainer全体ではなくバイトコード部分のみ受け取るため
- 必要なメタデータを バイトコードから再構築 する処理が必要
- 試行錯誤とAI支援で対応、ここが実装上最もエラーが起こりやすい部分
NeptuneとTritonによる仮想GPUレンダリングの流れ
- アプリケーションがDirectX/DXGI APIコールを発行
- システムライブラリがTritonのDDIコールを呼び出し
- TritonがDXBCバイトコードをDXContainerに再構築し、NeptuneにAPIコール
- Neptune UMDがAPIコールをシリアライズし、KMD経由でVirtIOコマンドをホストへ
- QEMUホストがコマンドをvirglrendererに渡し、NeptuneホストがAPIコールをデシリアライズ
- ホストDirectX実装がフレームをレンダリング
まとめ
- Triton＋Neptune により、QEMU上Windowsゲストで 高性能なDirectX 11仮想GPU を実現
- DDI実装＋API変換方式で、従来のDLL差し替えや中間バイトコード方式よりも 互換性・パフォーマンス・保守性 に優れる
- DXBC再構築など難所もあるが、オープンソース知見やAI活用で克服
- 今後もさらなる互換性強化と最適化が期待される