EGL/OpenGL ES /スイッチングのコンテキストが遅い

Question

私は複数の 'フレーム'で構成されたOpenGL ES 2.0アプリケーション（Windows用のangleprojectを開発用に開発中）を開発中です。

各フレームは、周囲のフレームを妨害しないでください。フレームは、OpenGL ES 2.0を使用して、そのフレーム内で実行されるコードによって描画されます。

私の最初の試みは、各フレームにフレームバッファを割り当てることでした。しかし、OpenGLの内部状態は1つのフレームが描画されている間に変更され、次のフレームが既知のOpenGL状態をすべて包括的にリセットしない場合、副作用が発生する可能性があります。これは、各フレームが分離されてお互いに影響を及ぼさないという私の要求を破ります。

私の次の試みはフレームごとのコンテキストを使用することでした。私はフレームごとに独自のコンテキストを作成しました。私は共有リソースを使用しているので、eglMakeCurrentを各フレームに、それぞれ独自のフレームバッファ/テクスチャにレンダリングし、次にeglMakeCurrentをグローバルに戻して、各テクスチャを最終画面に合成します。

これはインスタンスを隔離するのに素晴らしい仕事ですが、eglMakeCurrentはです。が遅いです。それらのうちのわずか4つが画面をレンダリングするのに1秒以上かかることがあります。

どのようなアプローチが可能ですか？コンテキスト切り替えをスピードアップする方法や、フレームごとにOpenGLの状態をどうにかしてコンテキストを切り替える方法はありますか？

Answer 1

ここでの問題は、汎用プラットフォームとOSに依存しない方法でこれを行うことです。特定のプラットフォームを選択した場合、良い解決策があります。 Windowsでは、完全に独立したOpenGLコンテキストを複数のウィンドウに同時に実行するwglライブラリとglutライブラリがあります。 Windowsと呼ばれ、フレームではありません。 OpenGLではなくDirectXを使用することもできます。アングルはDirectXを使用します。 Linuxでは、OpenGLのX11が解決策です。どちらの場合でも、高品質のOpenGLドライバを用意することが重要です。 Intel Extremeチップセットドライバはありません。 AndroidやiOSでこの操作を行う場合は、別のソリューションが必要です。 AndroidのケースについてのKhronos.org OpenGL ESフォーラムに最近のスレッドがありました。

Answer 2

私はあなたの現在のアプローチを使用できるようにする一方、eglMakeCurrentのオーバーヘッドを排除する可能性のある提案があります。

現在のEGLContextの概念はスレッドローカルです。私はあなたのプロセスのマスタースレッドですべてのコンテキストを作成し、コンテキストごとに1つのスレッドを作成し、各スレッドに1つのコンテキストを渡すことをお勧めします。各スレッドの初期化時には、所有するコンテキスト上でeglMakeCurrentを呼び出し、eglMakeCurrentを再度呼び出すことはありません。うまくいけば、ANGLEの実装では、コンテキスト用のスレッドローカル記憶域は効率的に実装され、不要な同期オーバーヘッドはありません。