Gallium3D は Linux で期待される新しい仕組みとして他のプロジェクトと並んで時々名前が出てくるんですけど、Wiki 読んでも、開発元の Tungsten Graphics 社のページを読んでも自分には技術的すぎて理解不能。
ただ、この記事やこの記事からするとグラフィックカードの完全仮想化のキーとなる機能を提供するみたいで、開発元が VMware 社によって昨年買収されたのもなるほどという感じ。Mesa3D や TTM メモリ管理マネージャの開発にも携わってるらしく、Linux のグラフィックス周りの中核を担っているみたい。
OpenCL などを通じて GPU を汎用目的にも使用しようという最近の流れからすると、仮想環境からでも GPU を使い倒せるようにするってのは重要になってきていてるんでしょうか？ まぁ、それに役立つのが Gallium3D と一応思っておくことにして、もうちょっと具体的かつ技術的すぎない解説はないのかと探した結果、とりあえず翻訳してみたのが以下の Phoronix フォーラムでの投稿です。
自分は単なる一般デスクトップユーザーで誤訳があるかもわからんですし、原文を書いた人も専門家じゃないみたい？なので、色々間違ってる可能性がありますが、どうやら Gallium3D はその名前が示すようにまず既存の 3D ハードウェア支援に関わっている DRI ドライバ、具体的には libgl1-mesa-dri や libdrm2 や libdrm-intel1 のようなパッケージと将来的に置き換わるのかな、という印象。また、現在 intel や radeon ドライバに組み込まれている 2D 支援（EXA など）に関してもその対象に入ってくる。
KMS や GEM(TTM)、DRI2 という新しい仕組みの導入は、「Intel の統合グラフィックでも Compiz 稼働のデスクトップで glxgears のウィンドウを正常に動かしたり、google earth が正常に描画されるようになったぞ、ヤッホー！」というような話だけで終わらずに、Gallium3D の土台でもある感じでしょうか。
原文：http://phoronix.com/forums/showpost.php?p=64958&postcount=14
古い方式（現在の主流の方式）
Linux のビデオ・ドライバは非常に入り組んだ状態。
X というのは、ビデオ・カードがフレームバッファとイコールでしかなかった時代に成長してきたもの。
フレームバッファというのは、データが単純に書き出されるメモリ領域のことを言い、ビデオ・カードがそのデータをディスプレイに書き込む。
非常に速くビデオ・カードに直接アクセスする方法だが、アクセラレーションはない。
時が経ち、ディスプレイの数々のアクセラレーティングが試み始められて、そうした機能を提供する新しいドライバが現れてきた。
現在のところ、１つのビデオ・カードを動かすのに複数のドライバを利用する状態になっている。以下はその典型。:
1. VGA または フレームバッファ・ドライバ — カーネル・ドライバ
端末アクセスを提供。つまり X ウィンドウを利用していない時に、カーネル内蔵の VGA またはフレームバッファ・ドライバを使用してディスプレイに表示する。
2. Xorg DDX — ユーザースペース・ドライバ
2D アクセラレーションやその他の機能を提供。
DDX というのは「Device Dependent X」の略。（X のデバイス依存部分）
Xorg ドライバは Linux とは別に開発されていて、ハードウェアに直接アクセスする独自の方法を持っているとともに、Linux カーネルの外側にある PCI レジスタやその他の危険な部分を触れ回る。
例えば EXA と XAA がある。XAA は 2D 支援の古い方法で、EXA はそれより概ね良く働く新しい方法。
現在のところ両者は Linux で利用され、大抵の DDX が両方の API をサポートし、どちらか一方がデフォルトになっている。
DDX は、モード設定（解像度や出力ディスプレイの設定）や、ある程度の動画再生支援等々も提供。
ちなみに DIX、Device Independent X（X のデバイス非依存部分）は、X ライブラリのような、ハードウェア・ドライバ構成部分以外のすべての部分を指す。
3. DRM ドライバ — カーネル・ドライバ
Linux の DRM ドライバは、ビデオ・カードへの制御されたアクセスを提供するためのカーネル内蔵ドライバ。
DRM は「Direct Rendering Management」の略。
Linux DRM は、DRI と呼ばれる安定的なユーザースペースの API/ABI を実装していて、それを通じてビデオ・ドライバはハードウェアと交信できる。
4. DRI ドライバ – ユーザースペース・ドライバ
DRI ドライバは、Mesa の数々のアクセラレーションにより構築される OpenGL ハードウェア支援ドライバであり、DRI プロトコルと Linux DRM ドライバを通じてハードウェアと交信する。「Direct Rendering Infrastracture」
Mesa は、ディストリビューションその他のオープンソース関連によって提供されるデフォルトの OpenGL スタック。
OpenGL 自体は 3D アプリケーション・プログラミングのための広範な汎用 API であり、ハードウェアからはほとんど独立していて、ハードウェア支援が効く場合もあれば効かない場合もある。ハードウェアと密接に結びついている DirectX とは非常に異なり、OpenGL の場合、常にハードウェア支援されるのは API の一部のみ。
一般向けレベルのビデオカードではビデオゲームなどに使用される部分の API だけをアクセラレートして、専門向けレベルのビデオカードではそれよりももう少し範囲が広くなる傾向。
基本的にベンダー等は Mesa を利用し、出来るだけハードウェアでアクセラレーティングさせることを通じて、DRI ドライバを開発。
ダメダメ
バラバラなやり方でこうした様々なドライバが強制的に協働させられるというのが、程度の差こそあれ、この全体の各仕組みの動作の仕方。
それら全てが違う人たちや別々のプロジェクト（Xorg, Linux, Mesa）によって開発されてるので、うまく調和せず、単にみなが納得し安定することだけに膨大な時間や努力が費やされてる。
例えば、通常 X.org DDX はディスプレイの自由支配権を与えられているわけだけれども、そのディスプレイに OpenGL アプリケーションが必要になると DDX はフレームバッファにブランクな矩形を描画して、それが DRI ドライバに渡される、といったような具合。
今後の方法
1. Linux DRM ドライバ — カーネルスペース・ドライバ
モード設定のような基底レベルのいくつかの機能が Linux カーネルに移行。
また、Linux カーネルに GEM のようなものが組み込まれて中央集権的なメモリ管理の仕組みができ、Linux カーネルがビデオカード・メモリの制御やビデオ・カードとのデータのページングなどを担う。
従来は各 API がそれぞれ自身のメモリ管理の仕組みを持っていて協働させることを難しくしていたが、デスクトップのコンポジットにはそれが不可欠。
ユーザースペース・ドライバがハードウェアにアクセスできるようにする DRI2 プロトコルの更新版を作成。
2. Gallium3D — ユーザースペース・ドライバ
OpenGL 専用の DRI/DRI2 Mesa ドライバを置き換える新しい DRI2 ドライバ。
古い DRI ユーザースペース・ドライバの場合、各ドライバはハードウェアに特化しすぎたコードを持っていて、１つのドライバでの改善が他のドライバにうまく転換され難い。
従って、Gallium3D ではハードウェア依存コードを隔離させ、なおかつ極力それを小さくするように区分されている。
それとともに、複数の異なる API に対応するように拡張もされる。OpenGL のみならず EXA API や動画再生支援、OpenCL 対応を提供することが可能。
これがつまり新しいモデル。自分は Gallium の内部構造は理解してなくて、ステート・トラッカーが正確には何なのか、ドライバのハードウェア依存部分が何と呼ばれるのか、逆にそうでない部分は何と呼ばれるのか、といったことについて語ることはできないけれど。
このボーナスの１つとして、有用な形式で Gallium が区分されていると、ハードウェアをどんなものにもすることができるため、CPU（すなわちソフトウェア・ドライバ） や CELL、その他に対するアクセスを提供できる。つまるところ、モダンな動画再生支援はもはやハードウェア支援ではない。すべてソフトウェアになる。CPU のみならず、CPU と GPU 両方で実行されるように最適化されたソフトウェアに。
Xorg DDX はどうなる？
Gallium3D が様々な多くの API を提供できるようになると、2D 専用ドライバの保持は余分になる。（言うまでもなく、ほとんどのビデオカード会社が 2D 専用のチップを取り払ってきている。）
また、Linux カーネルが完全にメモリ管理や入力検知、モード設定を引き継ぐとなると Xorg はそうしたことをする必要もなくなる。
従って、X がハードウェアに直接アクセスする理由は実質的に存在しなくなる。
つまり、X サーバは単なるアプリケーションの１つとなり、PCI ビットをいじることはなくなるということ。
ユーザーアカウント下で稼働して、他のアプリケーションと同じ方法でハードウェア支援を利用することになる。
これが一番最善の結果。
VGAやフレームバッファ
自分にはよくわからない。Gallium がそこら辺も提供できるだろうけれど、これに関してはカーネルが個別のドライバを持ちつづけるかもしれない。
他の OS については？
Xorg ドライバ擁護派の論拠の１つは、DDX は OS にほとんど依存していないということ。
直接ビットをいじるので、Linux に特化したコードを扱うようにはなっていない。
すべてが Linux DRM を通すことになると、ドライバが Linux の実行を必要とすることになってしまう。
しかし裏を返すと、DRI2 プロトコルをサポートするに充分スマートなカーネルを他の OS が持ってさえいれば、程度の差こそあれ、同じすべてのハードウェア支援機能に対応できることになる。
Gallium 自体はモジュールなので、既存の Windows または OSX の APIやドライバを使用してアクセラレートする Gallium ドライバをデザインすることも可能だろう。ここら辺のことは、自分には難しすぎるけれども・・・。
