さまざまな方法でGLSLシェーダにテクスチャ座標を渡す賛否両論について議論しています。テクスチャ座標と最適化GLSLシェーダ
私は多くのインスタンスデータをレンダリングしています。私は基本的なモデルを1つ持っており、変換マトリックスとテクスチャ/スプライトインデックスをシェーダに渡します。各モデルは、その後、回転変換行列ごとに翻訳され、テクスチャは、このスニペットに従って決定される：
TexCoord0 = vec2(TexCoord.x+(TexIndex%16),TexCoord.y+(TexIndex/16))/16;
私はこれについて好きではない事は、私はスプライトをハードコーディングされたことで、テクスチャサイズ。私は制服を使ってこの情報を渡すことができましたが、スプライトがインスタンスごとに変わることができないという制限があります（これは計画されたユースケースがありません）。さらに、スプライトの座標を決定するためにGPUをもう少し計算する必要があります。
私が使用できる別の方法は、テクスチャマップ内のスプライトの位置、幅、高さを区切るRect全体を指定することです。しかし、これには単一のテクスチャインデックスバイトではなく、4フロート（16バイト）の情報を指定する必要があります。例えば200Kのインスタンスでそれを掛け合わせると、（他のデータに加えて）約3MBのデータがあります。私はそれが今日の年齢の中で「たくさん」とみなされるかどうかわかりません。
GLSLシェーダの計算を簡単にする、またはバッファのサイズを最小限にすることに焦点を当てるべきですか？データをGPUに転送することはしばしばボトルネックですが、バッファにデータを再合成することは、各フレームをレンダリングする必要がある頂点の数と比較することはめったにありません。
同様に、私は私のモデル変換行列を取り出して、それぞれ平行移動と回転のためvec3とvec2に置き換える検討しているに16台のフロートから私をノックダウンだろう（私は回転のみの2度を必要とします） 5、次に頂点シェーダのマトリックスを再構築することができます。繰り返しますが、これはいくらかの柔軟性を取り去り、私はコスト削減を確信していません。
興味のあるハードウェアに座ってプロファイリングすることなくこの質問に答える方法はありません。それは悪い質問ではありません。ハードウェアからハードウェアまで、実装ごとに問題が変わることは間違いありません。ハイエンドマシンでは、1つの方法が高速になる可能性がありますが、もう1つはローエンドマシンでは高速になる可能性があります。 AMDのFusion CPU/GPUでは、バッファ帯域幅が個別のGPUよりもはるかに悪い可能性があります。あるいは、個別のGPUのDMAオーバーヘッドによって、Fusionチップがこれに理想的になる場合があります。それをプロファイリングせずに確実に知る方法はありません。 –