LIBGL_ALWAYS_INDIRECT = 1は実際に何をしますか？

KDE SC 4.5.0には、私のものを含むいくつかのビデオカードにいくつかの問題があります。リリース時にArchはいくつかの回避策を推奨しました。その1つは

KDEを開始する前に「LIBGL_ALWAYS_INDIRECT = 1」をエクスポートします

私はそれが最も簡単で最良の方法だと決めました。しかし、それが何をするのか、それが私のシステムにどのように影響するのかはわかりません。デフォルトより遅いですか？問題を監視し、後で修正したら無効にすることを忘れないでください。

間接レンダリングとは、GLXプロトコルを使用してOpenGLコマンドを送信し、X.orgが実際の描画を行うことを意味します。

直接レンダリングとは、アプリケーションが最初にmesaを介してX.orgと通信せずにハードウェアに直接アクセスできることを意味します。

コンテキストをX.orgプロセスに変更する必要がないため、ダイレクトレンダリングは高速です。

明確化：どちらの場合でも、レンダリングはGPUによって行われます（または技術的にはGPUによって行われる場合があります）。ただし、間接レンダリングでは、プロセスは次のようになります。

1. プログラムがコマンドを呼び出します
2. コマンドはGLXプロトコルによってX.orgに送信されます
3. X.orgはハードウェア（つまりGPU）を呼び出して描画します

ダイレクトレンダリングで

1. プログラムがコマンドを呼び出します
2. コマンドはGPUに送信されます

OpenGLはネットワーク上で動作するように設計されているため、間接レンダリングはアーキテクチャの素朴な実装、つまり大量のコマンドを一度に送信できるよりも高速であることに注意してください。ただし、コンテキストの切り替えとプロトコルの処理に費やされるCPU時間に関して、いくらかのオーバーヘッドがあります。

まず、LIBGL_ALWAYS_INDIRECTMesa 3Dクライアント側OpenGL実装（libGL.so）に関連するフラグです。他のベンダー（NVIDIAなど）のバイナリドライバーでは動作しません。

第二に、あなたの質問に直接答えるために、最後に次のようにフラグが機能するMesaコードを見ました。

2008年以前、Mesaが間接Xサーバーを使用していたssh -X場合（たとえば、表示を非ローカルサーバーに明示的に設定した場合など）、リモートXサーバーによって提供されるGLXビジュアルのリストがGLXアプリケーションで使用可能になります。たとえば、アプリケーションはglXChooseVisual（）を呼び出し、Mesaは一致する適切なものを見つけ、後続のglFoo()呼び出しはリモートXサーバーに送信され、そこでリモートXサーバーが接続されたlibGL（おそらくGPU）によって実行されます。

2008年の終わり頃にMesaは変更され、内部ソフトウェアOpenGLレンダラー（Xlibドライバー）をリモートX接続に使用するようになりました。（SuSEなどの一部のディストリビューションは、これにパッチを適用して古い動作に戻します。）これは、リモートXサーバーが内部ソフトウェアレンダラーの1つと完全に一致するGLXビジュアルを提供する場合にのみ有効です。（それ以外の場合、「エラー：RGBを取得できませんでした、ダブルバッファリングされたビジュアル」を取得します。）そのようなビジュアルが見つかった場合、MesaはglFoo()ローカル（アプリケーション）CPUですべてのコマンドをレンダリングし、ラスター画像を介したリモートXサーバーへの結果（XPutImage()）; 設定LIBGL_ALWAYS_INDIRECT=1（Mesa 17.3より前では、どの値でも機能します。1またはtrueを使用する必要があるためです。）Mesaに、通常の直接レンダリングまたは内部ソフトウェアレンダラーを無視し、従来のような間接レンダリングを使用するように指示します。

間接レンダリングまたは直接ソフトウェアレンダリングを選択すると、2つのことが影響を受けます。

OpenGLバージョン

• 通常、間接レンダリングはOpenGL 1.4に制限されています。
• 直接ソフトウェアレンダリングは、Mesaソフトウェアラスタライザーがサポートするものすべて、おそらくOpenGL 2.1+をサポートします

性能

• アプリケーションが間接接続用に設計されている場合（表示リストを使用し、ラウンドトリップクエリを最小化する場合）、適切なパフォーマンスを得ることができます。
• アプリケーションがglGetInteger()フレームごとに100回のような馬鹿げたことをすると、高速LANでも、これらのクエリはそれぞれ1ミリ秒、またはフレームごとに合計100ミリ秒かかります。つまり、アプリケーションで10 FPSを超えることはありません。
• レンダリングの負荷がそれほど大きくない場合、同じアプリケーションは、直接のソフトウェアレンダリングで非常に良好に機能する可能性があります。これらのglGetInteger()呼び出しはすべてマイクロ秒またはナノ秒で直接応答されるためです。
• アプリケーションが100万頂点の表示リストを作成し、その後多くの回転を行う場合、もう一方の端にある実際のGPUを使用した間接レンダリングにより、パフォーマンスが大幅に向上します。
• また、アプリケーションは、OpenGL 1.4 vs 2.xのみを使用できる場合、別のコードパスにフォールバックする可能性があり、これもパフォーマンスに影響する可能性があります。

そのため、アプリケーションの正確な詳細とネットワーク特性がなくても、特定の状況で直接ソフトウェアレンダリングと間接レンダリングのどちらが優れているかを判断することはできません。

あなたの場合、ローカルのkwinインスタンスを実行しているようです。そのため、LIBGL_ALWAYS_INDIRECTローカルXサーバーに強制的に間接的にレンダリングされます。これは明らかにkwinの動作を変更する（OpenGL 1.4のみ）か、他のバグを回避します。

根本的な問題が修正されたら、間違いなくこのフラグを削除する必要があります。