最新のOpenGLでユニフォームを処理するための良いアプローチは何ですか?


8

私は最新のOpenGL(3.1以降)を使用してレンダラーを作成していますが、今ではユニフォームを処理する効率的で柔軟な方法を作成しようとしています。私は、均一なバッファオブジェクトと、これらを使用するための「一般的な」アプローチとは何かを調べてきました(後者は、残念ながら、期待していたほど多くの結果が得られませんでした)。

OpenGL API呼び出しを減らし、連続したメモリにデータを保存するために、GPUにアップロードする必要がある各データ構造に対して複数の大きなバッファーを作成することを検討しています。各バッファの最大サイズは16kbです(私が理解しているところによると、これはUBOで使用できることが保証されています)。オブジェクトがユニフォームをGPUにアップロードできるようにしたい場合、まだいっぱいではない、アップロード対象のタイプの最初のバッファーをフェッチし、そのバッファー内で次に使用可能なインデックスを取得します。オブジェクトが描画されると、UBOがバインドされ(まだバインドされていない場合)、UBOの要素インデックスがアップロードされます。

これにより、次のような結果になります。

layout(std140) uniform ModelData { 
    mat4 model_matrix[kNumInstancesPerModelUbo]; 
}
uniform int u_ModelDataIndex;

layout(std140) uniform SkeletonData { 
    mat4 bone_transforms[kNumInstancesPerSkeletonUbo][kMaxBones]; 
}
uniform int u_SkeletonDataIndex;

ただし、次のことも検討しています。

layout(std140) uniform MeshData {
    mat4 model_matrix[kNumInstancesPerMeshUbo];
    mat4 bone_transforms[kNumInstancesPerMeshUbo][kMaxBones];
}
uniform int u_MeshDataIndex;

いくつかの点で、これは、アップロードされるメッシュに関連するすべてのデータにアクセスするために単一のインデックスを必要とするという点で、はるかにきれいに感じられます。一方、これは手に負えない可能性があります(16kbより大きいバッファーサイズ、無関係なデータ(スケルトンのないメッシュなど)へのハンドル)、またはモデルマトリックスのアップロード中にボーンを言うためのアクセスが許可されていないため、同期の問題も発生します)これがGPUのメモリレイアウトにどのように影響するかはわかりません。

率直に言って、私はここで立ち往生しているように感じ、UBOを高速で柔軟に処理する方法の具体的な例を見つけることができません。

ここで私を助けることができるアドバイスやリソースはありますか?

回答:


2

より大きなバッファからのサブアロケーションは絶対に行くべき道ですが、警告があります。私はDirectX / Vulkan側からより多くのことをやっていますが、これはOpenGLにも同様に当てはまるはずです(この回答では、直接のAPI呼び出しはありません)。考慮すべき事項は次のとおりです。

  • より大きなバッファーにインデックスを付ける必要がありますか、それとも毎回リソースをオフセットにバインドしても大丈夫ですか?
  • 一緒にパックされたユニフォームの配置制限のすべてに注意しましたか(256バイトの配置が一般的です)。

新しいグラフィックAPIには、描画コマンドで指定できる「動的オフセット」があります。これは、バッファーのサブ領域に間接的にアクセスするための非常に高速な方法です。ただし、変更可能なデータをトリプルバッファリングしていると仮定すると、データをバインドするためのドライバーでの競合はほとんどまたはまったくないはずです(固定オーバーヘッドのみ)。

要約すると、はい、メモリ/バッファのより大きな領域を割り当て、それらの領域をサブリースすることがベストプラクティスと見なされます。これは、異なるシェーダーを持つオブジェクトにも当てはまります(アロケーターがそれを処理できる場合)。


0

アプリケーションに両方のソリューションのベンチマークフェーズを含め、実行時に最適なソリューションを選択します。これはシンプルで移植性があり、将来を見据えています。つまり、あなたはこれについてのテストを持っていますよね?;-)

これは高パフォーマンスの「ベストプラクティス」に対するかなり一般的な答えであることは知っていますが、考えれば、数千の可能なターゲット構成と考慮すべき多くのベンダーがあります。その少し余分なものが必要な場合は、アプリケーションに最適化されたドライバーのベンダーに支払います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.