テクスチャキャッシュを介してデータをロードするようにコードを書き直すのは理にかなっていますか（フィルタリングや他のテクスチャユニットオプションが必要ないと仮定して）、それとも同じですか？L1キャッシュとトラフテクスチャリングユニットを介してデータをロードするのはどうですか？私はそのような戦略を使用できるコードを持っていますが、それはまったく意味がありますか？
明確にするために、私は「FERMIのテクスチャキャッシュはL1キャッシュハードウェアとは別のハードウェアですか」という意味でした。つまり、コードのL1 +テクスチャキャッシュボリュームの合計を巧みに取得できますか？
それは別です。テクスチャロードはL1を通過しません。テクスチャリング以外のアプリケーション（つまり、補間やクランプなどの機能を使用していない）の場合、テクスチャリングの主な利点は、中断することなく、潜在的にキャッシュできる（局所性と再利用を想定して）大量のグローバルメモリを選択的に追加できることです。 L1で何が起こっているのか。小さなデータセットの場合、テクスチャリングはL1よりも優れたパフォーマンスを提供しません。ある程度の局所性と再利用があるが、テクスチャキャッシュによってカバーされる領域からの負荷が、L1（キャッシュ構成によっては、FermiのSMあたり16KB程度）をスローする可能性がある大規模なデータセットの場合、テクスチャキャッシュは、アプリケーション全体にメリットをもたらします。テクスチャの使用がそうではないことをユーザーが体験することは珍しいことではありません。物事をL1にキャッシュできるのと同じくらい高速ですが、キャッシュされていないロード、またはL1を破壊する分散ロードよりもはるかに高速です。多くは、関連するデータのアクセスパターンとサイズに依存します。テクスチャキャッシュのサイズは、SMあたり約8KBです。はるかに大きな領域をキャッシュできますが、高レベルの再利用と局所性により、テクスチャキャッシュのパフォーマンスが確実に向上します。また、テクスチャメモリは読み取り専用であることに注意してください。あなたはこれに興味があるかもしれません また、テクスチャメモリは読み取り専用であることに注意してください。あなたはこれに興味があるかもしれません また、テクスチャメモリは読み取り専用であることに注意してください。あなたはこれに興味があるかもしれませんウェビナー。