memory - 共有メモリアーキテクチャにおける OpenGL (ES 2.0) VBO パフォーマンス

Question

私はデスクトップ GL 開発者で、モバイルの世界を探求し始めています。

誤解を避けるため、または些細な回答を歓迎しますが、私は GL および GL|ES 機構について十分に認識していると謙虚に言えます。

簡単な質問は、共有メモリアーキテクチャで GL|ES 2.0 を使用している場合、クライアント側の配列に対して VBO を使用することの背後にあるポイントは何ですか?

詳細:

頂点バッファーはメモリの未加工のチャンクです。アクセスパターンは、1) アプリケーションが頂点データレイアウトを構成する方法、2) 頂点シェーダーがバッファーコンテンツを消費する方法、および 3) 大量に保持できることに依存するため、ドライバーは何も最適化できません。さまざまな方法で動作し、同じバッファーをさまざまな方法でソースする頂点シェーダーの数。
アライメント: 個々の VBO ストレージは、基礎となる GL システムに最適なアドレスで開始できます。これらの境界へのクライアント側配列の割り当てを強制する (たとえば、配置のベストプラクティスを尊重する) とどうなりますか?
Tile-Based Rendering vs. Immediate Mode アーキテクチャは関係ありません。私の理解では、これは私の質問 (つまり、メモリアクセス) とは関係ありません。

VBO を使用すると、コードを変更せずに将来のプラットフォーム/ハードウェアでコードをより適切に/より速く実行できることを理解していますが、これはこの質問の焦点ではありません。

同時に、共有メモリアーキテクチャで VBO を使用すると、メモリ使用量が 2 倍になり (何らかの理由で頂点データを自由に使用できるようにしなければならない場合)、データの memcpy が必要になることも認識しています。

インターリーブされた頂点配列と同様に、VBO の使用法は、開発者のフォーラム/ブログ/official_technotes で大きな「誇大宣伝」を受けていますが、これらのステートメントをサポートするデータ (つまり、ベンチマーク) はありません。

score 3 · Accepted Answer

VBO を使用して Android デバイスに頂点データを保存すると、パフォーマンスがまったく改善されなかったと報告できます。Adreno、Mali400、PowerVR GPU で試してみました。ただし、OpenGL ES のベストプラクティスであることを考慮して、VBO を使用します。

これに関するメモは、記事(頂点バッファーオブジェクトの段落) にあります。

score 0 · Accepted Answer

このレポートによると、SMA を一定に保持しても、OpenGL の実装 (一部の VBO 作業は CPU で密かに行われます) と VBO のサイズの両方に依存します。

score -1 · Accepted Answer

iOSプラットフォームについて私が知っていることをお話しします。VBO は本当にパフォーマンスを向上させます。

静的なジオメトリがある場合、VBO は完璧です。一度コピーすると、描画呼び出しごとに追加のオーバーヘッドはありません。CA は、ドローコールごとにクライアントメモリから「gpu メモリ」にデータをコピーします。あなたがそれを忘れた場合、それはデータの再整列を行うかもしれません。
VBO は gpu vie glMapBuffer にマップできます - これは非同期操作です。つまり、オーバーヘッドはほとんどありませんが、覚えておく必要があります - バッファをマッピング\アンマッピングするときは、マッピング解除操作の 2 フレーム後に使用することをお勧めします - 回避するために同期
Apple のエンジニアは、フレームごとに再アップロードしたとしても、VBO は SGX ハードウェア上の CA よりも優れたパフォーマンスを発揮すると宣言しています - 詳細はわかりません。
VBO はベストプラクティスです。CA は非推奨です。最新のトレンドに対応し、可能な限りクロスプラットフォームを維持する

memory - 共有メモリ アーキテクチャにおける OpenGL (ES 2.0) VBO パフォーマンス