7

私は FBO+RBO を使用しており、デフォルト フレームバッファでの通常のダブル バッファリングの代わりに、RBO に描画してから、単一のバッファリングされた OpenGL コンテキストでデフォルト FBO (0) の GL_FRONT バッファに直接ブリットしています。

それは問題なく、ちらつきもありませんが、シーンが少し複雑になると、fps が大幅に低下します。同期がスキップされたために 1/60 から 1/30 になったという意味ではなく、突然 90% fps が低下したという意味です。

ブリット後に glFlush() を試しましたが、違いはありませんでした。ブリット後に glFinish() を試したところ、10 倍の fps ブーストが得られました。

そのため、デフォルトのフレームバッファと swapbuffers() で通常のダブル バッファリングを使用すると、glFinish() を使用した場合と同様に、fps も向上しました。

何が起こっているのかわかりません。なぜ glFinish() はそうすべきではないのにそれほど大きな違いを生むのですか? また、ダブル バッファリング コンテキストで swapbuffers 呼び出しを使用する代わりに、フロント バッファで直接 RBO とブリットを使用しても問題ありませんか? 私は vsync が欠落していることを知っていますが、コンポジット マネージャはとにかく同期します (実際にはティアリングは見られません)。モニターが 10 フレーム中 9 フレームを欠落しているかのようです。

好奇心から、ネイティブの swapbuffers() は Windows または Linux で glFinish() を使用しますか?

4

2 に答える 2

1

同期関連の問題だと思います。

RBO に直接レンダリングし、フロント バッファーにブリッティングする場合、まったく同期が行われません。したがって、複雑なシーンでは、GPU コマンド キューがすぐにいっぱいになり、OpenGL コマンド中にドライバーによって CPU 同期が強制されるまで、CPU ドライバー キューもすぐにいっぱいになります。その時点で、CPU スレッドは停止します。

私が言いたいのは、いかなる形式の同期もなしに、複雑なレンダリング (1 つまたは複数の OpenGL コマンドがキューに入れられるレンダリング) は、キューがいっぱいになるので、常にある時点で CPU スレッドを停止させるということです。 CPU はますます多くのコマンドを発行します。

スムーズな (より一定の) ユーザー操作を行うには、同期が必要です (プラットフォーム固有の swapbuffers() または glFinish() のいずれかを使用)。これにより、CPU が状況を悪化させ、ますます多くのコマンドを発行するのを防ぎます (これは、 turn は後で CPU スレッドを停止させます)

参考：OpenGL同期

于 2013-07-12T08:19:34.813 に答える