フラグメントシェーダーでテクスチャ座標を計算すると、テクスチャへのアクセスがはるかに遅くなるのはなぜですか？

GLSLでテクスチャを使用する場合、頂点シェーダーで最終的なテクスチャ座標を計算し、varyings を使用してそれらをフラグメントシェーダーに渡すのが最善です。y座標の単純な反転の例：

// Vertex shader
attribute vec2 texture;
varying highp vec2 texCoord;
// ...
void main() {
    texCoord = vec2(texture.x, 1.0-texture.y);
    // ...
}

// Fragment shader
varying highp vec2 textureCoordinates;
uniform sampler2D tex;
// ...
void main() {
    highp vec4 texColor = texture2D(tex, texCoord);
    // ...
}

Y座標の反転、またはvec2(0.5)テクスチャ座標への追加などのさらに単純な操作がフラグメントシェーダーで実行される場合、テクスチャアクセスは非常に遅くなります。どうして？

注意として、たとえば、2つのテクスチャをブレンドして、それらの加重和を使用すると、時間の点ではるかに安価であり、各ピクセルに対して実行する必要があるため、テクスチャ座標自体の計算はそれほどコストがかかるとは思われません。

あなたが話していることは、モバイル開発コミュニティでは一般に「依存テクスチャ読み取り」と呼ばれています。これは特定のハードウェアの実装の詳細であるため、実際にパフォーマンスに影響があるかどうかはGPUに依存しています。イマジネーションとAppleの両方で明示的に言及されているため、通常、これはAppleハードウェアのPowerVR GPUで取り上げられたものです。ドキュメンテーション。私が正しく思い出した場合、問題は基本的に、フラグメントシェーダーが実行を開始する前にテクスチャのプリフェッチを開始するGPUのハードウェアに起因していたため、レイテンシーを隠蔽するのに優れています。私がリンクしたドキュメントは、それがSeries6ハードウェアの問題ではなくなったことを述べているので、少なくとも新しいAppleハードウェアでは、心配する必要はありません。他のモバイルGPUについては正直に定かではありません。それは私の専門分野ではないためです。確実に確認するには、それらのドキュメントを参照してください。

この問題についてGoogle検索を行う場合は、古いデスクトップハードウェアでの依存するテクスチャフェッチについて話している古い資料が見つかることに注意してください。初期のピクセル/フラグメントシェーダーの基本的な用語である「依存テクスチャフェッチ」は、以前のテクスチャフェッチに依存するUVアドレスを使用することを指していました。古典的な例は、バンプマップされた環境マップレンダリングで、環境マップをサンプリングするために、法線マップに基づく反射ベクトルを使用したいと考えていました。この古いハードウェアでは、パフォーマンスに大きな影響があり、非常に古いGPUでもサポートされていなかったと思います。最新のGPUでは、ハードウェアとシェーダーISAがはるかに一般化されているため、パフォーマンス状況ははるかに複雑です。