日本時間2013年10月22日13：01，AMDは，同社が推進する「HSA」（Heterogeneous System Architecture）の新要素「hQ」を発表した。AMDは4月30日に，HSAで対応する新技術として「hUMA」（Heterogeneous Unified Memory Architecture）の概要を発表しているが（関連記事），今回のhQはそれに続くものとなる。
　今回4Gamerでは，アジア太平洋地域の報道関係者を対象とした事前電話会議に参加できたので，その内容を踏まえつつ，「hQとは何か」を紹介してみたい。

「異種混合」を真の意味で実現するためのhQは

ユーザーモードからGPUスレッドをディスパッチする

　hQは「Heterogeneous Queueing」（ヘテロジニアスキューイング）の略で，ざっくりまとめるならば「CPUとGPUの間にあった高いハードルを下げる仕組み」なのだが，その具体的な話をする前にまずは，「なぜAMDはHSAにhQという仕組みを取り入れる必要があるのか」という話をしておきたい。

　GPUはディスプレイコントローラの一種として登場した経緯があり，依然としてOSの管理下にある。そして言うまでもないことだが，ディスプレイには複数のアプリケーションから，表示データが出力されてくる。したがって，“誰か”がそれらを調停しなければならない。
　また，「ユーザーアプリケーションがハードウェアへ好き勝手にアクセスすると，アプリケーションの互換性を保証できず，セキュリティも脅かされるため，GPUを含むハードウェアに対するアクセスはOSの管理下に置くべきだ」という，OS設計上のポリシーもある。その結果として，アプリケーションはGPUに直接はアクセスできず，OSのAPI（Application Program Interface，命令や関数をまとめたもの）を通じて，グラフィックスドライバ（以下，デバイスドライバ）経由でGPUを操作する仕組みが採用されている。
　要するに，アプリケーションがGPUに何か処理をさせるときには，必ず，以下のような経路を辿る必要があるというわけだ。

• アプリケーション→OSのAPI→デバイスドライバ→GPU

　一見シンプルに見えるこの経路だが，その実，内部はかなり複雑なものになっている。というのもOSは，「CPUの特権機構」などと呼ばれる仕組みを使って，アプリケーションの動作からOS自体を守る仕組みを備えているためである。
　たとえば，x86プロセッサはRing0（最高特権）からRing3（最低の特権）までの4段階の特権レベルを持つ。そしてOSは，全メモリ領域や，GPUを含む全ハードウェアなど，コンピュータが持つすべてのリソースにアクセスできるRing0で動作する。対してアプリケーションは最低レベルのRing3で動作するため，OSから許可されたリソースにしかアクセスできない。なので，GPUへのアクセスは，OSを介して行わなければならないのだ。

　一般に，OSが動作するモード（※x86プロセッサならRing0で動作している状態）は「カーネルモード」（Kernel Mode），アプリケーションが動作するモード（※x86プロセッサならRing3で動作している状態）は「ユーザーモード」（User Mode）と呼ばれるが，ざっくりいえば，デバイスドライバはカーネルモードで動作している。Windowsは少々複雑で，「ユーザーモードドライバ」という仕組みが用意されており，グラフィックスドライバの一部はユーザーモードで動作していたりするのだが，それでもGPUを駆動させるというコア部分はカーネルモード動作である。

　問題は，GPUを駆動するために必要な「ユーザーモードからカーネルモードへの切り替え」に，大きなオーバーヘッドを伴うことだ。
　x86系プロセッサにおいては，ユーザーモードからカーネルモードに切り替える命令自体が，そもそも多くのクロックを消費する。しかも，切り替えにあたっては，複雑なセキュリティチェックも必要になる。「ひょっとしたらそのアプリケーションは，何か不正なデータをAPIに渡し，意図的にOSの破壊を狙うものかもしれない」ため，アプリケーションから渡されたパラメータに問題がないかをいちいち確認したうえでカーネルモードに切り替える必要があるのだから，ここが性能面の足を引っ張るのは火を見るより明らかだろう。

　以上，主にGPUのグラフィックス描画を前提に話を進めてきたが，状況はGPUを計算用途に使うGPGPUも同じ。グラフィックスドライバを経由する以上，ユーザーモードからカーネルモードへの切り替えが必ず必要になる。これが，アーキテクチャの異なるプロセッサが互いに協調する異種混合マルチプロセッシング（Heterogeneous Multi Processing）環境の実現というHSAのゴールに向けて，大きな問題となっていたのだ。

従来の問題点を記したスライド。CPUからGPUのタスクを起動（ディスパッチ）するには，CPUを駆動するためにOSを経て，カーネルモードで動作するデバイスドライバを呼び出す必要があり，ユーザーモードからの切り替えに大きなオーバーヘッドがあった。ちなみにこの図は簡略化されており，CPUの仕事はOSに処理させるだけのようにも見えるが，実際にはアプリケーションもOS（のAPI）もデバイスドライバもすべてCPUが実行させている

　AMDが推進するHSAは，GPGPUをさらに推し進め，CPUとGPUによる，より深い連携を実現しようというフレームワークである。しかし，ちょっとした処理をGPUに行わせるためだけにユーザーモードとカーネルモードの頻繁なスイッチが入るようでは，GPUを効率的に使うことはできない。
　ではどうするか。ユーザーモードからGPUタスクをディスパッチ（dispatch，プロセスやタスクをプロセッサに割り当てる意）できるようにするというのが，hQのキモである。

AMDは先にhUMAを発表済みだが，CPUとGPUより緊密に動作させるにはhUMAでは足りない。そこで，もう1つの柱となるhQの出番となるわけだ

　hQのポイントは大きく3つある。1つは，ユーザーモードからGPUタスクを起動させるための仕組みをハードウェアが提供するというもの。具体的には，GPUタスクの実行キュー（待ち行列）にユーザーモードからアクセスできるという機能だ。
　2つめは，その結果としてユーザーモードとカーネルモードの切り替えが介在しなくなるため，オーバーヘッドを大きく削減できるということだ。実のところ，これがhQのメリットとして最も大きい。

hQにおける3つのポイント。本文で挙げた順に「Device Enqueue」「User Mode Queueing」「Standard Packet Format」とあるが，それぞれは相互に関連しており，一番重要なのはUser Mode Queueingだ。GPUタスクをユーザーモードからGPUのタスク実行キューに積めるのが大きい

　そして3つめは，GPUタスクを起動させるためにキューへ積むパケットの形式が，HSAベースのプラットフォームで標準化されること。つまり，x86ベースのプロセッサであってもARMベースのプロセッサであっても，HSAをサポートしてさえいれば，同じフォーマットが使えるということだ。

hQでは，ユーザーアプリケーションから，「実行したいタスク」をGPUの実行キューに直接積むことが可能になるという

　電話会議でhQについて説明したAMDのBen Sander（ベン・サンダー）シニアフェローは，hQによって，GPUを使うプログラミングが極めて容易になることと，CPUとGPUとが本当の意味で対等な関係になることを，繰り返し強調していた。
　hUMAともども，CPUとGPUの連携をより緊密にするためには，欠かせない仕組みともいえそうだ。

hQによってカーネルモードを介在せずに済むようになるだけでなく，CPUからGPU，GPUからCPU，さらにはGPUからGPUのタスクもディスパッチできるようになるとSander氏。これでCPUとGPUは本当の意味で対等の関係になると氏は強調していた

GPUに複数のアプリケーションがアクセスするため，GPUにもタスクのスケジューラーが必要になる。そのため，GPU用のスケジューラがハードウェアとして用意されるという

　そんなhQだが，実装周りではまだよく分からない部分も多い。
　もちろん，ある程度は想像がつく。たとえば「GPUタスクがユーザーモードではアクセスできないリソースにアクセスしたらどうなるのか」は，Sander氏が電話会議で，「GPUタスクもユーザーモードからアクセスできるリソースにしかアクセスできないので，セキュリティは守られる」と述べていたことがヒントになる。おそらくはGPUの特権違反が，例外としてIOAPIC（Input/Output Advanced Interrupt Controller）を通じてCPU側に通知される仕組みになっているのだろう。
　これまでのGPUには例外を受け取るような仕組みがないので，GPUが発生させた例外をCPU側でキャッチし対処するというのが，常識的な実装になると思われる。

　ただ，「GPU側の例外をCPU側で処理するための情報を得る仕組み」はどうなっているのかというと，まったくのノーヒントだ。当然のことながら，例外処理の部分がしっかり実装されていないとセキュリティホールにつながりかねない。そもそも，OSをバイパスして，（CPUにとっての）周辺デバイスであるGPUにユーザーモードからダイレクトにアクセスできる仕組みは，OSの設計からすると，かなり際どい感じもする。このあたりの不安を払拭するだけの「何か」を，AMDは持っているはずだ。

　こういった実装面での詳細情報は，現地時間11月11日から米サンノゼ市で開催される予定の開発者会議「AMD Developer Summit 2013『APU13』」で明らかとなるに違いない。HSAはCPUとGPUの連携において従来にない領域へと踏み込もうとしているのは確かであり，続報が気になるところだ。

AMD Developer Summit公式Webページ（英語）