比較的新しい機能 GL_ARB_separate_program_object を調査しています。私が理解しているのは、glUseProgramStages を介してそこにマップされるステージからのシェーダーを含むパイプライン オブジェクトを作成する必要があることです。
これにより、複数のシェーダーを使用する 2 つの可能性について考えさせられます。
1. 各パイプラインへの 1 回のマッピングから生じるバリアント頂点/フラグメント シェーダー カップル (現時点では他のシェーダー タイプを使用しない) を使用して複数のパイプラインを作成します。
2.単一のパイプラインを作成し、実行時にマッピングを別のシェーダーに切り替える
glUseProgramStages
私は主にパフォーマンスに関心があります.どのオプションがよりパフォーマンスに優れていますか?
あなたの質問は、ドライバーの実装などによって異なるため、実際には答えられません。ただし、機能の事実と履歴は参考になるはずです。
EXT_separate_shader_objects は、この機能の最初の具現化です。それらの最大の違いは次のとおりです。EXT バージョンではユーザー定義の変数を使用できませんでした。のような古い互換性のある入出力を使用する必要がありましたgl_TexCoord。
EXT_separate_shader_objects 仕様の問題 #2 は、 この理解できない見落としを正当化しようと試みており、その理由を次のように説明しています。
パフォーマンスの観点からは、任意の個別のシェーダーに対して「名前によるランデブー」をサポートしようとすることは望ましくありません。これは、個別のシェーダーが、特別なリンク手順を行わないと、同じ名前のさまざまな入力と出力に一致するように自然にコンパイルされないためです。このような特別なリンクにより、個別のシェーダーをバインドするための追加の検証オーバーヘッドが発生します。リンク自体は glBegin 時間まで延期する必要があります。一貫したシェーダーのセットから別のセットに移行するときに個別のシェーダーが一致しないためです。この特別なリンクは、入力変数と出力変数の名前が一致しても、それらの型が一致しない場合に、エラーまたは未定義の動作を作成します。
これは、名前の一致に依存しない理由は、能力不足に加えて、パフォーマンスに関連していたことを示唆しています(わからない場合は、私は EXT_SSO をあまり高く評価していません)。「名前によるランデブー」のパフォーマンスは、一度に実行できるのではなく、ドローコールごとに実行する必要があることから生じます。
ARB_separate_shader_objects は、プログラムのコレクションをオブジェクトにカプセル化します。したがって、オブジェクトはすべての「ランデブー」データを格納できます。最初の描画呼び出しは遅くなるかもしれませんが、新しいプログラムを追加しない限り、同じ PPO のその後の使用は高速になります。
したがって、私はこれを、PPO にプログラムを設定してから放っておくべきであるという証拠と見なします。一般に、添付ファイル オブジェクトの変更は可能な限り避ける必要があります。そのため、FBO からテクスチャ/レンダー バッファーを追加または削除しないことをお勧めします。