web-dev-qa-db-ja.com

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

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

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

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

xorgkdeopengl
23
xenoterracide

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

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

直接レンダリングは、X.orgプロセスへのコンテキストの変更を必要としないため、より高速です。

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

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

直接レンダリング

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

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

16
Maciej Piechotka

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

次に、質問に直接回答するために、最後にフラグが次のように機能するMesaコードを確認しました。

Mesaが間接Xサーバーで作業していた2008年以前（たとえば、_ssh -X_を実行したか、ディスプレイを非ローカルサーバーに明示的に設定した場合）は、リモートXサーバーによって提供されるGLXビジュアルのリストを使用できるようにします。 GLXアプリケーション。アプリケーションが呼び出します。 glXChooseVisual（）とMesaは一致する妥当なものを見つけ、その後のglFoo()呼び出しはリモートXサーバーに送信され、リモートXサーバーが接続されているlibGL（GPUなど）によって実行されます。 。

2008年の終わり頃にMesaが変更され、リモートX接続に内部ソフトウェアOpenGLレンダラー（ Xlibドライバー ）を使用するようになりました。 （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と2.xしか使用できない場合、アプリケーションは別のコードパスにフォールバックする可能性があり、これもパフォーマンスに影響を与える可能性があります。

したがって、アプリケーションとネットワークの特性の正確な詳細なしでは、直接ソフトウェアレンダリングと間接レンダリングのどちらが特定の状況に適しているかを判断することは不可能です。

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

根本的な問題が修正されたら、必ずこのフラグを削除します。

14
Nathan Kidd