試験運用中なLinux備忘録・旧記事

はてなダイアリーで公開していた2007年5月-2015年3月の記事を保存しています。

GNU/LinuxネイティブのDirect3D 9を使えるようにするgallium nineと関連メモ(CSMT,Wine Staging)跡地

(2019/9/29)本記事は「GNU/LinuxネイティブのDirect3D 9を実装したGallium Nineとその使い方」へ移動した。

以下、以前の内容となる。

「gallium nine」と呼ばれるソフトウェアが一部で注目されている。

gallium nineについて

これはGNU/Linuxで自由なソフトウェアのグラフィックドライバ使用時にDirect3D 9がOSネイティブな描画APIとしてWine上のWindowsアプリケーションなどのDirect3D 9を利用するプログラムから利用できるようにするもの。
自由なソフトウェアのグラフィックドライバではGallium3D(もしくはGallium)と呼ばれる3Dグラフィックの枠組みが用いられるが、「gallium nine」はこの中の「state tracker」と呼ばれる種類のモジュールとしてGallium使用時にDirect3D 9を描画APIとして用いることを可能にする。
ファイルとしては「d3dadapter9」と呼ばれるライブラリの形をとり、これをWineなどのソフトウェアから利用するためのヘッダファイル群*1と、state trackerとして(libdrmやLLVMなどのライブラリを用いて)Direct3D 9の機能を提供する共有オブジェクト(d3dadapter9.so.[数字])*2から成る。

gallium nineの利点と欠点

利点
Wineは既にDirectX 9cを実装しているが、Direct3DについてはOpenGLを用いて実装されており、Direct3Dの描画命令を実行するためには処理コストが余計にかかる。
gallium nineは、WineのDirect3D 9(OpenGLを用いた実装)と比べるとOpenGLを経由しない分処理コストが少ない関係で高速に動作する場合が多い。
どの程度高速化されるかはグラフィックドライバ(Galliumのドライバ部分,libdrm,カーネルのDRMモジュールといったプログラム)やGPUによるが、特に、高性能なGPUの使用時には大きな差が出るようだ。Windows上より速くなるかどうかはそれぞれのOSのグラフィックドライバなどによる。
動作速度があまり向上しないケースでもCPUの処理量が減るのは間違いないため、CPU使用率が減ってわずかに省電力になる場合もある。
下はDirect3D 9の描画処理の大まかな流れを比較した図。 
(WineでDirect3D 9アプリケーションを動かす際の描画処理の流れ)
Wine/d3d9 -[Direct3D 9命令]-> Wine/wined3d(OpenGLを用いてその都度実行) -[OpenGL命令]-> libGL -> Galliumドライバ -> 低レベルドライバ(libdrmやDRMカーネルモジュール) -> GPU

(gallium nineを用いた際の描画処理の流れ)
Wine/d3d9(命令をそのまま渡す) -[Direct3D 9命令]-> d3dadapter9 -> Galliumドライバ -> 低レベルドライバ(libdrmやDRMカーネルモジュール) -> GPU

シェーダ処理については、WineのDirect3D(wined3d)では

  • GLSL(既定値)
  • OpenGL拡張のARB_vertex_program/ARB_fragment_program(GLSL無効時・非推奨)

のいずれかを用いる形で実装されているが、これらは自由なソフトウェアのグラフィックドライバ使用時は一旦GalliumのTGSI(TG Shader Infrastructure)と呼ばれる抽象化された表現に変換されてから(各GPU向けのGalliumドライバを経由して)実行される。gallium nineからシェーダを用いる際には上記のいずれかを経由せずに直接TGSIへ変換されるため、それよりも処理コストが削減される。

(WineでDirect3D 9アプリケーションを動かす際のシェーダ処理の流れ)
Wine/d3d9 -[Direct3D 9命令]-> Wine/wined3d(GLSL or GL拡張としてその都度実行) -[GLSL or GL拡張]-> libGL(TGSIに変換) -[TGSI]-> Galliumドライバ -> 低レベルドライバ(libdrmやDRMカーネルモジュール) -> GPU

(gallium nineを用いた際のシェーダ処理の流れ)
Wine/d3d9 -[Direct3D 9命令]-> d3dadapter9(TGSIに変換) -[TGSI]-> Galliumドライバ -> 低レベルドライバ(libdrmやDRMカーネルモジュール) -> GPU

欠点
  • 2015å¹´1月時点ではDirect3D 9専用・ただし、プロジェクトのサイトによると別のバージョンに向けた対応の可能性もあり、特にDirect3D 8は将来対応する可能性が高い*3
  • 2015å¹´1月時点のプロプライエタリなグラフィックドライバ(GPUメーカー提供の、自由でないドライバ)はGalliumの構造に合っていないため、プロプライエタリドライバでは利用できない
  • 2015å¹´1月時点ではまだ完成度が低く、動作するプログラムは非常に良好に動作する一方で、まともに動作しないプログラムも多い
  • Wineで利用するためにはWineへの修正が必要で、2015å¹´1月時点では公式のWineでは未対応*4・更に、古い安定版のWineでは利用できない(バージョン1.8が出れば安定版で利用できる)

これまでの開発

最初に話題になったのは2013年夏、Mesaのメーリングリストへの投稿のときだった。
2014年春まではこのときの開発リポジトリで開発が続いていたが、その後は新しい派生リポジトリに移って活発に開発が行われるようになった。

更に、Mesaの公式のソースツリーに取り込んでもらうよう働きかける動きも進んで、バージョン10.4では初めて公式のリリースの中に含まれることになった。
ビルドの際にconfigureスクリプトへオプション--enable-nineを付けることで比較的簡単に導入できるようになっているが、ディストリによってはMesa 10.4のパッケージでgallium nineは無効(既定値)のままとなっていて利用できない。
Mesa 10.4のgallium nineもまだ完成度は低く、開発が続けられる一方で、Mesa 10.4が出た後の修正についても公式のソースツリーに取り込んでもらう動きが続いており、2015/1/23(GMT表記では22日となる時刻)には50ものパッチが新しく取り込まれた。Mesa 10.5ではその改善も入る見通し。*5
Wineへの修正については、公式のソースツリーへの取り込みはまだ行われておらず、見通しについても不明*6。

å°Žå…¥

プロジェクトサイトのインストールに関するページでディストリごとの導入について書かれている。詳しくはここでは扱わない。
「DRI2よりもDRI3を用いたほうが高速に動作する」とされているが、DRI3の使用は必須ではなく、DRI2環境でもWineでgallium nineが使えるようになっている(「DRI2 fallback」という機能)。*7
2015年1月時点では、X11で「xf86-video-ati」ドライバ*8を使用している場合、DRI3を用いるには同プロジェクトが提供する「xf86-video-ati」パッケージが必要。gallium nineの動作テストと不具合報告を行う目的で使う場合は、これは用いずにDRI2環境を用いたほうがよい(不具合原因の切り分けの都合)。

有効化/無効化の設定

以前はレジストリの値を手動で設定する必要があったが、2015年1月時点(バージョン1.7.34)の修正済みのWineではGUIツールwinecfgで「画面」タブに設定項目があり、チェックを入れた状態でDirect3D 9アプリケーションを使用したときにgallium nineが使われる(チェックを外すと従来のOpenGLを用いた実装で動作する)。

動作テスト

テストにはWindowsのDirectX 診断ツール(dxdiag)が便利で、winetricksの「dxdiag」パッケージをインストールするのが楽。
インストールしたら、Wine内の「dxdiag」コマンドを実行する。 
(テスト時にフルスクリーンで動作)
$ WINEPREFIX=[Wine環境の場所] wine dxdiag

(1024x768の仮想デスクトップのウィンドウ内で動作・テスト時にはウィンドウサイズが変わる)
$ WINEPREFIX=[Wine環境の場所] wine explorer /desktop=dxdiag,1024x768 dxdiag

「ディスプレイ」タブの「Direct3D のテスト」を押すと3つ目のテストでDirect3D 9が使われるので、ここで前述のチェックが入っているとGNU/LinuxネイティブのDirect3D 9が使われる。回転する立方体の描画だけを見ても違いは分からないが、GNU/LinuxネイティブのDirect3D 9が使われているときには端末には色の付いたメッセージが表示される(プログラム起動時など、描画処理以外で表示される場面もある)。
ここまでに問題がなければ導入に成功していることになる。

関連:Wine上のDirect3DやDirectDrawのCSMTによる高速化

gallium nineとは別に「CSMT (Commandstream multithreading)*9」と呼ばれる手法(OpenGL命令の実行の別スレッド化)によりWineのDirect3D(Wineが対応する全てのバージョン)やDirectDrawの動作が高速化する場合があり、プロプライエタリドライバでも恩恵が受けられる。*10こちらも、2015年1月時点ではまだ公式のWineのソースツリーには入っていない*11が、まだ公式のソースツリーに取り込まれていない修正(実験的なものを含む)を適用したバージョンを多くのディストリ向けに提供することでテスト・評価などを行いやすくして、これらを取り入れてもらう流れやコードの品質をよりよくする目的で運用されている「Wine Staging」プロジェクト(www.wine-staging.com)*12が提供しているパッケージを導入することで試すことができる。
CSMTの有効/無効の切り替えについてもwinecfgで可能となっており、バージョン1.7.34の時点では「Staging」タブのCSMTに関する設定項目にチェックを入れることで有効にできる。

*1:修正されたWineなど、これを利用する側のソフトウェアのビルド時に使用

*2:利用する側のソフトウェアのビルド時と実行時の両方で使用

*3:Direct3D 10以上は過去にstate trackerとしての実装が存在した時期があり(ただし実用的ではなくライブラリもなく、実際はほとんど使われなかった)、2015年1月時点では消えているものの、将来需要が高まれば、また別の新しいstate trackerとしての実装が登場する可能性はある

*4:UbuntuのPPAで公開している人がいるため、導入自体は楽にできる

*5:その内の大部分は10.4系にも適用され、バージョン10.4.3で利用できる

*6:こちらも適用済みバージョンをUbuntuのPPAで公開している人がいるため、導入自体は楽にできる

*7:以前はDRI2かDRI3の片方にしか対応できず、注意が必要だった

*8:Device Dependent X (DDX) driverという類のX11用ドライバ

*9:「d3dstream」と呼ばれることもある

*10:また、有効にすることで描画の不具合が出る場合や、逆に既存の描画の不具合の回避になる場合もあるようだ

*11:将来的には確実に取り込まれる見通し

*12:Silverlight(DRM有りの動画の視聴含む)やUnity3DなどのWindows向けブラウザプラグインをGNU/LinuxのWebブラウザで動かすPipelightからも使われる・Pipelightについては機会があれば記事として詳しく扱う