7

現在、パイプラインには約 15 のレンダー パスがあります。すべてのパスで、描画する前に正しい設定を行い、後で再設定します。これらの設定には、ビューポート サイズ、深度テストのオンまたはオフ、ブレンド機能またはオフ、ステンシル機能、ステンシル操作などが含まれます。

OpenGL が、既に存在する状態を設定する API 呼び出しを無視するほど賢いかどうかは疑問です。それ以外の場合は、多くのフラグを使用して状態を追跡し、実際に必要な場合にのみレンダー パスの前に状態を設定するためです。

4

3 に答える 3

2

それ以外の場合は、多くのフラグを使用して状態を追跡し、実際に必要な場合にのみレンダー パスの前に状態を設定するためです。

これは、そのままにしておくよりも速いかもしれないし、そうでないかもしれないことに注意してください。他の人が言ったように、OpenGL は単なる API 仕様であり、実装は GPU ベンダー (または Mesa などのオープン ソース コミュニティ) に委ねられています。一般に、すべての呼び出しでなんらかの結果が生成されることを期待する必要がありますが、主な関心事がパフォーマンスである場合、実際に選択する唯一の方法はプロファイリングです。

これらの結果は、プラットフォームごとに、またはグラフィック ドライバーのバージョンによっても異なる場合があり、場合によっては、バッテリ電源からの実行など、思いがけないこともあります。測定するまでは、アプリケーションの実際のパフォーマンスの問題は何かを判断することはできません。

于 2013-06-17T10:06:34.650 に答える
-1

これらの多くはフラグのようであり、テストして設定するよりもフラグを設定する方がコストがかかる可能性があります。したがって、問題は、OpenGLが十分に賢いというよりも、それを行うのに十分愚かであるかどうかです。

残りの部分については、計算のコスト、おそらく変換マトリックスの設定が実際のレンダリングの作業と比較して重要であり、したがってライブラリレベルで最適化する価値がないかどうかは疑問です。

于 2013-06-17T08:39:43.250 に答える