Linuxで低レベルの3Dプログラミングを始めています。私は、高レベルのグラフィックスAPI OpenInventorを使用した経験が豊富です。
これらのすべてがどのように組み合わされるかを知ることは厳密に必要ではないことを知っていますが、私はただ興味があります。OpenGLはグラフィックアプリケーションの単なる標準であることは知っています。Mesa3Dは、この標準のオープンソース実装のようです。
では、GLXとDRIはどこに適合するのでしょうか？ウィキペディアとこれらすべてのウェブサイトを掘り下げて、私はまだそれがどのように連携するかについての正確な説明をまだ見つけていません。ハードウェアアクセラレーションはどこで発生しますか？プロプライエタリなドライバーはこれと何の関係がありますか？
回答:
OpenGLを除き、これらのライブラリを使用したことはありませんが、あなたが行ったように、ウィキペディアのページを読んで推測しようとします。
あなたはMesaについて正しいようです。追加情報は次のとおりです。
「Open Inventorは、OpenGLのプログラミングの上位層を提供するために設計されたC ++ 3DグラフィックスAPIです」
物事を簡単にするために、これらの各APIの入り口と出口で発生するデータ（およびコマンド）の単純化されたフローを想像してみましょう。最初に、コンピューターから実行するアプリケーションプログラム（コンパイル済みコード）があります。最後に、画面に表示される画像があります。
これらの質問への回答を控える場合がいくつかあり
ます。-グラフィック機能を処理するために、コンピューターにグラフィックカード（GPU）またはCPUのみがありますか？
-アプリケーションはx-windowシステムのウィンドウに埋め込まれていますか？
-xウィンドウシステムを使用している場合、「xサーバー」はコンピューターまたはネットワーク上の他のコンピューターで実行されていますか？
GPUがある場合はGPU用のドライバーがあり、ソフトウェアレンダリング用のMesaがあると仮定します）。
最初のシナリオ：X Window Systemを使用せずにOpenInventorで作成されたグラフィックアプリケーションを実行し、グラフィックカードがない場合。プログラムの流れは次のようになります。
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
ここで起こることは「ソフトウェアレンダリング」と呼ばれます。グラフィックコマンドは、グラフィックハードウェアではなく、通常はソフトウェアを実行するプロセッサである通常のCPUによって処理されます。
2番目のシナリオ：上記と同じ条件で、グラフィックカードがあることを想像してください。フローは次のようになります。
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
今起こっていることは「ハードウェアアクセラレーション」と呼ばれ、通常は最初のシナリオよりも高速です。
3番目のシナリオ：今、私が読んだいくつかのウィキペディアの行に基づいて、X Window Systemのフローを紹介します。
グラフィックハードウェアとAPIについてはしばらく忘れてください。フローは次のようになります。
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
X Window Systemを使用する場合、画面とアプリケーションを実行するコンピューターは「直接」接続されない場合がありますが、ネットワーク経由で接続される場合があります。
4番目のシナリオ：前の例のXクライアントアプリケーションに派手な3Dグラフィックレンダリングを追加するとします。X Window Systemはもともとこれを行うことができないか、少なくともOpenGL API関数と同等の機能を実行するには複雑なコードを必要とするように思えます。
幸いなことに、GLXを使用してOpenGLコマンドのサポートをシステムに追加できます。あなたは今持っています：
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
これで、最初のシナリオで最後の矢印を「OpenGL」の後の矢印に再接続できます。画面に3D画像を取得できます。
最後に、私がDRIについて理解していると思うことについて：
MesaがGPUにアクセスできるようにするため、最初のシナリオのフローを次のように変更します：
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
また、GLXを使用する場合、サーバーとクライアントが同じコンピューター上にあり、GPUがあるという条件を考えると、フローを短絡させるようです。その場合、4番目のシナリオのグラフは次のようになります。
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
それでおしまい ！
ここで、私はUnix環境の専門家ではないことに留意してください。したがって、最善のアドバイスは、これらの各APIのドキュメントを調べて、APIの機能を正確に把握することです。
前のチャートを単一のチャートに結合すると、物事が理解しやすくなります。私はこれをあなたへのエクササイズとしてしましょう！
OpenGLはプラットフォームに依存しません。つまり、OpenGL APIはプラットフォームに依存しません。
OpenGLの状態とバッファは、一般にコンテキストと呼ばれる抽象オブジェクトによって収集されます。
ホスティングプラットフォームは、基盤となるプラットフォームのOpenGLコンテキストを作成するためのAPIを提供します。Windowsにはwgl *ルーチン（GL for Windows）があり、UnixにはglX *ルーチン（X for GL）があります。
実際、GLXは、OpenGL APIを使用するために、アプリケーションがOpenGLコンテキストを作成できるようにするAPIに他なりません。
一般的なWGL / GLX操作は、ウィンドウの作成、オフスクリーンバッファーの作成、スレッド上でOpenGLコンテキストを最新にする、描画バッファーを交換することです...
代わりにDRIは、XServerをバイパスしてグラフィックカードとの直接通信を可能にするカーネルレイヤーであり、実際にOpenGLルーチンを使用してアプリケーションを高速化します。
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
DRIとしても知られるDirect Rendering Infrastructureは、X Window Systemの下でグラフィックハードウェアに安全かつ効率的に直接アクセスできるようにするためのフレームワークです。Xサーバー、いくつかのクライアントライブラリ、およびカーネル（DRM、Direct Rendering Manager）への変更が含まれます。DRIの最も重要な使用法は、Mesaのハードウェアアクセラレーションを提供する高速OpenGL実装を作成することです。3DFX、AMD（以前のATI）、Intel、Matroxで製造されたチップセット用のドライバーを含む、いくつかの3D加速ドライバーがDRI仕様に記述されています。
簡単に言うと、OpenGLはグラフィックスライブラリのタイプと仕様です。メサは基本的な実装です。DRIはハードウェアインターフェイスシステムです。
Mesaは基本的にフレームワーク全体を指します。しかし、私はあなたがMesaハードウェアドライバーについて話していると思います。
DRIは基本的に、ハードウェアを処理するカーネルインターフェイスです。技術的には他の用途にも使用できますが、Mesa用に作成され、主にMesaに使用されます。
GLXは、すべてがXにインターフェイスする方法です!!
各部分が何であるかを理解するには、それがどのように適合するかを知る必要があります。
プログラムは、任意のopenGLライブラリとインターフェイスするように設計されています。
GLXは、OpenGLとX11をインターフェースする手段です。「直接」インターフェースと「間接」インターフェースのどちらを使用するかによって、プログラムがこれを心配するかどうかが決まります。
libGLは、ほとんどこれらのインターフェイスです。Mesaドライバーを使用している場合、通常Mesaによって提供されます。
間接的なセットアップでは、次のようになります。アプリケーションフレームワーク（つまり、ハードアプリケーション、エンジン、または抽象化API）| LibGL | メサドライバー| DRI | ハードウェア
この構成では、GLXはプログラムのGL使用と他のプログラムとの間のインターフェイスを処理するためにサイドで使用されます。X11スタックとそのサポートプログラム（ウィンドウマネージャーなど）の通信を必要とすることを行うために使用されるGLX固有の呼び出し以外は、GLXはほとんど変更されていません。この配置で。
さらに、コマンドパススルーと共有メモリを使用して、このシステムのレイヤをさらに最適化できます。これにより、レイテンシが短縮され、ハードウェアへのアクセス速度が向上します。これは通常あなたが望むものです。
間接的な場合は、アプリケーションフレームワークです。LibGL（ユーザー側）| LibGLX | LibGL（X11サイド）| Mesaハードウェアドライバー| DRI | ハードウェア
この利点は、このセットアップを使用するためにハードウェアとの直接共有メモリバッファが必要ないことです。（ネットワーククライアントに加えて、より堅牢で、より安全なセットアップを可能にします。）
このため、このセットアップは、単一のビデオカードを共有する複数のVMで機能することも、ネットワーク経由でアクセスすることもできます。新しい拡張機能により、一部の形式の共有メモリまたは仮想共有「クローン」メモリを使用できますが、直接レンダリングモードで見られる直接ビデオメモリアクセスではありません。
欠点は、パイプまたはネットワークソケットを使用してX11とのインターフェイスを遅くすることです。少なくとも、最適化されたプログラムでは遅延が発生し、最悪の場合、最適化が不十分なプログラムではフレームレートが大幅に低下します。
これは、ネットワーククライアント、より堅牢なセキュリティを必要とするセットアップ、および同じGLスタックを実行して複数のオペレーティングシステムがハードウェアを共有する必要があるセットアップに適したセットアップです。最適とはほど遠いですが、ある程度のハードウェアアクセラレーションを提供します。