回答:
イマレットの答えに加えて、シェーダー内の異なるテクスチャデータへのアクセス数を増やすと、GPUキャッシュへの圧力が高まることは事実ですが、効果に大きく影響する可能性のある他のいくつかの要因があります。また、CPUキャッシュのように、GPUに複数のキャッシュレイヤーが存在する可能性があるという事実により、複雑になる可能性もあります。テクスチャユニット<= L0 <= L1 <= ..メモリ
パースペクティブや単純なスケーリングによるテクスチャデータの縮小化があるシーンがあり、MIPマッピングを使用していない場合は、エイリアシングが発生します。これは視覚的なアーティファクトを生成するだけではありません。パフォーマンスの問題である可能性が非常に高いです。
エイリアシングを取得するとすぐに、テクスチャへのアドレスアクセスは一貫性がなくなり、キャッシュをスラッシングするだけでなく、コストがかかる可能性のある多くのDRAM "ページブレーク"（より正確には、行ブレーク）を引き起こします。MIPマッピングは、インコヒーレンシの低減に役立ちます。
おそらく少し明白なオプションかもしれませんが、テクスチャ圧縮（例：DXTn | ETC * | PVRTC * | etc）を8bppから2bppまでターゲット設定できる場合は、次の方法でメモリ帯域幅/キャッシュの効率を大幅に向上できます。 4倍から16倍までの係数。現在、すべてのGPUについて話すことはできませんが、一部のテクスチャ圧縮スキーム（上記のリストなど）はハードウェアでデコードするのが非常に簡単で、データはキャッシュ階層全体で圧縮されたままで、テクスチャユニットでのみ圧縮解除されます。これらのキャッシュのサイズを効果的に乗算します。
明らかに、一部のデータ、たとえば後続のレンダリングでテクスチャデータとして使用されるレンダーターゲットは、テクスチャ圧縮を使用できません。可能な限り、最小のピクセル形式を使用してください。つまり、32 / 16bpp（A）RGBで可能な場合は、4x32浮動小数点形式を使用しないでください。
これは、上記のエイリアシングの例にいくらか関連していますが、大きなレンダーターゲットが作成され、非常にまばらにしかサンプリングされないケースを見てきました。キャッシュラインは、CPUでもGPUでも非常に長いため、各キャッシュラインで1ピクセルのみを使用している場合は、転送が無駄になります。
また、WRT圧縮テクスチャは、テクセルのローカル領域間でデータを効果的に共有することで圧縮を実現します。コヒーレントなアクセス権がない場合は、メモリフットプリントの削減は別として、圧縮はおそらく役に立ちません。
キャッシュの問題はそれほどではありませんが（計算されたアクセスが完全に矛盾しない限り）、頂点で提供されるUV座標によって直接定義されていないテクスチャアクセスは、直接定義されているものよりも遅くなる可能性があります。
最近のほとんどのテクスチャーはタイルまたはモートンのような（別名Twiddled / Swizzled）順序（または両方の組み合わせ）で保存されると思われますが、一部のテクスチャーはスキャンラインの順序のままになる可能性があります。テクスチャは、かなりの数のキャッシュミス/ページブレークにつながる可能性があります。残念ながら、私は特定のフォーマットがそのように配置されているかどうかを見つける方法を本当に知りません。
（背景を読むには、BlinnのThe Truth About Texture Mapping。FWIWを試してください。いくつかのステップを踏むと、少なくとも初期のPCハードウェアでTwiddled-order（つまりMorton Order）テクスチャが使用されるようになります）。