Vulkan：静的データの均一バッファーとプッシュ定数

均一バッファーとプッシュ定数の概念的な違いを理解するのに苦労しています。仕様を読んで集めることができるものと、主な違いは次のとおりです。

1. 均一バッファーは、プッシュ定数よりもはるかに大きくなる可能性があります。
2. UBOはstd140を使用し、PCはstd430を使用します。
3. UBOはvkCmdUpdateBuffer（またはホストマッピング）を使用していつでも更新でき、その値を保持できます。それ以外の場合は、レンダーパスごとにPCを再プッシュする必要があります。（私を驚かせた-名前に基づいて。パイプラインの定数をそのまま更新し、それらの変更を持続させると思った）

私のシナリオでは、約200バイト相当のデータがあり、ほぼ一定であると予想しています。つまり、それらを非常にまれに変更します。すべてのコマンドバッファーでプッシュ定数を再送信する必要がある場合でも、（サイズが許す限り）プッシュ定数を使用する方が良いでしょうか？または、200バイトのUBOを使用して、vkCmdUpdatebufferでたまにしか更新しない方がよいでしょうか？

また。たとえばfloat random_seed、シェーダーが実行されるたびに更新するaがある場合はどうなりますか？私がすでにUBOを持っていると仮定すると、UBOの残りが一定であっても、UBOで一括処理する方が良いでしょうか、またはこの変数にプッシュ定数を使用することで利益を得られるので、すべてのレンダーパスの前にvkCmdUpdateBuffer？

UBOはvkCmdUpdateBufferでいつでも更新できます

仕様から：「vkCmdUpdateBufferはレンダーパスの外でのみ許可されます。」したがって、「いつでも」はそうではありません。

レンダーパスの内部で許可されていても、転送操作です。つまり、メモリ転送をそれを使用するコマンドと同期させる必要があります。パフォーマンスが低下します。

一般的なプッシュ定数と均一のことについては、あなたの判断を使用してください。「判断」とは、それらがどのように機能するかを見るだけです。プッシュ定数を使用すると、メモリ操作、同期、記述子の状態の変更などの重いプロセスを実行せずに、いつでもデータを変更できます。明らかに、これらは頻繁に変更されるデータ用です。どのくらいの頻度で「頻繁に」ですか？まあ、それは裁判の呼び出しです。

それができない場合は、パフォーマンスの違いをプロファイルしてください。

約200バイト相当のデータがあり、ほぼ一定であると期待しています。つまり、それらを非常にまれに変更します。

データが頻繁に変更されない場合は、特殊化定数を使用できます。それらはパイプラインの作成時に設定され、値を変更する必要がある場合は新しいパイプラインを作成する必要があります。ウィンドウのサイズ変更などのまれなイベントの場合、これは許容できるコストになる可能性があります。

たとえば、シェーダーが実行されるたびに更新するfloat random_seedがある場合はどうなりますか？

これは、プッシュ定数の完全なユースケースです。他のすべてのデータをUBO（または特殊化定数）に保持し、この値をで変更できますVkCmdPushConstants。