正方形をレンダリングしたいとしましょう。そのテクスチャは「square.png」です。
テクスチャが単純な色である場合、コンピューターがレンダリングするのは簡単ですか？
そして、あちこちで完全にランダムな色の非常にノイズの多いテクスチャである場合はどうでしょうか？
または、そのテクスチャが、そのピクセルがすべて少しずつ異なるという意味でノイズが多い場合はどうでしょうか？
正方形をレンダリングしたいとしましょう。そのテクスチャは「square.png」です。
テクスチャが単純な色である場合、コンピューターがレンダリングするのは簡単ですか？
そして、あちこちで完全にランダムな色の非常にノイズの多いテクスチャである場合はどうでしょうか？
または、そのテクスチャが、そのピクセルがすべて少しずつ異なるという意味でノイズが多い場合はどうでしょうか？
回答:
ゲーム開発、特にゲームグラフィックスのほとんどのものと同様に、答えは「依存します」です。
テクスチャの解像度は、レンダリング速度に影響を与える可能性があります。含まれるピクセルが多いほど、GPUにアップロードする生データが多くなり、キャッシュに一度に収まるテクスチャが少なくなるため、シェーダーはテクスチャの適切な部分を待機する間、より多くの一時停止をヒットする可能性がありますキャッシュにプルされます。
ミップマッピングを使用すると、この影響を減らすことができます。ミップマップを使用すると、縮小されたテクスチャのチェーンが保存されます。これは、最初はもっと多くのメモリを使用するように聞こえます。しかし、画面上に小さなサイズでテクスチャが表示されている場合（遠近の遠方のオブジェクトのように）小さいバージョンから読み取ることができるため、サンプルはジャンプするよりもテクスチャキャッシュをより有効に活用します。これにより、エイリアシングも減少します。
テクスチャのコンテンツは、ほとんどの場合レンダリング効率に影響しません。
色は、GPUに関する限り単なる数字の集まりであるため、それらの数字が何であるかはあまり気にせず、同じ方法で計算に集中させます。「ああ、前にこの緑のピクセルを見たことがあります。前回この入力を見たときに計算したのと同じ出力を再利用します」ということを覚えているような凝ったものはありません。またはランダムに輝き、あなたのGPUは同じ仕事をしています。
画像の予測可能な領域でより効率的に圧縮し、複雑な領域でより多くのビットを消費するPNG＆JPGなどの形式とは異なり、BTC、ETC、PVRTC、または生のRGBAなどのGPUテクスチャ形式は、ブロックごとに固定ビット数を使用しますピクセル。そのため、同じ圧縮形式を維持しながらテクスチャを多少詳細に作成しても、データサイズが変更されたり、データ転送やキャッシュ関連の効率に影響を与えたりすることはありません。
ただし、以前の圧縮では適切に保存されない特定の種類の詳細を使用すると、画像全体を変更して別の形式を使用するように強制され、データサイズが再び変更される可能性があります。
状況における最大のアスタリスクは次のとおりですif()。分岐のように、このテクスチャカラー入力を使用して決定を下すことができます。ここでは、速度が重要です。
GPUシェーディングユニットはピクセルのブロックでバッチ処理され、複数のデータストリームで同じ命令を並行して実行します。したがって、ブロック内の一部のピクセルが一方のブランチをif取り、他のピクセルがもう一方のブランチを取る場合、バッチ全体が両方のブランチを通過する必要があります（ピクセルのセットに適用されない結果をマスクします）
入力がスムーズ/予測可能な方法で変化する場合、単一の分岐のみを必要とする多くのブロックが存在する可能性が高く、これらの両方の分岐のケースは遷移境界の周りの狭いバンドに制限されます。ただし、入力がランダムである場合、ほとんどのブロックが両方のブランチを使用し、レンダリングが遅くなると予想されます。
これは、1つのテクスチャを使用して、歪みマップやインデックスマップなど、2番目のテクスチャへのルックアップを制御している場合にも発生する可能性があります。最初のテクスチャがランダムに飛び回る場合、2番目のテクスチャの散らばったランダムなスポットからサンプリングし、テクスチャキャッシュの一貫性のない使用を行い、平均して必要なデータを取得するのを長く待ちます。
全体として：いいえ、テクスチャのコンテンツはレンダリング速度に大きな影響を与えませんが、そうする場合を除きます。;）
nth番目のピクセルを取得しようとすると、その前にすべてのピクセルを処理する必要があります。ピクセルのバイト幅が一定の場合start_of_buffer + width * n、それはちょうどであり、特にlargeの場合ははるかに高速nです。
上記のDMGregoryの優れた答えに加えて、おそらく、「テクスチャ」の複雑さがレンダリングパフォーマンスに影響を与える可能性のあるケースが1つあります。つまり、前のレンダリングの結果が後続のソース/ reflections / environmentマップ。
一部の最新のハードウェアは、これらのバッファーにロスレス圧縮を適用する場合があります。たとえば、PowerVRにはPVRIC、AMD、Delta Color Compressionがあり、ARMには同様のものがあります。これらの圧縮技術の目的は、全体的な帯域幅を削減することであり、これによりレンダリングパフォーマンスが向上します。
深さや色（整数または浮動小数点）がデータであるほど、これらのスキームはうまく機能します。もちろん、これらをより良く機能させるためにレンダリング出力を意図的に単純化することはお勧めしませんが、状況によってはノイズの多いデータの使用を避けることが役立つ場合があります。
また、これらのスキームを使用するフレーム/深度バッファのスパースサンプリングを行うと、帯域幅を低くしようとしても無駄になりますが、ブロックベースである可能性が非常に高いため、役に立ちません。
さらに、これら2つのSE Computer Graphicsの質問と関心のある答えを見つけることができます。