インデックス描画は非インデックス描画より速いですか

6つの頂点(2つの三角形)からなる多角形をたくさん描く必要があります。

テクスチャ座標、法線などがなければ、どちらの方法でも72バイトになります。将来、私は間違いなくテクスチャ座標と法線も必要となるでしょう。それほど多くはありません。

だから私の質問は、次のとおりです。頂点のオーバーラップが少ないVAOの場合、どちらのアプローチが速いですか。非インデックス描画で余分なメモリが消費されることを気にする必要はありません。速度だけです。

Edit: To make it clear.

ノンインデックスアプローチ

float[18] vertices = {
//Triangle 1
1,1,0,
1,0,0,
0,0,0,

//Triangle 2
1,0,0,
0,1,0,
0,0,0,
};

インデックスアプローチ

float[12] vertices = {
1,1,0,
1,0,0,
0,0,0,
0,1,0,
};

int[6] indices = {
//Triangle 1
0,1,2,

//Triangle 2
0,3,2
};
8
nl ru de
...ターゲットハードウェア上の特定のアプリケーションに対する両方のアプローチを測定し、最終的に見つけ出してはどうでしょうか。
追加された 著者 Sean Middleditch,

4 答え

私はその質問に答えようとしています。いくつかの理由から、インデックスを使用する必要があると思います。

1)いずれにせよ、インデックスはGPU側で自由操作です、あなたはそこにペナルティを課しません。 (追加)もちろん、インデックスはランダムアクセス操作であり、GPUメモリキャッシュのパフォーマンスを低下させる可能性があります。

2)インデックス付けは、GPU頂点キャッシュが重なり合う頂点についてこれらのわずかな最適化を行うことを可能にし得る。

3) Smaller memory footprint at GPU side many times means better performance, as memory bandwidth is one of the bottlenecks, and because many times extracting operations (e.g. 10_10_10_2 -> 4 x float) are non-cost.

速度の向上は、重なっている頂点がそれほど多くない場合、速度の違いはおそらく目立ちません。しかし、私は私の意見を支持するために(インデックスを使用するために)難しい事実を本当に持っていません。


これも見てください。

https://stackoverflow.com/questions/17503787/buffers-indexed-or-ダイレクトインターレースまたはセパレート

3
追加された
1)キャッシュのパフォーマンスのためにインデックスの順序を最適化することについてはどうですか。これにもアルゴリズムがあります。 kキャッシュの並べ替えと同じです。 3)インデックスバッファ自体のオーバーヘッドについてはどうですか?トリストリップするとアップロードするデータが少なくなることがありますが、一般的なことではありません。
追加された 著者 Pat Farrell,

私の考えでは、頂点にインデックスを使用すると遅くなります。

私は最初の質問を誤解しました、しかしここにカラーインデックスのための答えがあります。同じ規則が頂点の索引付けにも当てはまると思いますが(精度を失うことなく)、それは単なる推測です。

しかし...

  • 原則として、インデックス作成をお勧めします。
  • インデックス作成が遅くなります。
  • インデックスを作成しないほうが速いです。
  • インデックス作成はメモリ効率がよくなります。
  • インデックスを作成しないと、メモリ効率が低下します。
  • インデックスを作成すると色の精度が失われます。
  • インデックスを作成しなくても色の精度は失われません。

72バイトは非常に小さいため、インデックスを作成しない方がおそらくメモリ効率が高くなります。

いくつかの経験則: 索引付けはメモリー効率がよくなります。 インデックス付けは色精度を失います。 索引付けしない方が速いです。

これはあなたが決して索引付けを使わないことを望むかもしれませんが、メモリのトレードオフはまともなサイズの画像にとってかなり重要です。色精度は目立たないです。

インデックスが機能する方法は、ピクセルを描画するときにインデックスが与えられ、所定のサイズのテーブルで色を調べなければならないことです。 (256バイトとしましょう。ですから256色に制限されています)。それからそのピクセルを描画します。インデックスを作成してもピクセルデータが直接保存されないため、色数が256に制限されることはありません。

免責事項、私は私の帽子からこれらの数字を引き出しています。

1
追加された
色圧縮については尋ねませんでした。
追加された 著者 Eytan Levit,
テクスチャ圧縮ではなく、頂点のインデックス付けについて話しています。例えば、あなたはv0、v1、v2、v、3を持っています。 2つの三角形を描くには、0、2、3、0、2、4のインデックスを指定します。
追加された 著者 Eytan Levit,
非常に短い答え:索引付けは常に遅くなります。私は答えをそこに埋めました、しかしそれを最初の行に追加しました。それがカラー圧縮に入りました。
追加された 著者 Sergiu Damian,
ああ、私の間違い。その場合私は知りませんが、私は同じ経験則が適用されると思います(解像度の損失を差し引く)。
追加された 著者 Sergiu Damian,

位置が常に同じ場合は、配列をシェーダに格納し、 gl_VertexID を使用して頂点シェーダの頂点を選択することで、バッファなしで実行できます。

#version 330 core

const vec3 data[4] = vec3[]
(
//Triangle 1
vec3(1,1,0),
vec3(1,0,0),
vec3(0,0,0),

//Triangle 2
vec3(1,0,0),
vec3(0,1,0),
vec3(0,0,0)
);

void main()
{
  gl_Position = vec4( data[ gl_VertexID ], 1.0);
}
1
追加された
@ratchet freak Positionsは地形のため常に同じとは限りません(そしてボクセルベースであるため、triangle_stripsは適切に実装するのが非常に難しいため、使用できません)。私は単にインデックス描画と非インデックス描画のどちらを使うべきかを知る必要があります。あるいは、古いディスプレイリストでも、それが早ければ速いでしょう。
追加された 著者 Eytan Levit,
@KaareZあなたはまだ位置を変更するために制服を使うことができます。または、インスタンス化して面ごとのデータを渡すこともできます。
追加された 著者 kprobst,
インスタンス化でレンダリングすると、インスタンスごとにポイント、回転、スケールを設定できます。
追加された 著者 Tovin,

他のすべてのパフォーマンスと同じように、推測してプロファイルを作成してください。

それはハードウェアと非常に多くの複雑な要因によって変わります。プロファイリングによってそれを測定することは、あなたがそれらについて何かを知る必要なしに自動的にあなたのためにこれらすべてのことを考えます。

0
追加された