Fermi アーキテクチャ GPU の個人的なメモ

参考記事:
CUDA C++ プログラミング ガイド
NVIDIA の Fermi the First Complete GPU アーキテクチャ
パフォーマンスの最適化: プログラミング ガイドラインと GPU アーキテクチャの理由
Nvidia GPU アーキテクチャ – Fermi アーキテクチャ
のメモ コンピュータ構成の原則 – GPU グラフィック プロセッサ
GPU (SIMT) に関するメモ
NVIDIA GPUアーキテクチャレビュー
CUDAプログラミング学習記-02(GPUハードウェアアーキテクチャ)
GPUに対応したコンピューティング能力を確認する
私の構成は以下の通りです。
ここに画像の説明を挿入します

1 GPU ハードウェア アーキテクチャ

ここに画像の説明を挿入します
ここに画像の説明を挿入します
ここに画像の説明を挿入します

  • ホストインターフェイス: PCI-Express経由でGPUをCPUに接続します。
  • ギガ スレッド/ギガ スレッド エンジン: グローバル スケジューラは、スレッド ブロックを SM スレッド スケジューラに分配します。

この切り替えはチップ レベルの GigaThread ハードウェア スレッド スケジューラによって管理され、16 のカーネルにわたる各ストリーミング マルチプロセッサの 1,536 個の同時にアクティブなスレッドを管理します。
この集中スケジューラは、従来の CPU 設計からのもう 1 つの出発点です。マルチコアまたはマルチプロセッサ サーバーでは、単一の CPU が「担当」することはありません。オペレーティング システムのカーネル自体を含むすべてのタスクは、利用可能な任意の CPU 上で実行できます。このアプローチにより、Linux のような大規模なモノリシック カーネルから QNX のマイクロカーネル設計、Windows 7 のようなハイブリッド設計まで、各オペレーティング システムがカーネル設計の異なる哲学に従うことができます。しかし、このアプローチの汎用性は、複雑な CPU を必要とするため、弱点でもあります。はるかに単純なハードウェアでも処理できる機能の実行に時間とエネルギーを費やす必要があります。
Fermi を使用すると、対象となるアプリケーション、ストリーム処理の原理、カーネルとスレッド モデルがすべて事前にわかっていたため、より効率的なスケジューリング方法を GigaThread エンジンに実装できました。

  • SM (ストリーム マルチプロセッサ): 画像の黒いボックスと右の拡大図に示すように、32 個のコア (Cuda Core) があります。
    • コア (Cuda Core): ベクトルの実行単位であり、各コアには整数演算ユニット ALU (Integer Arithmetic Logic Unit) と浮動小数点演算ユニット FPU (Floating Point Unit) が含まれます。
    • ファイルの登録: ファイルの登録
    • SFU (Specil Function Units): 特殊関数単位、超越関数、数学関数 (逆平方根、サインとコサインなど)
    • ワープ スケジューラ: スレッド ワープ スケジューラ、スレッドを特定のコンピューティング ユニットに割り当てます。
    • ディスパッチユニット:命令分配ユニット
    • LD/ST (ロード/ストア): ストレージ ユニット (データ処理を担当) にアクセスし、サイクルごとに 16 スレッドのソース オペランド アドレスとデスティネーション オペランド アドレスを計算します (LD/ST が 16 個あるため)。GMEM、SMEM、LMEM のアクセス

Cuda Core の前にはSP (Stream Processor)という概念もありましたが、これは実際には Cuda Core でしたが、Fermi アーキテクチャから SP は Cuda Core と改名されました。

その後新たに廃止されたアーキテクチャでは、同じ SM 内に異なるタイプのコアが配置されることになり、たとえば、Volta アーキテクチャからは、同時実行のサポートを強化するために、INT32、FP32、Tensor コアになりました。
Cuda Core の概念は徐々に薄れ、代わりに、より詳細なコア タイプの分割が行われています。

新しく開始されたアーキテクチャでは、各 SM には、テクスチャおよび読み取り専用 GMEM へのアクセスに使用される複数のTex も付属しています。

  • ワープ スレッド バンドル: ワープは単一 SM 内のディスパッチの基本単位です (ワープは SM の基本実行単位です)。ワープには 32 個の並列スレッドが含まれます (現在のすべての GPU アーキテクチャにはこの数があるようです。ワープサイズを渡すことができます)カーネル関数が取得されると)、これらの 32 個のスレッドは SIMT モードで実行されます。つまり、すべてのスレッドはロックステップ方式で同じ命令を実行しますが、各スレッドは独自のデータを使用して命令分岐を実行します。

ワープ内に動作する必要のある 32 のスレッドがない場合、ワープ全体としてはまだ実行中ですが、スレッドのこの部分は非アクティブ状態になります。

SM では、ワープは特定の命令に分割され、実行するコンピューティング ユニットに与えられます。

個人的な理解: SM の下には複数のコアがありますが、コアは実行可能なスレッドを表しません。同じ SM の下のコアの数は、並列スレッドの最大数を表しません。SM スケジューラは、コアが実行できるようにスケジュールされるだけです。コアは、すべてのコアをより完全に利用して効率的に実行できるように命令を実行します。一般に、
ハードウェアのパフォーマンスを最大化するために、スレッド ブロック内のスレッドの数は通常、スレッド ワープの整数倍になります (絶対的なものではなく、特殊な状況があります) ))

2 Cuda と GPU ハードウェア アーキテクチャの関係

この写真はステーション b のビデオからのものです。
ここに画像の説明を挿入します
ここに画像の説明を挿入します
これは、共有メモリがブロック (__shared__変更された変数の定義によって作成された)内の共有メモリに対応していることを非常によく説明しています。

  • SM は 1 つ以上のブロックを保存できます。保存されるブロックの数は、(1) 共有メモリとレジスタの制限、(2) SM 上のスレッドとブロックの数の制限などのいくつかの要因によって異なります。
  • SM に保存されているすべてのブロックについて、関連するコンテキストは固定の場所に保存されます (CPU とは異なることに注意してください)。たとえば、共有メモリは常に共有キャッシュに配置され、その後も共有メモリに配置されます。スレッドの切り替え (つまり、スレッドの切り替えは CPU よりもオーバーヘッドが少ない)
  • 複数のブロックを SM に保存できますが、ブロックがスケジュールされている場合、ブロックは最後まで実行されます (CPU のようなタイム スライスのローテーションはありません)。
  • SM は、一度に 1 つ (以前の GPU) または少数 (最近の GPU) のワープ (32 スレッド) のみをスケジュールでき、SIMT の原理に基づいて、一度に 1 つの命令を実行します。
  • Warp のスケジュール設定を通じて遅延を非表示にする

確かにスレッドスケジューリングとブロックスケジューリングに関しては関連する命令が非常に少なく、矛盾する部分もあるため、上記の内容はほぼ私がまとめたものですが、間違いがあればご指摘ください。

おすすめ

転載: blog.csdn.net/xxt228/article/details/131882716