☰

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

tag-icon • tag-icon xorg kde opengl
LIBGL_ALWAYS_INDIRECT = 1は実際に何をしますか？

KDE SC 4.5.0には、一部のグラフィックカード（マイグラフィックカードを含む）にいくつかの問題があります。リリース後Archは複数のソリューションをお勧めします。その一つは

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

私はこれが最も簡単で良い方法だと思います。しかし、私はそれが何をしているのか、それが私のシステムにどのような影響を与えるのかわかりません。デフォルトより遅いですか？この問題を引き続き確認し、問題が解決したら無効にする必要がありますか？

答え1

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

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

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

言う:どちらの場合も、レンダリングはGPUによって実行されます（または技術的にはGPUによって実行されます）。ただし、間接レンダリングでは、プロセスは次のようになります。

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

直接レンダリング

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

OpenGLはネットワーク経由で動作するように設計されているため、間接レンダリングは複数のコマンドを一度に送信できる単純なアーキテクチャ実装よりも高速です。ただし、コンテキストの切り替えとプロトコルの処理に費やされるCPU時間の点では、わずかなオーバーヘッドがあります。

答え2

1つ目LIBGL_ALWAYS_INDIRECTは、Mesa 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を使用してすべてのコマンドをレンダリングし、結果をラスターイメージ（XPutImage()）を介してリモートXサーバーにプッシュします。設定LIBGL_ALWAYS_INDIRECT=1（Mesa 17.3以前は作業をしてください。1または本物) は Mesa に通常の直接レンダリングや内部ソフトウェアレンダラーを無視し、以前と同様に間接レンダリングを使用するように指示します.

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

OpenGLバージョン

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

パフォーマンス

  • アプリケーションが間接接続用に設計されている場合（表示リストを使用し、往復クエリを最小限に抑える）、合理的なパフォーマンスを得ることができます。
  • アプリケーションがglGetInteger()フレームごとに100回実行するなど、愚かな操作を実行している場合、各クエリは高速LANでも簡単に1msかかります。フレームごとに合計100msかかります。これは、アプリケーションが10FPSを超えることができないことを意味します。
  • レンダリング負荷が大きすぎないと、同じアプリケーションが直接ソフトウェアレンダリングによって非常にうまく機能する可能性があります。なぜなら、これらすべてのglGetInteger()呼び出しは数マイクロ秒またはナノ秒以内に直接応答できるからです。
  • アプリケーションが100万の頂点からなる表示リストを作成してから多くの回転を実行すると、反対側で実際のGPUを使用する間接レンダリングはより良いパフォーマンスを提供します。
  • アプリケーションでOpenGL 1.4と2.xしか利用できない場合は、他のコードパスに置き換えることもできます。これはパフォーマンスに影響を与える可能性があります。

したがって、アプリケーションとネットワークの特性に関する正確な詳細がないと、特定の状況に対して直接ソフトウェアレンダリングまたは間接レンダリングがより良いかどうかを伝えることができないことがわかります。

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

根本的な問題が解決したら、必ずこのフラグを削除したいと思います。

関連情報