ワープスケジューラの仕組み

ワープスケジューラ(Warp Scheduler)

図3-39は、Kepler GK110 ArchitectureのWhite Paperに載っている図であるが、Warp Schedulerは次に実行を開始するワープを取り出し、Dispatcherはそのワープ(を含むスレッド)の連続する2命令を実行パイプラインに発行して行く。ワープの選択回路は複雑であるので、これは4個だけにして、連続した命令が実行できるケースはDispatcherで2命令を発行するという方法で、8命令を発行するハードウェアを簡単にしようという設計であると考えられる。

図3-39では最初にワープ8の命令11と12が発行され、次にワープ2の命令42と43が発行され、その次のワープ14の命令95と96が発行されている。そして、他のワープの命令発行がしばらく続いて、ワープ8の命令13と14が発行されている。NVIDIAのドキュメントでは、演算結果が次の演算の入力として使えるようになるのに必要な時間は、Compute Capability(後述)が1.xと2.xのGPUでは22サイクル、3.xのGPUでは11サイクル(これは典型的なケースであり、命令によってこの値は変わる)と書かれている。

なお余談であるが、このサイクル数の違いは、Fermiまではパイプラインを細分化してクロックを上げて性能を稼ぐ設計であったのであるが、Keplerでは消費電力を抑えるため、パイプラインの段数を半減してクロックを下げる設計に変更したことが主因と考えられ、基本的な処理ユニットの演算時間はあまり変化が無いと思われる。

つまり、ワープ8の命令11、12と命令13、14の間に他のワープの命令が10～20命令あれば、命令13、14の実行を開始する時点では、命令11あるいは命令12の演算は終わっており、命令13、14は待ち時間なしに実行を開始することができる。

10～20命令を確保できず、命令13、14が開始できない場合は、他に実行可能なワープがあれば、それを先に実行するので、直ちに命令の発行が止まるわけではない。

このように、どのような命令が使われているか、どの程度の比率の命令が直前の命令の演算結果に依存するのかなどによって違ってくるのであるが、NVIDIAは、高い実行効率を維持するためには、SMあたり1700スレッド(53ワープ)程度を分担させることを推奨している。これは各ワープスケジューラに13ワープを分担させる必要があり、1つのワープスケジューラが扱えるワープ数の上限が16であることを考えると、かなり高いハードルである。

なお、メモリのアクセスは、CC 1.xと2.xのGPUでは400～800サイクル、CC 3.xのGPUでは200～400サイクルとなっており、最大16ワープの切り替えではメモリレーテンシは隠すには不足である。従って、メモリをアクセスするワープはしばらくお休みとなり、ワープスケジューラが担当する残りのワープを切り替えて実行することになる。

ブロックのスレッド数を大きくすると、レジスタ数やシェアードメモリ容量の制約で、2ブロックは入るが3ブロックは入らないということが起こり空きが出やすいので、NVIDIAは128～256スレッド程度のブロックを使うことを推奨している。128スレッドのブロックで、1700スレッドを1つのSMに入れようとすると、約13ブロックをSMに割り当てることになり、15SMのGK110チップの場合、最低でも、約200ブロックを含むグリッドが必要になる。

一般に、連続した2つの命令は同時に発行できるケースが多いと思われるが、それらのワープの命令の入力オペランドが揃っていない場合は命令を発行できないし、LD/ST命令が連続している場合などの実行ユニットが足りない場合には、命令を発行できない。

連続した2命令を発行できる場合は、4個のワープスケジューラで8命令演算ユニットに発行できる。一方、演算ユニットから見ると、192個のCoreを動かすには6命令が必要であり、残りの2命令で、ロードストアユニットやSFUなどを動かすことになる。倍精度浮動小数点演算を行うDPユニットは特別で、各オペランドのアクセスに32bitのポートを2つ必要とするので、これによる命令発行制約が出てくる。