インデックス描画は非インデックス描画よりも高速です


8

6つの頂点(2つの三角形)からなる多数のポリゴンを描画する必要があります。

テクスチャ座標、法線などがない場合、どちらのアプローチでも72バイトになります。将来的には、テクスチャ座標と法線も間違いなく必要になります。これにより、インデックスの描画で消費されるメモリが少なくなります。それほど多くはありません。

だから私の質問は:頂点の重なりが少ないVAOの場合、どちらのアプローチがより速いですか?インデックス以外の描画で消費される余分なメモリは気にせず、速度のみを気にします。

編集:明確にするために。

非索引アプローチ:

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
};

1
...なぜターゲットハードウェアで特定のアプリケーションの両方のアプローチを測定して、最終的に確認しないのですか?
Sean Middleditch、2015年

回答:


4

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

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

2)インデックス付けにより、GPU頂点キャッシュは、重複する頂点に対してこれらのいくつかの最適化を行うことができます。

3)メモリ帯域幅がボトルネックの1つであり、抽出操作(例:10_10_10_2-> 4 x浮動小数点数)が非コストであるため、GPU側のメモリフットプリントが何度も小さいことは、パフォーマンスの向上を意味します。

速度が向上する可能性のある頂点の重なりが少ない場合、速度の違いはおそらく目立ちません。しかし、私は本当に自分の意見を裏付けるための難しい事実はありません(インデックスについて言えば)。


これも見てください:

/programming/17503787/buffers-indexed-or-direct-interlaced-or-separate


1
re 1)キャッシュのパフォーマンスのためにインデックスの順序を最適化するのはどうですか?これにもアルゴリズムがあります。kキャッシュの並べ替えと同様です。re 3)インデックスバッファ自体のオーバーヘッドはどうですか?トライストリッピングを行うと、アップロードするデータが少なくなる場合があります。
jheriko 2015年

1

位置が常に同じである場合は、配列をシェーダーに格納し、を使用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);
}

また、インスタンス化してレンダリングする場合、インスタンスごとにポイント、回転、スケールを設定できます。
Lasse

@ratchet freakフリークの位置は常に同じとは限りません。これは地形の場合です(ボクセルベースであるため、適切な方法で実装するのが非常に難しいため、triangle_stripsを使用できません)。インデックス描画と非インデックス描画のどちらを使用するかを知る必要があるだけです。または、古いディスプレイリストの方が高速な場合でも。
KaareZ 2015年

@KaareZユニフォームを使用して位置を変更することもできます。または、インスタンス化を使用して、面ごとのデータを渡します。
ラチェットフリーク

0

すべてのパフォーマンスのことと同様に、推測せずに、プロファイルして調べてください。

ハードウェアや非常に多くの複雑な要素によって異なります。プロファイリングによって測定すると、それらについて何も知る必要なく、自動的にこれらすべてのことを考慮します。


-1

私の仮定は、頂点にインデックスを使用すると遅くなるということです。

私は元の質問を誤解しましたが、ここにカラーインデックスの答えがあります。同じ規則が頂点のインデックス付けに適用されると思います(精度を失うことはありません)が、それは単なる推測です。

だが...

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

72バイトは非常に小さいので、インデックスを付けない方がメモリ効率がよくなります。

いくつかの経験則:インデックス付けは、よりメモリ効率が高くなります。インデックスを作成すると、色の精度が失われます。インデックスを作成しない方が高速です。

これにより、インデックスを使用したくない場合がありますが、適切なサイズの画像の場合、メモリのトレードオフはかなり重要です。色の精度は目立ちません。

インデックス作成のしくみは、ピクセルを描画するときにインデックスが与えられ、所定のサイズのテーブルで色を検索する必要があるというものです。(256バイトとしましょう。256色に制限されています)。次に、そのピクセルを描画します。インデックスはピクセルデータを直接保存しないため、256までのカラー制限はありません。ただし、100x100の画像では、400ishバイトの画像は10000バイトになります。

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


色圧縮については尋ねませんでした。
KaareZ 2015年

非常に短い答え:インデックス作成は常に遅くなります。私はそこに答えを埋めましたが、最初の行にそれを追加しました。今度は、それがインデックス付けであるので、色圧縮に入りました。
Evorlor 2015年

テクスチャの圧縮ではなく、頂点のインデックスについて話しています。たとえば、v0、v1、v2、v3があるとします。2つの三角形を描画するには、次のインデックスを指定します
。0、2、3、0、2、4

ああ、私の間違い。その場合はわかりませんが、同じ経験則が適用されると思います(解像度の損失を差し引いたもの)
Evorlor
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.