Exoskeleton

ということで、Exoskeletonである。基本的な発想は、ApplicationからDeviceにもっと簡単にアクセスできるようにすることで、Latencyを減らしたいという発想である。具体的に言えば、Runtime経由でUser ApplicationがDeviceに直接アクセスすれば、余分なOverheadが最小限に抑えられる、という発想だ(Photo15)。ただ、だからといって既存のStandardを無視するわけにはいかないし、特定のベンダーに依存したインプリメントをすると応用が利かなくなる(Photo16)。

Photo14:Graphicsに関して言えば、ここにDirectXなりOpenGLなりというAPIが標準で入り、これをアクセスする形である程度は実現してきた。ただDirectXにせよ、OpenGLにせよ、最終的にはDevice Driverが動いているから、Todayの"Lower overhead interaction for graphics"はちょっと言い過ぎではないかとも思う。

Photo15:勿論これはDevice DriverからDeviceへのRuntimeアクセスを全てUser Applicationに移すという意味ではないだろう。

Photo16:これが全て実現できれば勿論問題無いのだが、現実にはトレードオフが発生するのはご存知の通り。付け加えるならISVのサポート、もっと具体的に言えばMicrosoftがこれをサポートすることも、過去の歴史を見ると必須な気もするのだが。

さて、具体的な実装である。通常CPUとAcceleratorが混在する環境では、Accelerator用のロジックを別に組んでおき、これはこれで勝手にローダ等を使って流し込んで実行しておき、CPU上からI/Oポートなどを経由してパラメータを渡し、結果を受け取るといった手法が一般的だったのはご存知の通りである(Photo17)。これをPhoto18ではDomain Specific Programmingと呼んでいるが、このDomain Specific Programmingの代わりにIntelが新たに提案しているのが、一番右のDirect Programmingである(Photo19)。このDirect Programmingでは、Photo20の様なアクセスを実現することになる。要するにApplicationやLibrary/Runtimeから、直接Acceleratorを叩ける仕組みだ。

Photo17:これはこの手のプログラムを書いたことがある人ならおなじみの方法。クロスコンパイラを使ったマルチプラットフォームなども似た形になる。

Photo18:まぁこれは誇張している部分も多いから、全てが全てに当てはまる訳ではないが、一般論としてこうした問題がDomain Specific Programmingに存在するのは事実である。

Photo19:要するにAddress空間の共有やData Modelの一致、Request/Replyの埋め込みなどを行えば、x86命令と同列に扱えますという、それだけの話といえばそれだけの話である。

Photo20:これとPhoto13を見比べると、一体どこにCPUとAcceleratorを仮想化してまとめて扱える仕組みが組み込まれているのか、全然判らないという話もある。要するにPhoto13はあくまでもConceptである、という事だ。

まずMemoryの共有化だが、これはPCI ExpressのIOVに含まれるATS(Address Translation Services)を使うことで、AcceleratorがMapするMemory AddressとCPU(というか、そのApplicationが動くProcessのVirtual Memory Address)を重ねる形で実現する(Photo21)。

Photo21:ここで初めてPage Faultとかpause/resumeが繋がってきた。User Modeの様なケースでは、User ProcessがPage Outされる可能性もありうるわけで、こうしたときにI/O側からもPage Fault要求を出せるようにしないと、いつまでもI/O開始待ちになってしまうことになる。pauseは、Page faultを確認してからPage Inが済むまでの間I/Oを待たせるため、resumeはPage Inが済んでI/Oを再開するために使う、とここでは理解できる。