これで分かるOpenCL。NVIDIAのOpenCLセミナーから，OpenCLの正体と可能性を再確認する

　速報記事でお伝えしているとおり，2009年10月29日，NVIDIAは東京・秋葉原で開発者向けのイベント「OpenCL seminar〜GPUコンピューティングがもたらすもの〜」を開催した。

　OpenCLは，NVIDIAの「CUDA」（Compute Unified Device Architecture）や，DirectX 11の「DirectCompute」などと同じく，GPUコンピューティングを実現する仕組みの一つである。
　GPUコンピューティングアーキテクチャとして，自社のCUDAを強力にプッシュしているNVIDIAが，なぜOpenCLなのか。NVIDIAは，開発者向けイベントの冒頭でわざわざ説明したほどなので，それだけ，OpenCLの立ち位置，そしてCUDAとの関係はまだ理解されていないということなのだろう。実際，さっぱり分からんという読者も少なくないと思う。

　今回は，OpenCL seminarの技術セッションにおける講演やQ＆Aの内容を中心に，このあたりを整理してみたい。

GPUで動作させるプログラムを

いかにして作成するか？

　CPUとは異なり，比較的単純な構造の演算器を大量に搭載するGPUは，大量のデータに対して，同じ演算を行うような処理に適している。データを大量に処理していくというのは，CPUが苦手としている分野なので，この部分をGPUに処理させれば，PCをより効率的に利用できる。
　――これが近年，GPUを「グラフィックス描画用プロセッサ」という枠を超えて利用しようという，GPUコンピューティング，あるいはGPGPU（General Purpose GPU）と呼ばれる概念だ。

OpenCLを策定したKhronos GroupによるOpenCLのイメージ

CPUとGPUを並列動作させるオープンなフレームワークとして，Khronos GroupはOpenCLを位置づける

　GPUは，専用のメモリ（＝グラフィックスメモリ）を持ち，単独でプログラムを実行できる。PCの中にGPUという別のコンピュータが入っている，といったイメージだ。
　このように種類の異なるCPUとGPUを混在させて利用するタイプのコンピュータを，最近はヘテロジニアス（Heterogeneous，異種混合）な並列環境などと言ったりもする（※NVIDIAはヘテロジニアスではなく，「Co-Processing」という言葉を好んで使うようになっている気配だが）。

　ともあれ，GPUコンピューティングを実現するためには，「CPUがGPUを制御して，GPUにプログラムを実行してもらう仕組み」が必要になる。先ほどOpenCLやCUDA，DirectComputeを「仕組み」と呼んだのはそのためだ。
　冒頭で述べたとおり，このなかでCUDAが特異なのは，NVIDIA製GPUに特化したデザインになっているということ。逆にいえば，OpenCLやDirectComputeはそうでないわけだが，今回はOpenCLが主役なので，OpenCLを中心に，CUDAなどとの関係性を考えてみることになる。

土山了士氏（フィックスターズ ソフトウェア・プラットフォームグループ OpenCLチーム リーダー）

　さて，OpenCL Seminarでは，並列コンピューティング関連ソリューションの提供を行っている企業，フィックスターズの土山了士氏が，OpenCLの概要とプログラムの基礎に関する二つのセッションを行った。

　氏はまず，OpenCLを「ヘテロジニアスな並列環境のためのフレームワークで，あらゆるプロセッサで動作することを想定しているもの」と定義する。CPUによるエミュレーションが可能とはいえ，CUDAやDirectComputeは対象をGPUに絞り込んでいるが，OpenCLは，GPUだけでなく，例えばDSP（Digital Signal Processor），あるいは4Gamer的にはPlayStation 3のCPUとして知られる「Cell Broadband Engine」（以下，Cell）などでも利用可能なのが大きな特徴というわけだ。

　本稿では以下，便宜的に，GPUやDSP，Cellの各コア「SPE」（Synergistic Processor Element）といった，実際にOpenCLの演算を担当するプロセッサを「演算デバイス」，x86 CPUやCellの「PPE」（PowerPC Processor Element）など，演算デバイスを制御する側を「制御ホスト」と呼ぶことにしよう。これら演算デバイスや制御ホストは，単体で，あるいは（それこそCellのように）一つのプロセッサ内に統合される形で，NVIDIAやIntel，AMD，東芝，Freescale Semiconductor，Texas Instrumentsといったベンダーから提供されている。

OpenCLはさまざまなタイプの並列環境をサポートする。スライドに挙げられているのはCPU＋DSP，Cell，CPU＋GPUという3パターンだが，必ずしも「制御ホストと演算デバイスが必須」というわけではなく，x86 CPUなら，内蔵するSSE用のレジスタを演算デバイスとして利用したりすることも可能だ

　この状況を前にして，プログラマーが，これらさまざまな演算デバイスや制御ホストに向けて，対応ソフトウェアをバラバラに開発するのは効率が悪い。演算デバイスの活用によって，ある機能を実現しようと思ったときに，GeForce向けにCUDAのSDK（Software Development Kit，ソフトウェア開発キット）で開発しつつ，ATI Radeon向けにはAMD Stream SDKで，PlayStation 3向けにはソニー・コンピュータエンタテインメントのSDKで作っていくというのは二度手間，三度手間になってしまうからだ。

　OpenCLが解消するのは，この「手間」であり，OpenCLでは，一度の手間で，さまざまな並列環境（＝演算デバイスと制御ホストの組み合わせ）に対応したソフトウェアの開発を行えるようになる。
　これを実現するに当たってクリアすべき条件は，“並列環境側”がOpenCLをサポートしなくてはならないこと。具体的には，演算デバイスや制御ホストを提供しているハードウェアベンダーや，サードパーティとなるソフトウェアベンダーが，大まかに，次に挙げる三つの仕組みを提供する必要がある。

1. 「OpenCL Platform Layer」（OpenCLプラットフォームレイヤー）
   OpenCLをサポートするプラットフォームの情報を得たり，OpenCLで作成したプログラムを動作させるためのリソースを得たりといった，OpenCLを利用するために無くてはならない足回りを実現する部分
2. 「OpenCL Compiler」（OpenCLコンパイラ）
   プログラマーは，「演算デバイス上で動作するプログラム」を作るためのプログラミング言語「OpenCL C言語」でソースコードを書くことになるが，そのソースコードを，演算デバイス上で実行できるバイナリ（※誤解を恐れず言い換えると，実行ファイルのようなモノ）に変換するもの
3. 「OpenCL Runtime」（OpenCLランタイム）
   制御用デバイスから，演算デバイス上で実行できるバイナリを演算デバイスに読み込ませ，実行を指示し，実行した結果を制御用ホストに取り込むためのソフトウェア的なインタフェースを提供するもの

SSE3，Cell，CUDA（対応GPU）では，同じ処理を行うにも，書くべきプログラムがまったく異なっていた。これに対してOpenCLだと，OpenCL C言語という1種類のプログラム記法で，さまざまな演算デバイスへ対応できる

OpenCLを使うために必要な3要素

OpenCLを使って演算デバイスを利用するイメージ。ホストプログラム（※ゲームプログラムなど，メインのプログラムのこと）から，OpenCL Runtime経由で，演算デバイスに「演算デバイス上で動作するプログラム」を実行させる。もちろん「演算デバイス上で動作するプログラム」を作成するのに使うのはOpenCL C言語だ

　「ゲーム内にあるオブジェクトの座標と各種パラメータを渡すと，適切な物理演算を行って，計算結果となる座標とパラメータを返す」というプログラムをOpenCL C言語で書いたとしよう。そのプログラムは，OpenCL C言語のコンパイラを使って，演算デバイス用のバイナリに変換しておく。
　このとき，制御ホスト上で動作しているゲームプログラムは，OpenCL Runtimeを使って「演算デバイス用のバイナリ」を演算デバイスに読み込ませて，実行を指示し，結果を返してもらうという流れになるわけだ。

　ここで押さえておかなければならないのは，OpenCL C言語を元に作られた演算デバイス側のバイナリは，演算デバイスによって異なる（＝互換性がない）こと。
　OpenCLにおいて，演算デバイス側プログラムの互換性が保たれるのは，あくまでもOpenCL C言語で書かれたソースコードの段階まで。ベンダーの提供するコンパイラを使って，ソースコードをバイナリに変換すると，そのバイナリは，演算デバイスに依存したものになるのだ。

　つまり，OpenCLを「演算デバイスの違いを完全に吸収して，演算デバイスが持つ最高のパフォーマンスを発揮してくれる仕組み」と捉えるのは，誤解ということになる。「OpenCL Cコンパイラを提供する各ベンダーには，OpenCL規格で定義されるOpenCL C言語の仕様を必ずサポートすることが求められているため，最終的にどんな演算デバイスを使うにしても，同じソースコードを利用できる」ことこそが，OpenCLの持つ最大のメリットなのである。

エンドユーザーから見た

OpenCLのメリットはどこにある？

OpenCL C言語は、ゲーム開発などに広く利用されているC言語を拡張し，同時に機能を若干削った言語になる。スライド中の「標準C99言語」が，ソフト開発に使われている一般的なC言語と考えてほしい。標準C99言語の大部分の機能をカバーしつつ，大まかに3分野で拡張が行われている

　OpenCLでも，バイナリは演算デバイスに依存する。ゲーム機なら，それこそ「PlayStation 3用」といったバイナリを一つ用意しておけば事足りるが，PCだと，最低でもIntel，NVIDIA，AMDのGPUやグラフィックス機能統合型チップセットに向けて用意しておく必要があるし，AMDのGPUのように，世代やグレードによってバイナリの互換性がなかったりするケースも考慮しなければならない。

　この世に流通しているすべてのGPUに対応したバイナリをすべて用意できれば，この問題は解決するが，言うまでもなく現実味は乏しい。そこでOpenCLには，実行時にソースコードを渡して実行するAPIが2種類，以下のとおり用意されている。

• clCreateProgramWithBinary()：演算デバイスのアクセラレーションをバイナリで提供するAPI
• clCreateProgramWithSource()：実行時にソースコードを渡して，その場でバイナリにコンパイルするAPI

OpenCLで演算デバイス上のバイナリを実行させるまでにはいろいろなステップがあるのだが，このスライドに挙げられている「clCreateProgramWidthBinary()」が，OpenCL C言語で作成したバイナリを読み込むAPIだ。「clCreateProgramWithSource()」というAPIもあり，こちらではOpenCL C言語のソースコードを読み込むこともできたりもする

　ソフトウェアベンダーは，演算デバイスによるOpenCLのアクセラレーションをバイナリで提供するか，ソースコードで提供して，制御ホスト側から演算デバイスを利用するとき，演算デバイスに合わせてその場でバイナリをコンパイルするかを選択できる。後者を選択すれば，まさに「演算デバイスを問わないOpenCLプログラム」を作成できるという理屈である。

　もっとも，ソフトウェアベンダーがどちらを選択するかは，今のところ何ともいえない。後者の場合，そのまま実装してしまうと，ソースコードが第3者に見られてしまうため，実際には暗号化が必要だったり，コンパイルに時間がかかるうえ，コンパイルしたバイナリは演算デバイス側のメモリ上に置くしかないため，複数のバイナリをとっかえひっかえするような用途だと，演算デバイス側のリソースを相当量消費してしまうという課題もあるからだ。
　ただ，OpenCLに，エンドユーザーが演算デバイスの違いを気にすることなく利用できる仕組みが用意されているという事実は，押さえておきたいポイントだといえる。

　ちなみに土山氏は，さまざまなプラットフォームに対応したOpenCL環境が今年中に出揃うという見通しを示していた。また，氏が所属するフィックスターズも，同社のYellow Dog Linux上にCUDAとOpenCLの開発環境をセットにした製品や，x86 CPU向けOpenCL環境などをリリースする予定とのこと。
　OpenCLを取り巻く開発環境が整ってくる2010年以降は，いよいよ，エンドユーザーの元へも，さまざまメリットがもたらされることになるはずだ。

OpenCLとCUDAの関係を再整理

〜NVIDIAはGPUコンピューティング発展を目指す

　最後に，OpenCLとCUDAの関係をあらためて整理しておくことにしよう。ここまで述べたとおり，OpenCLは，Platform LayerとCompiler，Runtimeが用意されていれば，演算デバイスに限定されずに利用できる。対するCUDAの場合，NVIDIA製GPU限定という制約がある一方で，NVIDIA製GPUの機能をフルに生かしたアプリケーションの開発を行えるというメリットがあるわけだ。

これがOpenCLのメモリモデル。大まかに，プライベート，ローカル，グローバル＆コンスタントの順で，演算ユニットから遠いメモリと考えてほしい。このモデルは多くのGPUに共通するものだ（※GPU以外の演算デバイスでは少々事情が変わってくる）。NVIDIA製GPUだと，コンスタントメモリをグローバルメモリよりも高速に参照できたりするが，それを前提にしてしまうと，ほかの演算デバイスを使ったとき，期待したパフォーマンスは得られない恐れがある

　一例として，メモリ周りを取り上げてみる。OpenCLでは，演算デバイスのメモリ構成モデルとして，3階層を規定している。イメージとしてはCPUのL1〜L3といった感じで，演算デバイスの演算ユニットに最も近いメモリと，次に近いメモリ，最も遠いメモリといった具合だ。
　OpenCLは，CPUやGPUだけでなく，世の中にあるさまざまなプロセッサを演算デバイスとしてサポートする都合上，ハードウェアの構造に依存した細かな制御を行うのは難しい。基本的には，メモリ階層をを大まかにしか制御できないのである。
　この点，CUDAでは，NVIDIA製GPUに特化した，きめ細かなメモリ制御が可能だ。換言すれば，CUDAではデータを置く場所を最適化しやすく，OpenCLよりもパフォーマンスを引き上げやすいということになる。

OpenCLでは，演算デバイス側で実行するバイナリ――より厳密には「実行する単位」――を「OpenCLカーネル」と呼ぶ。そしてOpenCLでは，OpenCL C言語で作成されたOpenCLカーネル以外に，演算デバイス固有に作られた「ネイティブカーネル」というバイナリの実行もサポートするのだ。CUDA C言語で開発されたバイナリを，ネイティブカーネルとして使えるわけである

　ただ，ここで面白いのは，OpenCLが，たいへん柔軟な設計になっており，CUDA C言語で開発したNVIDIA製GPU用のバイナリを，OpenCL Runtimeから読み出し，実行させることも可能だということ。
　デベロッパは，OpenCL C言語のソースコード一つで，AMD製GPUやコンシューマゲーム機に対応させつつ，CUDA C言語をベースにNVIDIA製GPUへの徹底的な最適化を行うことで，技術的な優位性をアピールしたり，もっと露骨な話をすれば，それによってNVIDIAからの技術的，マーケティング的，金銭的援助を得たりできるのである。

　いずれにせよ，AMDがCUDAを牽制するときによく使う，「3dfxのGlideと同じように，特定のGPUに依存したCUDAは，OpenCLなどに取って代わられる」という話は，CUDAに最適化したほうがより高いパフォーマンスを得られることと，開発環境の整備でOpenCLよりもCUDAのほうが進んでいることを踏まえるに，少なくともすぐ起こるようなことではない。
　しかも，NVIDIAの立場からすると，CUDAとOpenCLは競合しているにあるわけではなく，むしろパフォーマンスと互換性の面で相互補完の関係にある。OpenCLの普及を後押しすることにより，GPUコンピューティングの普及を図り，ひいては，性能面，機能面で優れるCUDAともども，GPUの利用を加速させるのが狙いである。おそらく今後もNVIDIAは，独自の立場から，OpenCLをプッシュしていくはずだ。

　ゲーマーの立場からすると，「OpenCLでもCUDAでもDirectComputeでも，何でもかまわないから，GPUコンピューティングにより，次世代感を感じさせてほしい」というのが本音だが，汎用性の高いGPUコンピューティングの仕組みであるOpenCLが花開く可能性は十分にある。そう簡単に，ぽこぽこと対応タイトルが出てくるとは思えないが，見守っていくだけの価値はあるだろう。