ダイレクトレンダリングインフラストラクチャ

ダイレクトレンダリングインフラストラクチャ（DRI ）は、現代のLinuxグラフィックススタックを構成するフレームワークであり、権限のないユーザー空間プログラムが他のプログラムと競合することなくグラフィックスハードウェアにコマンドを発行できるようにします。 ^[6] DRIの主な用途は、OpenGLのMesa実装にハードウェアアクセラレーションを提供することです。DRIは、ディスプレイサーバーを実行せずにフレームバッファーコンソールでOpenGLアクセラレーションを提供するようにも適応されています。^[7]

DRIの実装は、Xサーバーとその関連クライアントライブラリ、Mesa 3D、およびDirect Rendering Managerカーネルサブシステムに分散しています。^[6]ソースコードはすべてオープンソースソフトウェアです。

従来のX Window Systemアーキテクチャでは、X サーバーはグラフィックス ハードウェアに排他的にアクセスできる唯一のプロセスであり、したがって、フレームバッファで実際のレンダリングを行うプロセスです。X クライアントが行うことは、X サーバーと通信してレンダリング コマンドをディスパッチすることだけです。これらのコマンドはハードウェアに依存しません。つまり、X11プロトコルはグラフィックス デバイスを抽象化するAPIを提供するため、X クライアントは基礎となるハードウェアの詳細を知ったり心配したりする必要がありません。ハードウェア固有のコードはすべて、デバイス依存 X 内に存在します。デバイス依存 Xは、各タイプのビデオ カードまたはグラフィックス アダプタを管理する X サーバーの一部であり、ビデオドライバーまたはグラフィックス ドライバーとも呼ばれます。

3D レンダリングの台頭により、このアーキテクチャの限界が明らかになりました。3Dグラフィックス アプリケーションは大量のコマンドとデータを生成する傾向があり、そのすべてをレンダリングのために X サーバーにディスパッチする必要があります。Xクライアントと X サーバー間のプロセス間通信(IPC) の量が増えるにつれて、3D レンダリングのパフォーマンスが低下し、X ドライバー開発者は、最新のグラフィックス カードの 3D ハードウェア機能を活用するには、新しい IPC のないアーキテクチャが必要であると結論付けました。X クライアントは、別のプロセスに頼るのではなく、グラフィックス ハードウェアに直接アクセスして、すべての IPC オーバーヘッドを節約する必要があります。このアプローチは、従来の X アーキテクチャが提供する「間接レンダリング」に対して「直接レンダリング」と呼ばれます。ダイレクト レンダリング インフラストラクチャは、当初、この「直接レンダリング」アプローチを使用して、すべての X クライアントが 3D レンダリングを実行できるようにするために開発されました。

DRI を X クライアント内で高速化された 2D 直接レンダリングの実装に使用することを妨げるものは何もありません。^[3] 2D 間接レンダリングのパフォーマンスが十分に良かったため、そうする必要がなかったのです。

ダイレクトレンダリングインフラストラクチャの基本的なアーキテクチャは、3つの主要なコンポーネントで構成されています。^[8]

• DRI クライアント (たとえば、「直接レンダリング」を実行する X クライアント) には、現在のビデオ カードまたはグラフィックス アダプタを管理してレンダリングできるハードウェア固有の「ドライバ」が必要です。これらのDRI ドライバは通常、クライアントが動的にリンクされる共有ライブラリとして提供されます。DRI は 3D グラフィックス ハードウェアを活用するように考えられたため、ライブラリは通常、3Dハードウェア ベンダー自身またはMesa 3Dフリー ソフトウェアプロジェクトなどのサード パーティによって提供されるOpenGLなどの 3D API のハードウェア アクセラレーション実装としてクライアントに提供されます。
• X サーバーは、DRI クライアントがウィンドウ システムと DDX ドライバーの両方と連携するために使用するX11 プロトコル拡張(DRI 拡張) を提供します。 ^[9] DDX ドライバーの一部として、X サーバー プロセスも DRI クライアントと同じ DRI ドライバーに動的にリンクしますが、これは間接レンダリング用の GLX 拡張を使用してハードウェア アクセラレーションによる 3D レンダリングを X クライアントに提供するためです(たとえば、直接レンダリングを使用できないリモート X クライアント)。2D レンダリングの場合、DDX ドライバーは同じグラフィックス デバイスを使用する DRI クライアントも考慮する必要があります。
• ビデオカードまたはグラフィックアダプタへのアクセスは、 Direct Rendering Manager (DRM)と呼ばれるカーネルコンポーネントによって制御されます。 ^[10] XサーバーのDDXドライバと各XクライアントのDRIドライバは両方とも、グラフィックハードウェアにアクセスするためにDRMを使用する必要があります。DRMは、コマンドキュー、カードレジスタ、ビデオメモリ、DMAエンジンなどのグラフィックハードウェアの共有リソースを同期化し、複数の競合するユーザー空間プロセスの同時アクセスが互いに干渉しないようにします。DRMは、3Dレンダリングを実行するために必要な範囲を超えてXクライアントがハードウェアにアクセスできないようにする基本的なセキュリティエンフォーサとしても機能します。

オリジナルの DRI アーキテクチャでは、当時のビデオ カードのメモリ サイズの関係で、画面のフロント バッファーとバック バッファー(補助的な深度バッファーとステンシル バッファーも) のインスタンスが 1 つしかなく、それがすべての DRI クライアントと X サーバーで共有されていました。^{[11] [12]}それらはすべてバック バッファーに直接レンダリングされ、垂直ブランキング インターバル時にフロント バッファーと交換されました。^[11]バック バッファーにレンダリングするために、DRI プロセスはレンダリングがそのウィンドウ用に予約された領域にクリップされるようにする必要があります。^{[11] [12]}

Xサーバーとの同期は、シグナルとSAREAと呼ばれる共有メモリバッファを介して行われました。[ 12 ] DRMデバイス^へのアクセスは排他的であったため、どのDRIクライアントもレンダリング操作の開始時にデバイスをロックする必要がありました。その間、デバイスの他のユーザー（Xサーバーを含む）はブロックされ、両方の操作に競合がない場合でも、現在のレンダリング操作の終了時にロックが解除されるまで待たなければなりませんでした。^{[12]もう1つの欠点は、現在のDRIプロセスがデバイスのロックを解除した後、操作がメモリ割り当てを保持しないため、}テクスチャなどのグラフィックスメモリにアップロードされたデータは次の操作では失われ、グラフィックスのパフォーマンスに大きな影響を与えることでした。

現在、DRI1 は完全に時代遅れとみなされており、使用することはできません。

Compizのような合成ウィンドウマネージャの人気が高まったため、ダイレクトレンダリングインフラストラクチャを再設計して、X クライアントがダイレクトレンダリング中に「オフスクリーンピックスマップ」へのリダイレクトもサポートできるようにする必要があった。通常の X クライアントは、X サーバーがレンダリングターゲットとして提供する別のピックスマップ (いわゆるオフスクリーンピックスマップ) へのリダイレクトを既に尊重していたが、DRI クライアントは引き続き共有バックバッファに直接レンダリングを行い、合成ウィンドウマネージャを事実上バイパスしていた。^{[11] [13]}最終的な解決策は、DRI がレンダリングバッファを処理する方法を変更することであり、これにより、新しい操作セットを備えたまったく異なる DRI 拡張機能が生まれ、ダイレクトレンダリングマネージャにも大きな変更が加えられた。^[3]新しい拡張機能は「DRI2」と名付けられたが、これは後継バージョンではなく、元の DRI と互換性のない別の拡張機能であり、実際、X サーバー内では両方とも長い間共存していた。

DRI2では、単一の共有（バック）バッファの代わりに、すべてのDRIクライアントは、ハードウェアアクセラレーションを使用してウィンドウのコンテンツをレンダリングするために、関連する深度バッファとステンシルバッファとともに、独自のプライベートバックバッファ^{[11] [12]}を取得します。次に、DRIクライアントはそれを偽の「フロントバッファ」^[12]と交換します。これは、合成ウィンドウマネージャによって、 VBLANK間隔で実際のフロントバッファと交換される最終的な画面バックバッファを構成（構築）するためのソースの1つとして使用されます。

これらすべての新しいバッファを処理するために、ダイレクトレンダリングマネージャは新しい機能、具体的にはグラフィックスメモリマネージャを組み込む必要がありました。DRI2は当初、実験的なTTMメモリマネージャを使用して開発されましたが、 ^{[11] [13]後にGEMがDRMメモリマネージャの決定版として選ばれた後、} GEMを使用するように書き直されました。^[14]新しいDRI2内部バッファ管理モデルは、元のDRI実装に存在していた2つの主要なパフォーマンスボトルネックも解決しました。

• DRI2クライアントは、レンダリングにDRMデバイスを使用している間、デバイス全体をロックしなくなりました。これは、各クライアントが他のプロセスから独立した個別のレンダリングバッファを取得するためです。^[12]
• DRI2 クライアントは、ビデオ メモリ内に独自のバッファ (テクスチャ、頂点リストなどを含む) を割り当て、必要なだけ保持できるため、ビデオメモリの帯域幅の消費が大幅に削減されます。

DRI2 では、ウィンドウのプライベート オフスクリーン バッファ (バック バッファ、フェイク フロント バッファ、デプス バッファ、ステンシル バッファなど) の割り当ては、X サーバ自体によって行われます。^{[15] [16]} DRI クライアントは、DRI2 拡張機能で利用可能なDRI2GetBuffersやDRI2GetBuffersWithFormatなどの操作を呼び出して、それらのバッファを取得し、ウィンドウにレンダリングします。 ^[3]内部的には、DRI2 は、X11 プロトコルを介してそれらのバッファへの「参照」を渡すために、GEM 名を使用します。GEM 名とは、DRM デバイスにアクセスする 2 つのプロセスが同じバッファを参照できるようにする、GEM API によって提供されるグローバル ハンドルの一種です。[ 16 ] X^サーバがウィンドウのレンダリング バッファのバッファ割り当てを担当する理由は、GLX 拡張機能によって、複数の X クライアントが同じウィンドウでOpenGLレンダリングを協調して実行できるためです。 ^[15]このようにして、X サーバはレンダリング プロセス全体にわたってレンダリング バッファのライフサイクル全体を管理し、いつ安全に再利用または破棄できるかを認識します。ウィンドウのサイズ変更が行われると、Xサーバーは新しいウィンドウサイズに一致する新しいレンダリングバッファを割り当て、InvalidateBuffersイベントを使用してウィンドウにレンダリングするDRIクライアントに変更を通知し、新しいバッファのGEM名を取得する責任もあります。^[15]

DRI2 拡張機能は、DRI クライアントに、使用すべき DRM デバイスとドライバーの検出 ( DRI2Connect ) や、DRM デバイスのレンダリング機能とバッファ機能を使用できるように X サーバーによる認証を受ける ( DRI2Authenticate ) などのコア操作も提供します。^[3]レンダリングされたバッファを画面に表示するには、DRI2CopyRegionおよびDRI2SwapBuffers要求を使用します。DRI2CopyRegion は、偽のフロント バッファと実際のフロント バッファ間のコピーに使用できますが、垂直ブランキング インターバルとの同期は提供されないため、ティアリングが発生する可能性があります。一方、 DRI2SwapBuffers は、サポートされていて両方のバッファが同じサイズである場合は、バック バッファとフロント バッファ間の VBLANK 同期スワップを実行し、そうでない場合はコピー ( blit ) を実行します。^{[3] [15]}

DRI2はオリジナルのDRIに比べて大幅に改善されましたが、新しい拡張機能によっていくつかの新しい問題も発生しました。^{[15] [16]} 2013年には、これらの問題を解決するために、DRI3と呼ばれるダイレクトレンダリングインフラストラクチャの3番目のバージョンが開発されました。^[17]

DRI3 と DRI2 の主な違いは次のとおりです。

• DRI3クライアントは、DRI2でサポートされていたXサーバーによる割り当てではなく、レンダリングバッファを独自に割り当てます。^{[15] [16]}
• DRI3は、DRIクライアントとXサーバー間でバッファオブジェクトを渡すためのGEM名（グローバルGEMハンドル）に基づく古い安全でないGEMバッファ共有メカニズムを廃止し、代わりにファイル記述子を使用するPRIME DMA-BUFに基づくより安全で多用途なメカニズムを採用しました。^{[15] [16]}

クライアント側でのバッファ割り当ては、複数の GLX アプリケーションが同じウィンドウで協調してレンダリングすることができなくなるという意味で、 GLXの前提を破ります。プラス面としては、DRI クライアントが存続期間中ずっと自身のバッファを管理するという事実は、多くの利点をもたらします。たとえば、DRI3 クライアントは、レンダリング バッファのサイズが常にウィンドウの現在のサイズと一致するようにすることが容易であり、それによって、DRI2 でのウィンドウのサイズ変更で問題となっていた、クライアントとサーバー間のバッファ サイズの同期不足によるアーティファクトを排除できます。^{[15] [16] [18]}また、DRI3 クライアントは、X サーバーがレンダリング バッファを送信するのを待つ余分なラウンド トリップを節約できるため、パフォーマンスも向上します。^[16] DRI3 クライアント、特にコンポジター ウィンドウ マネージャーは、以前のフレームの古いバッファを保持し、ウィンドウの損傷した部分のみをレンダリングするためのベースとして再利用することで、パフォーマンスを最適化できます。^{[15] [16]} DRI3拡張機能は、新しい特定のバッファ形式をサポートするために変更する必要がなくなりました。これは、これらのバッファ形式がDRIクライアントドライバとDRMカーネルドライバの間で直接処理されるようになったためです。^[15]一方、ファイル記述子を使用すると、カーネルは使用されていないGEMバッファオブジェクト（参照されていないオブジェクト）を安全にクリーンアップできます。^{[15] [16]}

技術的には、DRI3 は「DRI3」拡張と「Present」拡張という 2 つの異なる拡張から構成されています。^{[17] [19]} DRI3 拡張の主な目的は、DRI クライアントと X サーバーの間で直接レンダリングされたバッファーを共有するメカニズムを実装することです。^{[18] [19] [20]} DRI クライアントは GEM バッファー オブジェクトをレンダリング ターゲットとして割り当てて使用しますが、X サーバーはこれらのレンダリング バッファーを「pixmap」と呼ばれる X11 オブジェクトのタイプを使用して表します。DRI3 は、DRI3PixmapFromBufferとDRI3BufferFromPixmapという 2 つの操作を提供します。1 つは GEM バッファー オブジェクト (「DRI クライアント空間」) から pixmap (「X サーバー空間」) を作成する操作で、もう 1 つはその逆を行い、X pixmap から GEM バッファー オブジェクトを取得します。^{[18] [19] [20]}これらの DRI3 操作では、GEM バッファー オブジェクトはGEM 名ではなくDMA-BUFファイル記述子として渡されます。 DRI3 は、DRI クライアントと X サーバーの間で同期オブジェクトを共有する方法も提供し、共有バッファへのシリアルアクセスを可能にします。^[19] DRI2 とは異なり、最初のDRI3Open操作 (どの DRI クライアントがどの DRM デバイスを使用するかを知るために最初に要求する必要がある操作) では、デバイスノードのファイル名ではなく、既に開いているファイル記述子がデバイスノードに返されます。必要な認証手順は、X サーバーによって事前に実行されています。^{[18] [19]}

DRI3 は、レンダリングされたバッファを画面に表示するメカニズムを提供しておらず、別の拡張機能であるPresent拡張機能に依存しています。^[20] Presentという名前は、その主なタスクがバッファを画面に「表示」することであるため、クライアント アプリケーションによって配信されたレンダリングされたバッファの内容を使用してフレームバッファの更新を処理することを意味します。^[19]ティアリングなどの表示アーティファクトを回避するために、画面の更新は適切なタイミングで実行する必要があります。通常、VBLANK 間隔中に行われます。Present は、画面の更新を VBLANK 間隔に同期させる処理も行います。^[21]また、イベントを使用して各バッファが実際に画面に表示される瞬間を X クライアントに通知するため、クライアントはレンダリング プロセスを現在の画面のリフレッシュ レートと同期できます。

Present は、画面更新のソースとして任意の X ピックスマップを受け入れます。^[21]ピックスマップは標準の X オブジェクトであるため、Present は直接レンダリングを実行する DRI3 クライアントだけでなく、任意の手段でピックスマップをレンダリングする任意の X クライアントでも使用できます。^[18]たとえば、既存の非GLベースのGTK+およびQtアプリケーションのほとんどは、 XRenderを使用してダブル バッファリングされたピックスマップ レンダリングを実行していました。Present 拡張機能は、これらのアプリケーションでも使用でき、効率的でティアリングのない画面更新を実現します。これが、Present が DRI3 の一部ではなく、独立したスタンドアロン拡張機能として開発された理由です。^[18]

非GL XクライアントがVBLANKで同期できるようにする以外にも、Presentには他の利点があります。DRI3グラフィックスのパフォーマンスは、PresentがDRI2よりもバッファのスワップに効率的であるため優れています。^[19] DRI2では利用できなかったOpenGL拡張機能のいくつかは、Presentが提供する新機能に基づいてサポートされるようになりました。^[19]

Present は、X クライアントに 2 つの主な操作を提供します。1 つは、ピックスマップの内容の一部またはすべてを使用してウィンドウの領域を更新する操作 ( PresentPixmap )、もう 1 つは、クライアントが通知を受ける必要がある特定のウィンドウに関連するプレゼンテーション イベントの種類を設定する操作 ( PresentSelectInput ) です。^{[19] [21]ウィンドウが X クライアントに通知できるプレゼンテーション イベントは 3 つあります。進行中のプレゼンテーション操作 (通常は}PresentPixmapの呼び出しによる) が完了したとき ( PresentCompleteNotify )、もう 1 つはPresentPixmap操作で使用されるピックスマップが再利用できる状態になったとき ( PresentIdleNotify )、もう 1 つはウィンドウ構成 (主にウィンドウ サイズ) が変更されたとき ( PresentConfigureNotify ) です。^{[19] [21]} PresentPixmap操作がフロント バッファーへの直接コピー ( blit ) を実行するか、バック バッファー全体をフロント バッファーと交換するかは、DRI2 のように X クライアントが明示的に選択するのではなく、Present 拡張実装の内部詳細です。

ATI Mach64、ATI Rage128、ATI Radeon、3dfx Voodoo3 から Voodoo5、Matrox G200 から G400、SiS 300 シリーズ、Intel i810 から i965、S3 Savage、VIA UniChrome グラフィックス チップセット、およびNvidia用のnouveauなど、いくつかのオープン ソースDRI ドライバーが作成されています。ATIやPowerVR Kyro など、一部のグラフィックス ベンダーはクローズド ソースのDRIドライバーを作成しています。

DRI のさまざまなバージョンが、 Linux カーネル、FreeBSD、NetBSD、OpenBSD、OpenSolarisなど、さまざまなオペレーティング システムで実装されています。

このプロジェクトは、Precision InsightのJens OwenとKevin E. Martinによって開始されました（Silicon GraphicsとRed Hatの資金提供による）。^{[1] [22]最初は}XFree86 4.0 ^{[1] [23]}の一部として広く利用可能になり、現在はX.Org Serverの一部となっています。現在はフリーソフトウェアコミュニティによって管理されています。

DRI2 の作業は、2007 年の X Developers' Summit でKristian Høgsbergの提案から始まりました。^{[24] [25]} Høgsberg 自身が新しい DRI2 拡張機能とMesaおよ​​びGLXへの変更を書きました。^[26] 2008 年 3 月には DRI2 はほぼ完成していましたが、^{[27] [28] [29]} X.Org Serverバージョン 1.5には組み込めず^[14]、2009 年 2 月のバージョン 1.6 まで待たなければなりませんでした。 ^[30] DRI2 拡張機能は、2009 年 10 月の X11R7.5 リリースで正式に含まれました。 ^[31] DRI2 プロトコルの最初の公開バージョン (2.0) は、2009 年 4 月に発表されました。^[32]それ以来、いくつかの改訂が行われており、最新のものは 2012 年 7 月のバージョン 2.8 です。^[4]

DRI2 にはいくつかの制限があったため、2012 年の X.Org 開発者会議で Keith Packard と Emma Anholt によって DRI-Next と呼ばれる新しい拡張機能が提案されました。^{[15]この拡張機能は}Linux.conf.au 2013で DRI3000 として再度提案されました。^{[16] [17]} DRI3 および Present 拡張機能は 2013 年に開発され、2013 年 12 月の X.Org Server 1.15 リリースに統合されました。^{[33] [34]} DRI3 プロトコルの最初のバージョン (1.0) は 2013 年 11 月にリリースされました。^[5]

• 
  Xサーバー内の2Dドライバー
• 
  GLX経由の間接レンダリング、Utah GLXを使用; 別途: fbdev
• 
  初期のDRI:モード設定は引き続きXディスプレイサーバーによって実行されており、ルートとして実行される必要があります。
• 
  最終的にすべてのアクセスはダイレクトレンダリングマネージャーを経由します
• 
  Linuxカーネル3.12ではレンダリングノードが導入され、DRMとKMSドライバーが分割されました。WaylandはEGL経由の直接レンダリングを実装しています。

• ダイレクトレンダリングマネージャー
• メサ 3D
• X ウィンドウ システム

ウィキメディア・コモンズには、ダイレクト・レンダリング・インフラストラクチャに関連するメディアがあります。

• ダイレクトレンダリングインフラストラクチャプロジェクトのホームページ
• 現在の仕様書（常に最新バージョンに更新されます）：
  • DRI2 拡張機能 (Kristian Hogsberg、2008 年)
  • DRI3 拡張機能 (Keith Packard、2013)
  • プレゼントエクステンション（キース・パッカード、2013年）