5

複数の「フレーム」で構成される OpenGL ES 2.0 アプリケーション (Windows で angleproject を使用して開発) を開発しています。

各フレームは、周囲のフレームに干渉しない独立したアプリケーションです。フレームは、そのフレーム内で実行されるコードによって、OpenGL ES 2.0 を使用して描画されます。

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

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

ただし、これはインスタンスを分離するのに優れた仕事をします.. eglMakeCurrent は非常に遅いです。わずか 4 つでも、画面のレンダリングに 1 秒以上かかることがあります。

どのようなアプローチを取ることができますか? フレームごとに OpenGL の状態を何らかの方法で保存することで、コンテキストの切り替えを高速化するか、コンテキストの切り替えを回避する方法はありますか?

4

2 に答える 2

0

現在のアプローチを使用できるようにしながら、eglMakeCurrent のオーバーヘッドを排除できる提案があります。

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

于 2013-08-14T16:49:25.930 に答える
-1

ここでの問題は、一般的なプラットフォームと OS に依存しない方法でこれを行おうとすることです。特定のプラットフォームを選択する場合、適切なソリューションがあります。Windows には、完全に独立した OpenGL コンテキストを同時に実行する複数のウィンドウを提供する wgl および glut ライブラリがあります。フレームではなく、ウィンドウと呼ばれます。OpenGL の代わりに DirectX を使用することもできます。角度は DirectX を使用します。Linux では、ソリューションは OpenGL の X11 です。どちらの場合でも、高品質の OpenGL ドライバーを用意することが重要です。インテル エクストリーム チップセット ドライバーはありません。Android または iOS でこれを行う場合は、別のソリューションが必要です。Khronos.org OpenGL ES フォーラムには、Android のケースに関する最近のスレッドがありました。

于 2013-08-07T22:45:56.573 に答える