Intel オープンソースグラフィックドライバの今後

Intel ドライバの開発者?の Keith Packard 氏の Sharpening the Intel Driver Focus というブログ投稿記事が Phoronix で取り上げられていたのを見て翻訳してみました。自分にはテクニカルすぎてほとんど理解不能、誤訳も多々あろうかと思いますが、ドライバのこれまでの開発と今後の流れがなんとなくわかって面白しろかったので。

Ubuntu Jaunty 9.04 では混乱状況ですが、ようは今までのオプションが今後廃止されて、KMS + GEM + UXA + DRI2 という1つの組み合わせに収斂するシンプルで快適な薔薇色の未来を約束するからもう少し耐えろってことみたいです。^^

追記:この開発者の記事も踏まえたうえで、専門知識のある方が日本語で噛み砕いた説明をされてる投稿記事がありました。


2009年4月24日
今週、Intelドライバの09年度第一四半期のリリースを完了。

今期に最も注力したのは、新しく導入した機能などの安定化であり、深刻なバグの修正に集中したり、できるだけ多くの組み合わせをテストしてきた。昨年の一年ほどの間、自分たちは新しい手法のメモリ管理やセッティング・モード、ユーザー空間とカーネルとのコミュニケーションなどを追加して、ドライバを再構築することに追われた。

こうした変更のすべては複数のプロジェクト(X/Mesa/Linux)にまたがるため、あらゆる組み合わせに対応しているか確認に努めた。

というわけで、どのようなオプションがあるのか見てみよう。:

モード・セッティング(Mode Setting)

1. ユーザー・モード

ドライバ・スタックの出力側すべて、つまり、出力の検知、モニタの検知、EDID 解析等々のすべてがユーザー・モードに。

これには非常に制限があって、最悪なのは、何が起きているのかカーネル側には判らないということ。したがって、X サーバがディスプレイの制御を放棄するまでカーネル・メッセージが表示できない。具体的には、パニック・メッセージがユーザーに届かず、X サーバがクラッシュした場合、ユーザーはマシンの再起動に見舞われる。

もう少し細かい制限としては、ドライバが割り込みに対処できない点が挙げられる。 そのため、これまでホット・プラグのモニタに対応していなかった。 ホットプラグのプロジェクタへの対応を求める声や、マシンからビデオケーブルが抜かれたときにドライバの介入を要する DisplayPort を含むシステムの始動の点からも、これは重要になってきている。

2. カーネル・モード

コードのすべてがカーネルに移動。DRIインタフェイスの一部として公開されるとともに、フレームバッファ・コンソールまたはその他のフレームバッファ・アプリケーションに使用されるフレーム・バッファAPIを通じても公開される。これには多くの便益があるけれども、開発環境がユーザー・モードとは完全に異なってしまい、コードの移植は結構な作業となる。Dave Airlie は、必要なカーネルAPIの適切なユーザーモード・エミュレーションでカーネル・モード・セッティング(KMS)コードを再コンパイルすることによりコードをユーザー・モードで実行させる、という件について途方もないアイデアをいくつか持っている。

ダイレクト・レンダリング(Direct Rendering)

1. 無し

このモードの場合、システムはダイレクト・レンダリングをまったくサポートしない。したがって、レンダリングはすべて X サーバを通らなければならない。GLコールは基本的に X サーバ内にソフトウェア・ラスタライザとして実装される。

2. DRI1

このモードの場合、アプリケーションは単一の front/back/depth/stencil バッファ・セットへのアクセスを共有する。アプリはそれらのウィンドウが占有する各バッファのサブセットに対してすべての描画操作が確実に切り出されるようにしなければならない。 各アプリは、各バッファの適切な領域からコンテンツをコピーすることによって、自身のバッファのスワップを行う。Xサーバとの同期は信号と共有メモリ・バッファを通じて行われる。なにがしかのアプリが実行中の間は、たとえ衝突が生じない場合であったとしても、ハードウェアからその他のアプリケーションすべてが締め出されてしまう。

3. DRI2

このモードでは、それぞれ専用の back/depth/stencil バッファが与えられる。カーネルが各オブジェクトへのアクセスに介在するため、締め出しに見舞われることなく描画。各ウィンドウの実際の front バッファはウィンドウ・システムに所有される。したがって、そのバッファに描き込む要求は、ウィンドウ・システムAPI を通じて指示される。Xウィンドウ・システムの場合は、そのとき DRI2 を使用。アプリがその front バッファへの描き込みを要求すると擬似バッファが割り当てられる。それは、実 front バッファへのコピーが適切な同期ポイントで自動的に行われることを除き、ほぼ back バッファと同様に行われる。

メモリ管理(Memory Management)

1. Xサーバ+旧スタイルの DRI

このモードの場合、Xサーバは固定のメモリ量を要求する。このメモリ量はグラフィック・アパーチャに不変的に結びつけられて、別個のグラフィックカード上のメモリのように扱われる。 Xサーバはこの固定プールからピクスマップを割り当て、それを使い切ると、通常の仮想メモリを使用する。アパーチャと仮想メモリとの間でオブジェクトをコピーすることで、出し入れの移動をする可能性がある。

このモードではダイレクト・レンダリングもサポートする。ダイレクト・レンダリング・アプリケーションが DRI1 のロック(上述したことを覚えてる?)を保持している間、そのアプリはXサーバによって与えられるアパーチャ内のエリアに対して独占的なアクセス権を有する。 このエリア用のページは(Xサーバによって)静的に割り当てられる。アプリが DRI1 ロックを失うと、そうしたページに保管されたデータの一部または全部が弾き出される可能性があり、アプリはそのため、通知のないデータ消失に備える必要がある。GPUによって書かれたのでは(一般的に)なくアプリによって生成された、テクスチャや頂点リストのようなデータに対して、このモードは非常にうまく働く。アプリはすでにデータのコピーを有し、消失時に再アップロードできるわけなので。

2. GEM(Graphics Execution Manager)

この場合、グラフィックシステムによる独占使用のためにページが静的に割り当てられることはない。代わりに、個別のオブジェクト(バッファ・オブジェクト”buffer object”または”bo’s”)が、通常の仮想メモリからページのチャンクとして割り当てられる。これらのオブジェクトは使用されない場合、ページアウトされる。その上さらに、アプリはグラフィック・アーパチャ空間に制限されることはなく、代わりに仮想メモリのシステム・プールから割り当てる。オブジェクトがアプリに使用される場合、カーネルはそれらを動的にグラフィック・アーパチャにマップする。

2D 支援(2D acceleration)

1. 無し

Xサーバは完全なソフトウェア2Dレンダリング・システム(フレーム・バッファ)を有していて、ドライバが何の支援描画メカニズムも提供しない場合、そのソフトウェア・スタックを使用して必要な描画操作のすべてを提供することが可能。これは非常に遅いように思われるが、実際には、ターゲットとなるレンダリング面がキャッシュ・メモリに存在する限り、また wirte-combining ないしは uncached モードのデバイスを通じてアクセスされない限り、そう悪くはない。

2. XAA

これは古い XFree86 レンダリング・アーキテクチャであり、zero-width lines や core text,enven core wide lines や arcs を含んだ”クラシック”なX描画操作に傾注している。スクリーンないしはスクリーン・ピクセル・フォーマットに正確に合致するピクスマップ以外への支援描画はサポートしていない。ピクスマップは、それらがスクリーン上に実際にあるかのように、フレーム・バッファのサブセットから割り当てられる。これは、限られた 2D アドレス能力しか持たない(Intel 8xx-945 や旧型の ATI のような)チップでは、単一の2D割り当て量を越えるメモリを使用することができないため、大きな問題となる。

3. EXA

このコードは KDrive から取り上げられたもので、組み込みXサーバ向けのミニマルなグラフィック支援アーキテクチャとしてデザインされたもの。 ターゲットとなるシステムはグラフィック・アクセラレータが利用できるオフスクリーン・メモリを基本的に持っていなかったので、元々のデザインでは、すべてのピクスマップがシステムメモリに割り当てられた。

加えて、シンプルなハードウェアに素早くXサーバを持ち込むことが目標だったので、支援が効く操作は 2D solid fills(塗りつぶし)と2D blits(データを一方から他方へコピー)のみ。 しかしながら、任意のピクセル・フォーマットでの描画のための統一 API を提供したことは、このコードの1つのキー機能といえる。

このコードはXサーバのコアに移されたため、グラフィックメモリからピクスマップが割り当てられるように変更された。さらに、モダンなアプリケーションがアンチエイリアス・テキストや合成画像に適したパフォーマンスを得られるようにするため、Render エクステンション用の支援が追加された。 だが、支援が効くのはグラフィックメモリに保管されたオブジェクトへのレンダリングだけであり、しかもそのメモリはあらかじめXサーバによって割り当てられていなければならない(上記のメモリ管理の項を参照のこと)。 そのメモリをひと度使い切ってしまうと、何をすればよいのか判断しようとしてXサーバがスタックする。

この1つの問題、すなわち、仮想メモリとグラフィックメモリとの間でいつデータを移動させるか、がここ2年間の EXA の開発の焦点であった。 グラフィックメモリにあるオブジェクトはGPU で最も速く描画され、仮想メモリにあるオブジェクトは CPU でのみ描画可能。ここでキーとなる問題は、グラフィックメモリからデータを読むのは非常に高くつき、そのため、グラフィックメモリから仮想メモリへオブジェクトを移動させるコストが高いということ。 すべてが適切なメモリ空間にあるとき、EXA の実行は速い。それをスラッシングし始めると、EXA の実行は遅くなる。

4. UXA

GPU が任意のメモリに描画できると前提。そして、EXA の基本描画操作は正常であり、(グラフィックメモリに収まる限りは)2Dアプリのサポートの仕事を十分に行うと前提。 UXA はこうした2つの前提の組み合わせから生まれる。GEM が前者を提供し、EXA 描画コードが後者を提供。 ピクスマップは自身のページの小さなセットに止まり、GEM コードが必要に応じてそれらをアパーチャにマップしたりアパーチャからマップするので、ピクスマップは決して動かない。したがって、ピスマップを移動(migration)させる(醜い)コードは UXA に一切必要ない。 つまり、UXA と EXA はスタイルや本質においてそれほど離れた存在ではなくて、GEM の世界では必要のない EXA の一部分を UXA は単純に省略する。

各列から1つ選択

上述の多くの選択肢からそれぞれ独立して選ぶことが可能だ。DRI1 と従来のメモリ管理、XAA とともにユーザーモード・セッティングを使用できるし、DRI1 と GEM、EXA とともにカーネルモード・セッティングを使用することもできる。2 × 3 × 2 × 4 = 48 通りの組み合わせでは、以下が考えられる。

*組み合わせのなかにはうまく一緒に働かないものがある。
*組み合わせのなかにはテストされていないものがある。
*組み合わせのなかにはパフォーマンスのためにチューニングされていないものがある。
*組み合わせのなかには i915 ではうまく働くが 965GM ではうまく働かないものがある。
*965GM でうまく働く組み合わせであっても 855 では働かない。
*あらゆる面で完璧に働く組み合わせは(今のところまだ)ない。

2 年前はかなり少ない選択肢しかなかった。(ユーザーモードのみ、ダイレクトレンダリングは DRI1 または無し、メモリ管理はXサーバのみ、アクセラレーションは無しか XAA、EXA = 12 選択肢。訳注:6 通りのような気が・・・)。そうした時でさえも、XAA と EXA との間の選択ではかなりの議論となった。 EXA はメモリを酷くスラッシュする一方で、XAA はその(小さな)オフスクリーン空間を使い切ってしまうと直ちにピクスマップのアクセラレーションを効率的に無効にしてしまう。

しかしながら、我々が施した変更のなかにはそうした古いオプションでパフォーマンスの減退をもたらしていて、必ずしも喜ばしいものにしてはいない。 古いコードは遅くなり、新しいコードはあらゆるシチュエーションで黄金期を迎えるための用意ができていない。 ここで1つの選択肢となるのが、コードの出荷を取りやめて”完璧な”ドライバを作成する作業を漫然と続けることだ。宇宙が死を迎えた直後にリリースされるために。

代わりに、我々はドライバを出荷し続け、自分たちの検証とともに実地でも働かせて、この相当に重要な新しい世界秩序への移行をなすための手助けをコミュニティに担ってもらえるようにすることを決定した(決定に関してあまり議論しなかったことを自分は認めざるを得ないが)。 だが、実際のユーザーに公開することは、しばしばデザイン上の酷いミスをしていないかどうかを確かめる一番良い方法なので、我々は新しいコードを素早く出す非常に意識的な選択をしたといえる。これには、もし新しいコードが問題を起こした場合、ユーザーはいつでも”古い”コードに切り替えることができるという考えがあった。 もちろん、新しいコードが統合される間に、”古い”コードがかなり重要な変更に対面することがある・・・。

我々の内部の試験者もこの計画に完全に満足しているわけではないことは想像できるだろう。カウントしているバグの数は長期にわたり非常に多く、ここ3カ月を修正作業にだけ費やす一方で、自分の期待よりもかなり多い数がまだ残ってる。

パフォーマンスの違い

上のリストで明らかにパフォーマンスに密接に関係しているのは、2、3 くらいのもの。例えば、XAA を選択すれば Render エクステンション用の支援が効かないためにモダンなアプリケーションに影響が出る。 では一体なぜ EXA から UXA に切り替えるとXサーバのパフォーマンス面に大きな変化が出るのか? UXA や GEM、KMS がまだあらゆるプラットフォームで調整されているわけではないから、というのがその単純な答えだ。

例えば、ハードウェアのレンダリング・パフォーマンスはメモリが描画エンジンによってどのようにアクセスされるかに影響される。 ピクセルのマッピングには”リニア”と”タイル”の2つの方法がある。 リニア・モードでは、ピクセルは各走査線全体にわたる連続したアドレスに保管され、 その後に続く走査線はそれより高位のアドレスに保管される。シンプルなプラン、そしてXサーバのすべてのソフトウェア・レンダリング・コードはこのモデルを前提としている。 タイル・モードでは、スクリーンの矩形チャンクがメモリの近接域に保管される。インテルのハードウェアでは 128×8 ピクセルが”X タイル”を形成する。 このモードの垂直方向に近接するピクセルへの描画は、リニア・モードと比較して PTE(Page Table Entry) のスラッシングを減らしつつ、同じページにタッチすることを意味する。PTE の数やグラフィック・ハードウェア内のキャッシュが制限されたシステムでは、タイル・モードが非常に大きなパフォーマンスの向上をもたらす。 しかし、すべてをタイルモードとするように並べることは非常に面倒であり、ハードウェアや設定によってはそれに至らず、パフォーマンスの大きな落ち込みを目にすることになる。

同様に、ページを GTT(Graphics Translation Table) へマップしたり GTT からマップすることは、CPU または GPU キャッシュからしばしばコンテンツがフラッシュされることを必要とする。 GPU キャッシュのフラッシュはチープではないのだが、それを始終行わざるを得ない。なぜなら、レンダリング・コンテンツがスクリーン上に見えるように保証される方法がそれだからだ。 他方で、PCI 越しのすべての I/O 操作と CPU コア間のコミュニケーションはキャッシュ・コヒーレントであるため、CPU キャッシュのフラッシュは決してしてはならないと”されている”ものだ。GPUはこれに当てはまらない。つまり、これをせざるを得ないというときは常に、相当ひどく遅い CPU 上の道を使用せざるを得ないということになる。 UXA は描画時においてキャッシュをフラッシュする道に至ることはないはずなのだが、依然としてそれが時々生じる。 そのため、UXA のパフォーマンス・ロスが起こってしまうことがある。一方でオブジェクトを GTTへ動的にマップするのに失敗するということは、いくつかのオブジェクトがフィットしないということを意味するので、EXA はデータをコピーして回るのに相当な時間を費やす。この場合、EXA は悪影響を受ける。

DRI1 と DRI2 でのパフォーマンスの違いは、DRI2 アプリケーションから ”実” front バッファを持つXサーバへのバッファ・スワップ・コマンドを得るのに必要なコンテキスト・スイッチに因る部分がある。 glxgears のようなほとんど何も描画せずにほとんどの時間を消去とスワップに費やすアプリケーションにとっては、そのインパクトは大きいものとなり得る(注 glxgears はベンチマークではなく、これは数多くの理由の1つにすぎない)。他方で、占有の back バッファを持つということは、部分的に隠されたアプリケーションは速く描画を行うことを意味し、メインのレンダリング・ループで矩形のクリップをループする必要がない。

ここで明らかなのは、アプリケーションのパフォーマンスがこうした図の全体に及んでいるという状況に我々は立っていて、しかもそれがハードウェア・プラットホームや選択された設定オプションの特定のセットに依存しているということだ。

トンネルの先の光明

良いニュースなのは、自分たちの再デザイン作業が今や完了して、グローバルなグラフィック・メモリ管理やカーネルモード・セッティング、各ウィンドウごとの 3D バッファといった、システム全体に渡って配置したいアーキテクチャを持つに至ったということ。 これは、ドライバに新たなコードを追加する割合が、ほとんどゼロにまで劇的に減少したことを意味する。 ゆくゆくは、この”完璧”な組み合わせが時間の経過とともにより安定的に、より速く、より良く動くことをユーザーは期待するだろう。

現在のところ、自分たちはコードの安定化やバグ修正にすべての時間を費やしている。 この仕事の中でマイナーではあるものの重要なのが、UXA を GEM なしで実行させて、古いカーネルで EXA のようなパフォーマンスが得られるようにすること。 これは非常に容易なはず。 なぜなら UXA は基本的な EXA アクセラレーション・コードと同じものをすべて共有しているし、EXA ピクスマップの移動(migration)関連は、最もシンプルな方法(描画時にGPUに移動、メモリ圧迫状態時にだけ退出)で一番良く働くけれども、そうしたことは UXA 下にすでに存在する GEM エミュレーション・レイヤに提供可能だからだ。

自分たちの全体的な計画は「ただ唯一の設定」に注力すること。 そのためには、唯一の設定に到達するまで、サポートするオプション設定の数を減らしていくことが一番良い。 まず最初にその台に上るのは、XAA と EXA だ。 XAA はもはや誰も使用する必要のないものだし、EXA にしても我々に不要なピクスマップ管理周りを UXA に加えただけのものなのだから。 パフォーマンス関連の隠れた様々なバグが修正されれば、EXA よりも UXA の方が遅くなる理由はどこにも存在しない。

それと同時に、DRI1 サポートも削除される。自分たちは DRI1 下においてコンポジット・マネージャをサポートすることはできないし、フレームバッファ・リサイズやその他の新しい機能のホストをサポートすることもできない。 たとえ DRI1 なしであっても、支援が効いた OpenGL が利用できないだけであって、デスクトップは依然として利用できる。 カーネルやXサーバにおける必要なインフラストラクチャはすでにリリースされているので、コードの大きな束を切り落とす丁度良い時のように見える。

この作業の当初測定が示すところでは、コードベースは10%ほど小さくなる。

そして次の四半期リリースの先には、ユーザーモード・セッティングに関わるコードが残りの”レガシー”部分となる。 2D ドライバにおけるコードの半分ほどがこれに関連しているので、これを取り除くとコードベースがかなり減らせることになる。 この予測に自分たちがどれほど興奮しているかは想像してもらうしかない。

目標は、今あるドライバを手に取って、次の数リリース内にリニアにより速くより安定的なドライバをプロデュースすることにある。

広告

1件のコメント »

  1. Johnd659 said

    Just wanna remark on couple of general issues, The web site style is perfect, the subject matter is rattling excellent dggdfaekkkek

RSS feed for comments on this post · TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。