OpenGL、GLX、DRI、およびMesa3Dの関係は何ですか？
Linuxで低レベルの3Dプログラミングを始めています。私は、より高いレベルのグラフィックAPI OpenInventorを使用した多くの経験を持っています。
これらすべてがどのように組み合わされているかを認識することが厳密に必要なわけではないことはわかっていますが、興味があるだけです。 OpenGLがグラフィックスアプリケーションの単なる標準であることは知っています。 Mesa3Dは、この標準のオープンソース実装のようです。
では、GLXとDRIはどこに適合するのでしょうか。ウィキペディアとこれらのすべてのWebサイトを調べてみたところ、すべてがどのように連携しているかについての正確な説明はまだわかりません。ハードウェアアクセラレーションはどこで発生しますか？プロプライエタリドライバーはこれとどのような関係がありますか？
OpenGLを除いて、これらのライブラリーを使用したことはありませんが、あなたがしたように、ウィキペディアのページを読んで、推測してみます。
あなたはメサについて正しいようです。これが私たちが持っている追加情報です：
"Open Inventorは、OpenGLのプログラミングの上位層を提供するように設計されたC++ 3DグラフィックAPIです"
物事をより簡単にするために、これらの各APIの入り口と出口で発生するデータ（およびコマンド）の単純化されたフローを想像してみましょう。最初に、あなたのコンピュータから実行するあなたのアプリケーションプログラム（コンパイルされたコード）があります。最後に、画面に表示される画像があります。
これらの質問への回答を制限するいくつかのケースがあります。
-コンピュータには、グラフィック機能を処理するためのグラフィックカード（GPU）またはCPUのみが搭載されていますか？
-アプリケーションはXウィンドウシステムのウィンドウに埋め込まれていますか？
-xウィンドウシステムを使用している場合、「xサーバー」はご使用のコンピューターまたはネットワーク上の他のコンピューターで実行されていますか？
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番目のシナリオ：次に、私が読んだいくつかのWikipediaの行に基づいて、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のドキュメントを調べて、何ができるかを正確に知ることです。
前のグラフを1つにまとめると、状況がわかりやすくなる場合があります。私はこれをあなたのエクササイズとしてしましょう！
OpenGLはプラットフォームに依存しません。つまり、OpenGL APIはプラットフォームに依存しません。
OpenGLの状態とバッファーは、一般にコンテキストと呼ばれる抽象オブジェクトによって収集されます。
ホスティングプラットフォームは、基盤となるプラットフォームのOpenGLコンテキストを作成するためのAPIを提供する責任があります。 Windowsではwgl *ルーチン（Windows for GL）があり、UnixではglX *ルーチン（GL for X）があります。
実際、GLXは、アプリケーションがOpenGL APIを使用するためにOpenGLコンテキストを作成できるようにするAPIにすぎません。
一般的なWGL/GLX操作は、ウィンドウの作成、オフスクリーンバッファーの作成、OpenGLコンテキストをスレッド上で最新にする、描画バッファーをスワップするなどです。
代わりにDRIは、XServerをバイパスしてグラフィックカードとの直接通信を可能にするカーネルレイヤーであり、実際にOpenGLルーチンを使用してアプリケーションを高速化します。
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
DRIとも呼ばれるダイレクトレンダリングインフラストラクチャは、Xウィンドウシステム下のグラフィックハードウェアに安全かつ効率的な方法で直接アクセスできるようにするフレームワークです。 Xサーバー、いくつかのクライアントライブラリ、カーネル（DRM、Direct Rendering Manager）への変更が含まれます。 DRIの最も重要な用途は、Mesaにハードウェアアクセラレーションを提供する高速OpenGL実装を作成することです。 3DFX、AMD（旧ATI）、Intel、Matroxによって製造されたチップセット用のドライバーを含む、いくつかの3DアクセラレーションドライバーがDRI仕様に書き込まれています。
簡単に言えば、OpenGLはグラフィックライブラリのタイプと仕様です。メサは基本的な実装です。 DRIはハードウェアインターフェイスシステムです。
メサは基本的にフレームワーク全体を指します。ただし、Mesaハードウェアドライバーについてお話していると思います。
DRIは基本的に、ハードウェアを処理するためのカーネルインターフェイスです。技術的には他の用途にも使用できますが、Mesa用に作成され、主にMesaに使用されます。
GLXは、それがすべてXとどのようにインターフェースするかです。
各部分が何であるかを理解するには、どのように組み合わされるかを知る必要があります。
プログラムは、openGLライブラリとインターフェースするように設計されています。
GLXは、OpenGLをX11と、またはX11を介してインターフェースする手段です。 「直接」インターフェースまたは「間接」インターフェースのどちらを使用しているかによって、プログラムがこれを心配するかどうかによって異なります。
libGLはこれらのインターフェースです。通常、Mesaドライバーを使用している場合は、Mesaによって提供されます。
間接的なセットアップでは、次のようになります。アプリケーションフレームワーク（ハードウェアアプリケーション、エンジン、または抽象化API）| LibGL |メサドライバー| DRI |ハードウェア
この構成では、GLXは、プログラムのGL useと他のプログラムの間のインターフェイスを処理するために、側面で使用されます。X11スタックとの通信を必要とすることを行うために使用されるGLX固有の呼び出し以外は、サポートプログラム（ウィンドウマネージャーなど）GLXはほとんど変更されていません。
さらに、コマンドパススルーと共有メモリを使用して、このシステムのレイヤーをさらに最適化できます。これにより、待ち時間が短縮され、ハードウェアへのアクセス速度が向上します。これは通常必要なものです。
間接的にはそれはあなたのアプリケーションフレームワークです| LibGL（ユーザー側）| LibGLX | LibGL（X11側）| Mesaハードウェアドライバー| DRI |ハードウェア
これの利点は、この設定を使用するためにハードウェアで直接共有メモリバッファを必要としないことです。 （ネットワーククライアントと、より堅牢でより安全なセットアップを可能にします。）
この設定は、単一のビデオカードを共有する複数のVMで機能するか、またはこのためにネットワーク経由でアクセスすることもできます。新しい拡張機能により、一部の形式の共有メモリまたは仮想共有「クローン」メモリを使用できますが、これは、直接レンダリングモードで見られる直接ビデオメモリアクセスではありません。
不利な点は、X11とのインターフェースにパイプまたはネットワークソケットを使用すると遅くなり、少なくとも最適化されたプログラムではレイテンシが発生し、最適化が不十分なプログラムではフレームレートが大幅に低下することです。
これは、ネットワーク接続されたクライアント、より堅牢なセキュリティを必要とするセットアップ、および同じGLスタックを実行して複数のオペレーティングシステムがハードウェアを共有する必要があるセットアップに適しています。最適とはほど遠いが、ある程度のハードウェアアクセラレーションを提供します。