［SIGGRAPH］ついにDirectX 11を凌駕した!? Khronosに聞く「OpenGL 4.2」の正体

Khronosに属するメンバー企業を示したスライド

Khronosが規格策定に携わっているオープンスタンダードAPI群がこのスライドに示されている

　Khronos Group（クロノスグループ，以下Khronos）は，組み込み機器向けのオープンスタンダードAPIワーキンググループとして2000年に発足した団体である。活動初期においては，組み込み機器向けのOpenGL ESの規格策定に注力していたが，2006年に本家OpenGLの規格策定を行っていたOpenGL ARB（Architecture Review Board）と統合することになった。その結果，Khronosは，クロスプラットフォーム対応のオープンスタンダードAPIの規格化団体として，最も大きなものの1つに数えられるようになっている。

　そんなKhronosはこのところ「Game Developers Conference」（以下，GDC）と「SIGGRAPH」の会期中に大きな発表を行うのが慣習化しているのだが，SIGGRAPH 2011でもやはりいくつか重要な発表がなされたので，その内容をレポートしよう。

DirectX 11を大きく凌駕するというOpenGL 4.2

　というわけで，SIGGRAPH 2011におけるKhronos最大のトピックは，3Dグラフィックス向けオープンスタンダードAPI「OpenGL 4.2」の発表である。

Khronosの代表であるNeil Trevett氏。NVIDIAにおけるMobile Content部門のVice Presidentという肩書きも持つ

　本稿の執筆にあたっては，Khronosの代表であり，NVIDIAでモバイルコンテンツ部門の副社長も務めるNeil Trevett（ニール・トレベット）氏への取材を行ったのだが，そのときに彼は，今回のOpenGL 4.2の発表を「OpenGLの歴史上で，久々にDirectXを追い越した……なんて言っている人もいるが（笑）」と，とても嬉しそうに語っていたのが印象的だった。

2010年からOpenGLがロケットの如く加速し，DirectXを引き離しているということを冗談めかして示したOpenGLのロードマップ

　なぜ「OpenGL 4.2がDirectX 11を追い抜いた」などという話になっているのか。
　2009年にWindows 7がリリースされて以来，DirectX 11では，大きなアップデートが行われていないのに対し，DirectX 11から5か月遅れで「DirectX 11と同等の機能」と謳われるOpenGL 4.0がリリースされて以降，SIGGRAPH 2010で「OpenGL 4.1」，そして今回のOpenGL 4.2と，順調にバージョンアップが進み，機能も追加されているから，というのがその理由である。
　依然として“DirectX 11.0”に留まるDirectXに対して，Windowsと距離を取る開発者が「追い越した」と表現したくなるのも無理はない，というわけである。
　ではOpenGL 4.2のどのあたりがDirectX 11を追い越したのかを機能面から順番に見ていくことにしよう。

●Image_load_Store and Atomic Counters

　一般的に，「Pixel Shader」（ピクセルシェーダ）――OpenGLでは，「Fragment Shader」（フラグメントシェーダ）と呼ばれているが，4Gamer読者的にはピクセルシェーダのほうが親しみがあると思われるので，本稿ではピクセルシェーダと記述する――では，単一のバッファにしか書き込むことができない。また，テクスチャを読み出すことができても，一度書き込んだバッファを再度読み出す方法が与えられていない。

　OpenGL 4.2で提供される「Image_load_Store」は，任意の2Dテクスチャ配列に対して，ピクセルシェーダが読み書きできるようにする機能である。
　従来だと，「Multiple Render Target」（MRT，マルチレンダーターゲット）を使うことで，DirectX 10世代以降であれば最大8バッファまでなら同時に書き込みが行えていた。これが，OpenGL 4.2では，メモリ容量が許す範囲ならばいくつでも書き込みできるうえに，読み出しも行えるようになっている。

グラフィックスパイプラインにComputeShader的な拡張性を与えたともいえ，非常に強力な機能拡張だといえる

　Image_load_Storeとセットで紹介されている「Atomic Counters」は，Atomic Operation（不可分操作）に対応したカウンタ操作を行える機能だ。このカウンタ操作では，加算と減算が可能で，複数のカウンタをバッファに持つこともできるようになっている。

　実のところ，これらの機能は，NVIDIAのFermiアーキテクチャにおいて拡張機能として実装されているもので，実際，これらを使った「Order Independent Transparency」（OIT，描画順序無視の半透明描画）対応の描画パイプラインが考案されてたりしている。
　サンプルプログラムも公開されているので，興味がある人は，チェックしてみるといいだろう。

●Transform Feedback Instanced Example

　DirectX 11（OpenGL 4.x）世代のGPUには，「Tessellation Stage」（テッセレーションステージ）が用意されている。簡単に説明すると，「少ないポリゴンモデルをプログラマブルに自動分割することで多ポリゴン化したり，さらに『Displacement Mapping』（ディスプレースメントマッピング）によってディテールを付加したりできるもの」なのだが，実のところ，これには1つ大きな問題が指摘されているのだ。

　その問題とは，同じポリゴン分割と同じディスプレースメントマッピングが何度も行われてしまい，テッセレーションステージが意味もなく高負荷になってしまうというものである。

　たとえば毎秒60コマのゲームで，視点から10m離れたところに100ポリゴンの低ポリゴンモデルを配置したとする。これをテッセレーションステージを活用して10倍の1000ポリゴンモデルとして描画するとしよう。
　すると，次のフレームを1/60秒後に描画することになるわけだが，この間にプレイヤーキャラクターが300mm進んだと仮定した場合，9.7m先に再び100ポリゴンの低ポリゴンモデルを配置することになる。この場合，テッセレーションステージが再度ポリゴンモデルを1000ポリゴンに分割するのだが，分割結果は，前フレームのものと同じではないものの，ほとんど違わないものとなる。
　つまり，この2フレームの間で（ほぼ）同じポリゴン分割を2回繰り返したことになるわけだ。

テッセレーションステージを活用すると描画パフォーマンスが低下する問題を軽減できるかもしれない新機能だ

　ちょっとムダに思えるこの作業を解消する機能として導入されるのが，「Transform Feedback Instanced Example」である。
　これは，テッセレーションステージによって分割・変形された3Dモデルを，そのままキャプチャして再利用できるというものだ。
　先ほどの例で説明すると，Transform Feedback Instanced Example機能は，視点からの距離が2m変わるごとに再テッセレーションを行うが，そこまで距離が変わらない場合には直近のテッセレーション結果をテッセレーションステージで再利用するという，最適化処理を組み込めるようにする。
　また，テッセレーションステージによる処理結果のコピーに対して，個別のインスタンスを与えて，個々に異なる姿勢やアニメーション描画をすることもできるようになる。そのため，テッセレーションステージを用いて同型モデルの雑魚キャラなどを多数描画する場合に，劇的な最適化効果を得られることになるのだ。

●Compressed Pixel Texture Storage

上段，中段に記されているのが従来の手法。下段に記されているのがCompressed Pixel Texture Storageを用いたテクスチャの部分更新における手法だ

　「Compressed Pixel Texture Storage」は，圧縮されたテクスチャの部分更新にまつわる機能拡張だ。

　知っている読者も多いかもしれないが，プログラマブルシェーダ時代の到来以降，テクスチャは，ポリゴンに貼り付ける画像テクスチャだけでなく，シミュレーションの結果などといった汎用数値データの格納にも用いられるようになっている。

　例えば，波の高低情報をデータ化した圧縮テクスチャが用意され，これをもとにGPUが水面の波を描画していたとしよう。ここで，プレイヤーが水面に銃弾を撃ち込んだ場合，GPUは，銃弾と水面のインタラクションを処理しなければならない。
　従来は，水面のテクスチャを一度展開してGPUに丸々渡すか，もしくはCPUとGPUとが共有できるメモリ空間に更新したいテクスチャブロックをコピーするかといった具合に，いずれにしても処理に大きな冗長性があった。

　しかし，Compressed Pixel Texture Storageを使うことで，直接GPU側のローカルメモリ内に保存されているテクスチャを，任意の部分だけ書き換えられるようになる。
　要するに，これまであったムダを省きつつ，テクスチャの部分更新ができることになるわけだ。

●Map Buffer Alignment

　CPUでは，キャッシュシステムやメモリシステムの都合で，16bytesや64bytes，128bytes単位といった，特定で切りのいいデータアドレスでないと最大パフォーマンスを出せない場合がある。
　「Map Buffer Alignment」は，このデータアドレスを明示的にコントロールする機能。CPU側が持つSIMD命令セットであるSSEやAVXを有効に使いたい場合など，CPUとGPUとで同じデータを利用するアプリケーションでは効果を発揮できるはずだ。

●Conservative depth

　「Conservative depth」は，ピクセルシェーダを用いたZバッファレンダリングを行うときに有効な拡張機能。早期カリングを最適化する場合にも利用される。もともとはAMD製GPU専用の拡張機能だったものだが，今回，標準仕様に組み込まれたことになる。

●Shading Language Packing

　「Shading Language Packing」により，ベクトル型変数と整数型変数とを相互にパッキングしたり型変換したりできるようになる。

Webブラウザでプラグインなしの3Dグラフィックス描画を実現する「WebGL」

WebGLはHTML5に組み込まれるWeb向け3DグラフィックスAPIである

WebGLのソフトウェア階層ダイアグラムを示したスライド

　Khronosが力を入れているのはOpenGLだけではない。最近，注力しているのが，Webブラウザ上でプログラマブルシェーダ世代の3Dグラフィックスをリアルタイム動作させるオープン規格「WebGL」だ。

　これまで，Webブラウザ上での3Dグラフィックスといえば，何かのプラグインソフトを導入して実現されるものだった。万人が見られてしかるべきWebコンテンツの在り方としては，疑問符の残るものだったわけだ。
　AppleがiOSで頑ななまでにFlashをサポートしようとしない原因の一端も，このあたりの話にあったりするわけである。

　その点WebGLは，「HTML5」規格の一部に盛り込まれるため，プラグイン不要でWebブラウザ上での3Dグラフィックスを利用できる。もう少し具体的に説明すると，「OpenGL ES 2.0相当の3DグラフィックスをJavaScriptから扱えるようにするもの」だ。

　WebGLで扱える3Dグラフィックスは，インタラクティブコンテンツとして構成でき，なおかつプラグインソフトのような矩形領域表示だけに限定されないという特徴が挙げられる。動画，静止画，3Dグラフィックスを自由に合成して，これらをCSSでWebページへと自在にレイアウトができるわけだ。
　つまり，HTML5とWebGL，そしてJavaScriptの組み合わせは，ある種1つのソフトウェアプラットフォームになり得ると言えよう。
　このプラットフォームを「有望なゲーム用オープンプラットフォーム」と見ているゲームスタジオは，今や少なくない。

　WebGL 1.0ついてだが，GDC 2011で正式発表されたが，SIGGRAPH 2011でもいくつかのアップデートが報告されている。

　WebGL 1.0のトピックは，Typed Array（型付け配列）変数仕様の実装形態やその動作検証が5月から開始されたことと，事実上のバグフィックス版であるWebGL 1.0.1の規格策定が始まったこと。とくに前者は，「ダイナミックなコンテンツには，バルクデータの取り扱いが必要不可欠」という事情もあるだけに，最終的な仕様の動向を世界中の開発者達が見守っている。

WebGLはAPIであるため，利用するには3Dグラフィックスの知識が必要不可欠。このため，サードパーティによってWebGLを簡単に利用するためのミドルウェア開発が進められている

　これに関してもう一つ，機能の拡充と動作の安定性強化が進められ，WebGLベースのミドルウェア開発プロジェクトが始まったことも紹介しておきたい。
　WebGLは，いわば「Web版のOpenGL ES」だが，Webプログラマの多くは3Dグラフィックスには慣れ親しんでいないため，3DグラフィックスをHTML5で簡単に利用できるエンジンの構築が開始されたというわけである。始動したばかりということもあり，本格的な普及にはまだ時間がかかるとも思われるが，いずれ，HTML5とWebGLで動作するゲームエンジンなども出てくるはずである。

　このほかKhronosでは，WebGLのセキュリティホールを見つけ出すことにも注力しているそうだ。
　例えば，わざと無限ループを持つシェーダを実行し，その間に画面をキャプチャしてネットに送出するような，スパイウェア型ウイルスが技術的には実現可能であることから，これらをどのように検出していくのか，そして発見後に潰せるのかを調査・検討しているという。
　とはいえ，これらはWebGL単体の問題ではなく，Webブラウザや，HTML 5の仕様にも深く関係している部分であるため，関係部署と相互連携して進めているとのことだ。

現在では，Firefox，Safari，ChromeがデフォルトでWebGLを有効化しているブラウザとなる

Khronosは，WebGLを取り巻くセキュリティ問題にも取り組んでいるとのこと

現実味が増してきたWebCL

　GDC 2011の会期中，Khronosは，HTML5に組み込まれる新API群として「WebCL」の存在を明らかにしたが，今回のSIGGRAPHでもWebCLにまつわるアップデートを報告している。

　ところで，WebCLとはなにか。
　簡単に言うならば「HTML版のOpenCL」である。HTML5版のOpenGL ESといえるWebGLと似たような位置づけと考えておいていいだろう。OpenCLは，データ並列コンピューティングを行うためのプログラミング言語もしくはフレームワークとして，実際に活用されているが，Webページ上でもこれを利用可能にしようとするのがWebCLということになる。ちなみにCLとは「Computing Language」の略だ。

　WebGLに加えて，HTML5上でWebCLが利用可能になるとということは，「3Dグラフィックスと物理シミュレーションを駆使したWebページを動作させられるようになる」というのと同義だ。あるいは，ビデオ編集や本格的なフィルタ処理などを備えたフォトレタッチソフトがHTML5だけで動作するようにもなるといえる。「そんなことできるの？」と思った人も少なくないだろうが，WebCLに注力しているNokiaとSamsungが公開している動画を見れば，これが夢物語でないことが分かるだろう。

　Nokiaは，WebCLの特設サイトを設けており，WebCLを用いた本格的なフォトレタッチWebツールの試作版を動画で公開している。下に掲載したのがそれだ。

このインタラクティブデモを試すには，Firefox 5以降と同サイトで公開されているプロトタイプ版WebCLのインストールが必要だ

　また，同サイトでは，実動WebCLを用いたインタラクティブデモの体験ページも公開されている。このインタラクティブデモは，WebCLで画像処理を実行した場合と，JavaScriptで実行した場合とを比較できるもので，実際にユーザー自身のPCでWebCLのパフォーマンスを実感できるものになっている。

　Samsungも，1024個のパーティクルを用いたN-BODYシミュレーションデモや写真の上に水滴をこぼしたようなエフェクト処理を，プロトタイプ版WebCLを利用した場合とJavaScriptを利用した場合とのパフォーマンス比較を公開している。これらのデモムービーを下に掲載したので，ぜひ確認してみてほしい。



　こうしたデモを目の当たりにすると，Webページで本格的なゲームや実用アプリが登場するのも夢物語ではないということが実感として分かってくるはずだ。

WebCLはOpenCLのWeb版的な存在であるとのことだ

現在公開されているWebCL関連のリソースを示したスライド

　さて，Khronosは，WebCLの立ち上げのために2011年よりワーキンググループを発足させているのだが，今回，Trevett氏がそのワーキンググループ内での議論で固まった「現時点におけるWebCLの方向性と規格策定」の進捗状況について話してくれている。
　Trevett氏によれば，WebCLはできるだけOpenCLと同等に，ハードウェアに近いローレベルな形でまとめていくことが決定したという。ミドルウェア的なものは，ミドルウェアメーカーに委ねることとし，基礎的なフレームワーク仕様と言語仕様のみを規定することにしたそうだ。OpenCLベースの物理シミュレーションライブラリ（エンジン）などに，Khronosとして関与したりはしないという。
　なお，誤解のないよう念のため書き記しておくと，WebCLの最終仕様は未だ確定していない。

新API「StreamInput」とは？

　最近のスマートフォンやタブレット，そのほかの携帯型電子機器は，画面のマルチタッチだけでなく，GPS，加速度センサー，電子コンパスなど，ありとあらゆるセンサーが1つの本体へと同時に組み込まれていることが珍しくない。

　そのため，OS開発者やアプリケーション開発者は，その機器に内蔵された多様なデバイス（センサー）群の状態を取得するために，そのデバイス（センサー）メーカーから提供されたデバイスドライバを活用しなければならない。搭載されているセンサーのメーカーが異なったりすると，複合的なセンシングを行わざるを得なくなり，全デバイスドライバの仕様を理解する必要があり，開発負荷がかなり大きくなる。
　しかも，こうした苦労の末できあがったOSやアプリは，特定メーカーの特定センサーが持つ仕様に深く依存した設計となってしまう。結果，センサー類が変わっただけで，プログラムの大幅な改変が必要になるという事態が生じるのである。
　多様なセンサー類を活用するOSやアプリでは，どうしても移植性（ポータビリティ）が低くなるという問題が起きているのだ。

　こうした問題に取り組むべく，Khronos内で発足したのが「Input Working Group」。このInput Working Groupによって開発検討されているのが「StreamInput」と呼ばれる新APIである。

Khronosが規格策定に乗り出しているのが新APIのStreamInputだ

StreamInputプロジェクトに参加している企業群を示したスライド。ちなみにPrimeSenseは，「Kinect」に採用されている深度センサーを開発したメーカーである

　Khronosは，GDC 2011会期中に「OpenInput」という仮称の新API規格を策定し始めたことを明らかにしたが，SIGGRAPHまでの間にワーキンググループ内で議論が交わされた結果，StreamInputへプロジェクト名が改称されたのだという。
　この名称についてTrevett氏は，「StreamInputも開発コードネームに過ぎないが，大きな反対がなければこのまま正式名称になるだろう」と述べたうえで，「土壇場で『OpenSI』になったりする可能性は否定できないが」と付け加えていた。

StreamInputは，入力インタフェースの合理的なモジュール化を推し進めるのに有効な手段となる

　さてこのStreamInputだが，スマートフォンやタブレット端末に採用されているジェスチャー入力やモーション入力をシステマティックに取り扱えるようにするAPIである。誤解のないようあらかじめ断っておくと，これはWebGLやWebCLといったHTML5関連技術とは（少なくとも今のところは）無関係であり，どちらかといえば組み込み機器向けのAPIという理解をしておけばいいだろう。「さまざまなセンサー類が取得したパラメータを取りまとめて，アプリケーションが欲する情報の形にして返す」という役割を担うことになる。

　StreamInputのプログラマーは，センサー群から取得した情報をどう処理するかを組み立て，機能ブロックの1つ1つをノードとして定義していく。各ノード同士をどうつなげるかも定義できるうえ，各ノードのプログラミングにOpenMAXやOpenCLを利用することが可能だ。
　つまり，センサー類が変更された場合は，StreamInputで構築した機能モジュールのほうを修正したり，再開発したりすれば，その上層のOSやアプリケーションは改編なしで動作させられるということになる。

　例えば，「狙って撃つ」というゲームアプリがあった場合，StreamInputプログラマは，StreamInputで「狙う」「撃つ」というアクションを返すことができる機能ブロックを開発する必要がある。
　タッチインタフェースに対応した「狙う」「撃つ」というアクションを返す機能ブロックを作れば，ゲームアプリはタッチインターフェース対応のものになる。ここで，Kinectのようなジェスチャー認識システムに対応させれば，ゲームアプリ側を無改編でKinect対応に生まれ変わらせることができるというわけだ。
　StreamInputは，入力インターフェースの合理的なモジュール化を推し進めるための有効な手段となるだけでなく，異なるハードウェアでアプリケーションを透過的に動かすことにも貢献するといえる。

StreamInputを利用して拡張現実アプリを構築した場合のプロックダイアグラム。センサーの利用と認識をアプリから切り離している点が特徴である

OpenGL 4.2の発表でDirectXが今後どう動くのかに注目したい

　SIGGRAPH 2011におけるKhronosの発表をまとめると，DirectX 11を超えたと謳うOpenGL 4.2の発表，WebGLの本格普及に向けての洗練化，正式リリース前の最終調整に入ったWebCL，StreamInputのコンセプト決定といったところだろうか。
　なかでもOpenGL 4.2は，業界に与える影響が大きそうである。OpenGL 4.2の拡張機能のうち，Image_load_Store and Atomic Counters，Transform Feedback Instanced Example，Compressed Pixel Texture Storageの3つは，とくに開発者に歓迎されているそうで，DirectX 11のマイナーチェンジ版（出ればの話だが）にも搭載されてくることだろう。ちなみに，Compressed Pixel Texture Storageは，Blizzard Entertainmentから要求があった拡張仕様とのこと。

　DirectXがこのあとどう動いてくるか，その動向も含め，今後も注目し続ける必要がありそうだ。