つぶやく
2011/08/23 00:00ニュース
［SIGGRAPH］ついにDirectX 11を凌駕した!? Khronosに聞く「OpenGL 4.2」の正体
 Khronosに属するメンバー企業を示したスライド |
 Khronosが規格策定に携わっているオープンスタンダードAPI群がこのスライドに示されている |
そんなKhronosはこのところ「Game Developers Conference」（以下，GDC）と「SIGGRAPH」の会期中に大きな発表を行うのが慣習化しているのだが，SIGGRAPH 2011でもやはりいくつか重要な発表がなされたので，その内容をレポートしよう。
DirectX 11を大きく凌駕するというOpenGL 4.2
というわけで，SIGGRAPH 2011におけるKhronos最大のトピックは，3Dグラフィックス向けオープンスタンダードAPI「OpenGL 4.2」の発表である。
 |
 |
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では，メモリ容量が許す範囲ならばいくつでも書き込みできるうえに，読み出しも行えるようになっている。
 |
実のところ，これらの機能は，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回繰り返したことになるわけだ。
 |
これは，テッセレーションステージによって分割・変形された3Dモデルを，そのままキャプチャして再利用できるというものだ。
先ほどの例で説明すると，Transform Feedback Instanced Example機能は，視点からの距離が2m変わるごとに再テッセレーションを行うが，そこまで距離が変わらない場合には直近のテッセレーション結果をテッセレーションステージで再利用するという，最適化処理を組み込めるようにする。
また，テッセレーションステージによる処理結果のコピーに対して，個別のインスタンスを与えて，個々に異なる姿勢やアニメーション描画をすることもできるようになる。そのため，テッセレーションステージを用いて同型モデルの雑魚キャラなどを多数描画する場合に，劇的な最適化効果を得られることになるのだ。
●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のソフトウェア階層ダイアグラムを示したスライド |
これまで，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は，いわば「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ツールの試作版を動画で公開している。下に掲載したのがそれだ。
 |
Samsungも，1024個のパーティクルを用いたN-BODYシミュレーションデモや写真の上に水滴をこぼしたようなエフェクト処理を，プロトタイプ版WebCLを利用した場合とJavaScriptを利用した場合とのパフォーマンス比較を公開している。これらのデモムービーを下に掲載したので，ぜひ確認してみてほしい。
こうしたデモを目の当たりにすると，Webページで本格的なゲームや実用アプリが登場するのも夢物語ではないということが実感として分かってくるはずだ。
 WebCLはOpenCLのWeb版的な存在であるとのことだ |
 現在公開されているWebCL関連のリソースを示したスライド |
Trevett氏によれば，WebCLはできるだけOpenCLと同等に，ハードウェアに近いローレベルな形でまとめていくことが決定したという。ミドルウェア的なものは，ミドルウェアメーカーに委ねることとし，基礎的なフレームワーク仕様と言語仕様のみを規定することにしたそうだ。OpenCLベースの物理シミュレーションライブラリ（エンジン）などに，Khronosとして関与したりはしないという。
なお，誤解のないよう念のため書き記しておくと，WebCLの最終仕様は未だ確定していない。
新API「StreamInput」とは？
最近のスマートフォンやタブレット，そのほかの携帯型電子機器は，画面のマルチタッチだけでなく，GPS，加速度センサー，電子コンパスなど，ありとあらゆるセンサーが1つの本体へと同時に組み込まれていることが珍しくない。
そのため，OS開発者やアプリケーション開発者は，その機器に内蔵された多様なデバイス（センサー）群の状態を取得するために，そのデバイス（センサー）メーカーから提供されたデバイスドライバを活用しなければならない。搭載されているセンサーのメーカーが異なったりすると，複合的なセンシングを行わざるを得なくなり，全デバイスドライバの仕様を理解する必要があり，開発負荷がかなり大きくなる。
しかも，こうした苦労の末できあがったOSやアプリは，特定メーカーの特定センサーが持つ仕様に深く依存した設計となってしまう。結果，センサー類が変わっただけで，プログラムの大幅な改変が必要になるという事態が生じるのである。
多様なセンサー類を活用するOSやアプリでは，どうしても移植性（ポータビリティ）が低くなるという問題が起きているのだ。
こうした問題に取り組むべく，Khronos内で発足したのが「Input Working Group」。このInput Working Groupによって開発検討されているのが「StreamInput」と呼ばれる新APIである。
 |
 |
 |
この名称についてTrevett氏は，「StreamInputも開発コードネームに過ぎないが，大きな反対がなければこのまま正式名称になるだろう」と述べたうえで，「土壇場で『OpenSI』になったりする可能性は否定できないが」と付け加えていた。
 |
StreamInputのプログラマーは，センサー群から取得した情報をどう処理するかを組み立て，機能ブロックの1つ1つをノードとして定義していく。各ノード同士をどうつなげるかも定義できるうえ，各ノードのプログラミングにOpenMAXやOpenCLを利用することが可能だ。
つまり，センサー類が変更された場合は，StreamInputで構築した機能モジュールのほうを修正したり，再開発したりすれば，その上層のOSやアプリケーションは改編なしで動作させられるということになる。
例えば，「狙って撃つ」というゲームアプリがあった場合，StreamInputプログラマは，StreamInputで「狙う」「撃つ」というアクションを返すことができる機能ブロックを開発する必要がある。
タッチインタフェースに対応した「狙う」「撃つ」というアクションを返す機能ブロックを作れば，ゲームアプリはタッチインターフェース対応のものになる。ここで，Kinectのようなジェスチャー認識システムに対応させれば，ゲームアプリ側を無改編でKinect対応に生まれ変わらせることができるというわけだ。
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がこのあとどう動いてくるか，その動向も含め，今後も注目し続ける必要がありそうだ。
- 関連タイトル：
OpenGL - この記事のURL：
4Gamer.net最新情報
プラットフォーム別新着記事
総合新着記事
企画記事
新着連載
新着レビュー
