後藤弘茂のWeekly海外ニュース
バーチャルリアリティを加速するAMDのPolarisアーキテクチャ
2016年7月12日 06:00
ハイプライオリティタスクのスケジューリングが高速に
AMDは、新GPU「Radeon RX 480」で採用したPolarisアーキテクチャで、GPUのフロントエンドの制御プロセッサ群を強化した。コマンドプロセッサとACE(Asynchronous Compute Engine)に加えて、ハードウェアスケジューラ(Hardware Scheduler:HWS)を搭載した。ハードウェアスケジューラによって、低レイテンシでGPU状態にきめ細かく対応したタスクスケジューリングが可能になる。
GPUのタスクのスケジューリングは、従来は多くの部分がCPU上で走るソフトウェアで行なわれていた。Polarisでは、その一部をGPU上のハードウェアに移した。実際には、GPU上のコントローラで走るファームウェアへと切り替えた。これは、GPUにとっては、自らの制御を行なうという点で、大きな変化となる。この方向への進化が続くと、AMDのGPUは、多様なアプリケーションを、タスクの粒度に関わらず効率的に走らせることができるアーキテクチャへと進化するだろう。
PDF版はこちら
ハードウェアスケジューラの利点は、GPU上でタスクの制御を行なうことで、低レイテンシで効率の高いスケジューリングが可能になること。複雑で高度なスケジューリングメソッドの導入が可能になることだ。AMDでGPUのアーキテクチャを担当するMike Mantor氏(Senior Fellow Architect, RTG ,AMD)は次のように語る。
「スケジュールタスクをGPUハードウェアに移行させると、スケジュールタスクはより効率的で応答性がいいものになる。その結果、スケジューリングに新しい機能を加えることができるようになる。ハードウェアスケジューラはプログラマブルで柔軟な機能を備えており、実に多くのことができる。現在は、まだ、できることのごく一部しか使っていない。
ハードウェアスケジューラで、まず最初に実装したのはハイプライオリティスケジューリングだ。キューをACEエンジンにマップする際に、ハードウェアスケジューラが高いプライオリティキューに設定する。ハードウェアスケジューラによるハイプライオリティの利点は、非常に低レイテンシであることだ」。
Polarisアーキテクチャでは、ハードウェアスケジューラが、タスクをハイプライオリティキューにマップすると、特殊なメカニズムが働くという。マップされると即座にハードウェアが、そのタスクに割り当てられるメモリとレジスタへのアクセス権を確保する。割り当てられたメモリロケーションとレジスタがビジブルになることが、ハイプライオリティワークのトリガとなる。トリガを受けて、実行エンジンであるシェーダアレイの中で、タスクの実行スレッドバッチであるWavefrontが立ち上げられ、空いたCUで実行が始まる。
AMDのGCNアーキテクチャでは、コンピュート向けのコマンドプロセッサであるACEが、非同期にワークグループをシェーダプロセッサアレイに割り当てる。割り当ては動的に行なわれるため、AMD GPUでは非同期に動的にGPUへのタスク割り当てとパーティショニングが変化する。もともと、AMDアーキテクチャでは、各タスクへのコンピュートリソースの割り当ては、半固定されたものではなく、完全に動的に行なわれる。
この時、タスクは、通常はタスクキューの順番に、実行リソースに割り当てられる。しかし、高プライオリティが設定されたキューのタスクは、ほかのタスクより優先され実行される。その際のプライオリティハンドリングが、ハードウェアスケジューラによって低レイテンシでなされる。
ややこしいのは、タスクのプライオリティの設定自体は従来も、コンピュートタスクをハンドルするACEなどに実装されており、ハードウェアスケジューラがなくても可能であることだ。しかし、ハードウェアスケジューラによって、ずっと短いレイテンシで、ハイプライオリティタスクが実行されるという。そのため、高いプライオリティの応答性がより高くなり、プライオリティキューの利点が大きくなる。
PDF版はこちら
リアルタイム性のアプリケーションの実行を可能に
AMD GPUのハードウェアスケジューラの利点が活きるスケジューリングの1つが、リアルタイムスケジューリングだ。これによって、GPUをリアルタイム性の高いDSP(Digital Signal Processor)のように使うことが可能になるという。グラフィックスワークロードが走っている時に、リアルタイム性の高いタスクをGPUで走らせることは、これまであまり現実的ではなかった。AMDのMantor氏は次のように説明する。
「特定のジョブを円滑に実行できるようにするリアルタイムスケジューリングも、ハードウェアスケジューラで実装した。リアルタイム性が要求されるアプリケーションに適用する。リアルタイムキューを設定して、リアルタイムのジョブをそのキューにマップする。リアルタイムプロセスが走っている間は、継続してリアルタイムスケジューリングを行なう。
リアルタイムジョブでは、応答性が重要となる。そのため、ジョブが専用して使うことができるリソースの確保、何らかの時間的または空間的なリソースのアロケーションが必要となる。そこで、リソースリザベーションを導入した。
我々がリアルタイムキューを、最初に適用したのはオーディオプロセッシングだ。オーディオはリアルタイム性の非常に高いタスクだ。そこで、オーディオタスクに一定のコンピュートリソースをリザーブ、そのリソースを占有していたタスクはどいてもらう。その上で、そのリソースをほかのタスクが使うことがないように、リザーブする」。
リアルタイムスケジューリングでも、特殊なリアルタイム属性のタスクキューを設定する。リアルタイムキューに収められたジョブには、一定のGPUリソースが割り当てられる。割り当てられたリソースでは競合が発生しないため、ジョブの実行において応答性が非常に高くなる。オーディオプロセッシングのように、途切れたりすることが許されないタスクでは非常に有効だ。
Polarisアーキテクチャでは、リアルタイムスケジューリングでオーディオタスクをシェーダアレイで実行する。そのため、従来のAMD GPUが備えていたTensilica製のオーディオDSPコアは、Polarisでは外された。GPUの一部をDSP的に使えるようになったためだ。
従来のAMD GPUでは、プロセッシング能力が限定されたDSPでTrueAudioを実行していた。そのため、複雑なオーディオ処理になると、DSPの性能が足りなくなってしまうケースが発生していた。しかし、Polarisアーキテクチャでは、コンピューティングリソースに余裕がある限り、TrueAudioにリソースが割り当てられるため、複雑なオーディオ処理でも円滑にできる。
これは、3Dオーディオ処理が非常に重要となるバーチャルリアリティでは大きな利点となる。リアルタムDSP的な使い方ができるPolaris GPUのために、必要なだけのコンピュートリソースで高度なオーディオ処理を行なうことができる。AMDは、現状では、オーディオとグラフィックスに、このリソースリザベーションを適用している。後述するが、グラフィックスでのリソースリザーブは、バーチャルリアリティで有効に働く。
リアルタイムスケジューリングで難しい点は、ワークロードに対して、適切な量のリソースをリザーブする仕組みだという。過剰にリソースを割り当てしてしまうと、ほかのジョブの実行が圧迫されてしまう。リソースには制約があるので、APIが必要十分なリソースアロケーションを管理できるようにする必要がある。そのため、リアルタイムスケジューリングの開発は、非常に複雑なプロセスになるという。
バーチャルリアリティで問題となるタスクスケジューリング
AMDは、バーチャルリアリティ(VR)向けのAPIセットである「Liquid VR API」で「Quick Response Queue」と名付けた応答性の高いキューの導入もアナウンスしている。Liquid VRでは、レンダリングエンジンによる描画と、描画した後の画像をユーザーの頭の動きに合わせて修正するAsynchronous Time Warp(ATW)を平行して行なう。
ATWはコンピュートタスクであり、グラフィックスタスクとオーバーラップして走る。VRヘッドマウントの動きに追従する必要があるため、低レイテンシが重要となる。Quick Response Queueのスケジューリングはどうなっているのか。
「Quick Response Queueは、マーケティングネームだ」とAMDのMantor氏は笑う。「実際にはやっていることは、ハイプライオリティキューだ。Quick Response Queueでは、タスクのプライオリティを上げているだけで、リアルタイムキューのようなリソースリザーブは行なわない。しかし、キューを高いプライオリティにマップするため、次のWavefrontのローンチ時に優先的にディスパッチされる。
ATWでも、もちろんリソースリザベーションを使うこともできるし、アーリークリーンナップスペースを使うこともできる。しかし、現状では、ハイプライオリティにして、低レイテンシにシェーダアレイに入れるようにするだけで十分だと考えた。もし、不十分となれば、いつでも違う方式のスケジューリングに変えられる」。
ATWのスケジューリングについては、AMDは昨年(2015年)から問題提起を行なっていた。バーチャルリアリティでは、頭を動かすにつれてゴーグル内に表示される画面がシフトする必要がある。このシフトの追従性が悪いと、VR酔いの原因となる。しかし、3Dグラフィックスのレンダリングには一定の時間がかかるため、レンダリングでリアルタイムに追従することは難しい。
そこで、現在のVRでは、VRヘッドセット画面への描画の同期タイミングで、辻褄の合った絵を表示するテクニックを導入している。これがATWで、レンダリングした絵と表示タイミングの頭の位置の絵がずれた場合に、補正を行なう。レンダリングした絵を頭の位置の移動に合わせてシフトさせて、本来描画されるであろう位置の絵にする。
プリエンプションでは解決が難しいATWタスク
問題はこのATWの作業はコンピュートタスクである点。できる限り短い時間で、画面の同期タイミングまでにワープした絵を生成しなければならない。しかし、GPU上では、グラフィックスタスクが連続的に走っている。そのため、ATWのワークロードを優先させて、コンピュートリソースをつぎ込んで短時間で処理させることが望ましい。
AMDは昨年春にGDC(Game Developers Conference)と日本で行ったプレスカンファレンスで、この問題について詳しく説明している。
まず、GPUコアが1度に1つのコマンドストリームしか処理ができない場合や、複数タスクを平行して走らせることができても、プライオリティを付けられない場合、ATWタスクは時間がかかってしまう可能性がある。1ストリームしか走らせることができず、プリエンプションもできない場合は、グラフィックスタスクが終わるまでATWが待たされてしまう。レイテンシが予測できないため、高品質なATWは極めて難しくなる。
プリエンプションによるコンテクストスイッチングを使って、リソースを占有するタスクを全て強制的にスイッチさせる方法もある。ATWの場合、走っているグラフィックスタスクをプリエンプションで休止させて、ATWのタスクを走らせることになる。しかし、この場合は、GPUはコンテクストが大きいため、プリエンプティブコンテクストスイッチングのストア/リストアのレイテンシが発生してしまう。効率が悪いものとなる。
上記の方法に対して、多数のタスクを同時にGPUでパーティショニングで走らせて、タスクを制御できる場合は、話はずっとすっきりしたものになる。ATWの場合は、グラフィックスタスクが走っている状態で、ATWタスクを混入させることができる。その場合に、ATWタスクのプライオリティを高く設定すると、多くのリソースが割り当てられ、ATWのタスクが短時間で終わる。
実際にAMD GPUがやっているスケジューリングは巧妙で、まずATWタスクをハイプライオリティタスクに設定する。すると、コンピュートリソースが空いたタイミングで、プライオリティの低いタスクではなくATWタスクが優先的に割り当てられる。グラフィックスタスクよりもATWが優先される。
しかし、それではグラフィックス処理が完全に止まってしまうことになり、問題が発生するケースが出てくる。そこで、AMDは、グラフィックスタスクに一定のリソースをリザーブ、ハイプライオリティのATWタスクが入って来た時も、最低限のグラフィックスワークロードはコンピューティングリソースで走るようにしている。下の図で、赤のATWが優先的にローンチされた後も、グレーのラフィックスのワークロードが一定量残って走っているのがそれだ。
こうしたATWのQuick Response Queueのふるまいの中で、Polarisのハードウェアスケジューラは、どう役に立つのか。ベネフィットは、明瞭だ。プライオリティタスクのATWのレイテンシがより短くなり、より効率的になる。その分、迅速にATWタスクが実行されるようになる。これは、レイテンシクリティカルなVRでは大きな利点となる。その一方で、グラフィックスタスクは、負荷に応じて柔軟にリソースがリザーブされ続ける。
新しいスケジューリングの導入が期待できるハードウェアスケジューラ
ハードウェアスケジューラの導入は、GPUタスクスケジューリングを進化させる可能性を持っている。AMDのMantor氏は、まだ始まりに過ぎないと言う。
「我々は、現在、多様なスケジューリングが可能となっている。リアルタイムコンピュート、ハイプライオリティコンピュート、バックグラウンドコンピュートが可能だ。また、ほかのコンピュートジョブを、プリエンプトでコンテクストスイッチすることができる。また、それらのポリシーは全て制御できる。
しかし、ハードウェアスケジューラには、もっと多くの可能性がある。例えば、リアルタイムスケジューリングでも、ハードウェアスケジューラの機能は非常にフレキシブルなので、さまざまな実装に対応できる。現在は、比較的シンプルなスケジューリングを行なっているが、将来は、異なるリアルタイムスケジューリングも導入できるだろう。
例えば、特定の時点や条件になると、リアルタイムジョブがウェイクアップする場合がある。それに合わせて、リアルタイムジョブが現れる前に、リソースをリザーブするといったスケジューリングがありうる」。
AMDのハードウェアスケジューラの活用は、まだ初歩段階で、これから広がって行く。グラフィックスとコンピュートなどが入り交じる時に、ハードウェアスケジューラの効力が出る。コンピュートタスクも多数のタスクが平行して走るようになると、より複雑なスケジューリングが必要となって行きそうだ。
ハードウェアスケジューラで走るコードは、カーネルモードドライバの一部のように見える。だから、アプリケーションも、ハードウェアスケジューラを制御できる。同じように見えながら、レイテンシが短くなり、多様なスケジューリングが可能になる。GPUが、タスクスケジューリングの面でも、より汎用プロセッサ的に変わりつつある。
「将来、ハードウェアスケジューラは、GPUのスケジューリングに関する全てのタスクを実行できるようになるだろう。GPUのスケジューリングに、CPUが全く関わらないようになると見ている。ただし、そうなると、OSのタスクスケジューリングと類似の複雑性が生じるため、様々なチャレンジが待ち受けている」(Mantor氏, AMD)。
OSと異なることは、メモリとメモリ管理で、グラフィックスについては、メモリの扱いを明示的にする新しいAPIが必要となる。DirectX 12やVulkanといった新しいAPIは、新しいメモリ管理モデルを備えており、ユーザーキューでのキューイングが可能となっている。そのため、ハードウェアスケジューラと親和性が高い。
実際、新APIでは、非同期にコンピュートタスクの割り当てが行なわれるAsynchronous Computeがサポートされている。AMD GPUは、もともと非同期にワークグループを割り当てている。それが、新APIによって、明示的に有効に使われるようになり、さらにハードウェアスケジューラによって、制御がより迅速に柔軟にできるようになった。「ハードウェアスケジューラと新APIによって、HSA(Heterogeneous System Architecture)的な機能をグラフィックスに持ち込むことができるようになった」とMantor氏は言う。
AMD PolarisのハードウェアスケジューラによってGPUを制御するマイクロコントローラがより強化され、CPUからGPUへと処理がまた1つ移った。GPUのCPUへの依存がまた低減したことになる。GPUの大きな弱点だったタスクスケジューリングの窮屈さが解消されつつある。長い目で見ると、GPUが独立したプロセッサへと変わって行く、そのプロセスが、AMDでは、また1つ進んだと考えることもできる。