つぶやく
2012/10/17 00:00ニュース
OpenGLはDirectX 11を超え，OpenGL ESは据え置き型ゲーム機と同等以上に。Khronosの最新動向レポート
 |
1つは，PCおよびワークステーション向けのグラフィックスAPIである「OpenGL」の新バージョン「OpenGL 4.3」だ。そしてもう1つは，組み込み向けのグラフィックスAPIである「OpenGL ES」の新バージョン「OpenGL ES 3.0」である。
筆者は，SIGGRAPH 2012のタイミングで，Khronosのプレジデントを務めるNeil Trevett（ニール・トレヴェット）氏にインタビューできたので，今回はそれを基に，OpenGL 4.3とOpenGL ES 3.0のポイントをまとめてみたい。
もはやポテンシャルは据え置き機以上となった
OpenGL ES 3.0
 |
OpenGL ES（OpenGL for Embedded Systems）は，クロスプラットフォームかつロイヤリティフリーなオープングラフィックスAPIであるOpenGLから派生した組み込み（Embedded Systems）向けAPIだ。第1世代のOpenGL ES 1.0が登場したのは2003年頃で，2007年にはプログラマブルシェーダアーキテクチャに対応したOpenGL ES 2.0が登場。近年，ミドルクラス以上のスマートフォンやタブレット（のSoC）で広く採用されている。
今回発表されたOpenGL ES 3.0は，OpenGL ES 2.0への後方互換性を維持しつつ，業界内で生じた要望を取り入れ，なおかつPCやワークステーション向けとなるOpenGL 3.3やOpenGL 4.xが持つ機能との親和性を高める方向での強化が図られたものという位置づけだ。Khronosは，OpenGL 3.3やOpenGL 4.xベースのアプリケーションを移植する難度は，OpenGL ES 3.0で劇的に低下したとしている。
OpenGL ES 3.0とOpenGL 4.xとの間にある大きな違いは，「OpenGL ES 3.0にはジオメトリシェーダやテッセレーションステージが用意されていない」点だ。それ以外の仕様は共通する点が多いというわけだが，以下，Khronosが「ホットトピック」として挙げているOpenGL 3.0の新要素を，項目別にチェックしてみることにしよう。
■テクスチャ関連機能の拡張
OpenGL ES 3.0ではテクスチャフォーマットにまつわる旧世代の制約がほぼすべて取り払われた。
一例を挙げると，OpenGL ES 3.0では，一辺が2のべき乗（あるいは累乗）サイズに限定されない。OpenGL ES 3.0では256×256テクセルのような2のべき乗サイズだけではなく，257×257テクセルなどといった，16進数的にキッチリしないサイズのテクスチャも扱える。
また，RGBのRだけなどといった1要素テクスチャ，あるいは2要素テクスチャを扱えるようになったため，画面座標系のベロシティ（velocity，速度）情報，法線ベクトルのような汎用数値の格納も行いやすくなっている。
テクスチャの配列管理――いわゆるTexture Array（テクスチャアレイ）――や，「空間をスライスしたようなボクセル的な情報」の格納に便利な，3Dテクスチャのサポートも付け加えられた。
 |
ゲームグラフィックスの描画に直接“効いて”くる新要素としては「Depth Textures with Shadow Compares」（影判定を伴ったデプステクスチャ）が挙げられるだろう。
これは一部のOpenGL ES 2.0プラットフォームで拡張仕様として使われていたもので，デプスシャドウ技法における「影か否か」判定をアクセラレーションできる機能になる。
■OpenGL 4.3との共通要素として加わった
■新しいテクスチャ圧縮法（1）〜ETC2/EAC
開発者の間では「2012年のOpenGL ES 3.0とOpenGL4.3の発表で，この部分が一番ホットである」とさえ言われているのが，新しいテクスチャ圧縮法「ETC2」「EAC」だ。私見を挟ませてもらうなら，これはMicrosoftのDirectX側も早急に対応が迫られる要素だといえる。
まずは，標準仕様として組み込まれたETC2からだが，これはスウェーデンのTelefonaktiebolaget LM Ericsson（以下，Ericsson）が開発したフォーマットだ。ETCは「Ericsson Texture Compression」の略で，ETC1がRGBテクセル構成専用の圧縮法だったのに対し，ETC2はαチャネルを含むフォーマットにも対応させてきたのが大きな特徴となる。
もう1つのEAC（※何の略か現在のところ不明）は，やはりEricssonが開発したテクスチャ圧縮技法で，ETCのアルゴリズムを1要素テクスチャと2要素テクスチャに適用したものだ。そのため実際には「ETC2のみ」「EACのみ」「ETC2＋EAC」といった運用がなされることになる。
 |
■OpenGL 4.3との共通要素として加わった
■新しいテクスチャ圧縮法（2）〜ASTC
OpenGL ES 3.0では，ハイダイナミックレンジ（HDR）テクスチャの圧縮にも対応した。1要素〜4要素までのテクスチャを高画質に圧縮する新技法「ASTC」が，「Khronos標準拡張仕様」の形でサポートされたのだ。
ASTCを開発したのは組み込みの世界の巨人，ARMである。ただ，ASTCの「A」はARMの略ではなく，全体が「Adaptive Scalable Texture Compression」（適応型かつ可変長なテクスチャ圧縮）と略とされている。
さて，ASTCは「まさに新世代のテクスチャ圧縮技法」といった感じであり，アルゴリズムは複雑。デコードには専用ハードウェアロジックが必須だ。
テクスチャ圧縮のアルゴリズムにおいて，シェーダユニットは与えられたテクスチャ座標から一意的にテクセルをサンプルできなければならないので，基本的には，モードごとに圧縮率を固定化したアルゴリズムでなければならい。
それに対しASTCでは，圧縮対象テクチャの特質ごとに，モードのバリエーションが非常に豊富となっているのだ。そのため，「Adaptive」（適応型）というキーワードが名前に入っているのである。
またDXTC（＝S3TC）などのクラシックなテクスチャ圧縮技法だとブロックサイズは4×4テクセルで固定化されていたが，ASTCでは4×4テクセル〜12×12テクセルまでの可変サイズとなっている。これが「Scalable」（可変長）というキーワードの由来だ。
より詳細なアルゴリズムには，ARMによるASTCの解説ページ（英語）を参照してほしい。
 |
なお，ASTCもロイヤリティフリーの技術として公開されており，OpenGL ES 3.0およびOpenGL 4.3時点では前述のとおり「Khronos標準拡張仕様」という扱いになっているが，近い将来，OpenGLおよびOpenGL ESの標準仕様に組み込まれる見込みとなっている。筆者も，NVIDIAの次世代GPU――TegraなのかGeForceなのかは不明――がASTCのハードウェアデコーダを実装する計画があるという情報を掴んでいるので，ASTCは今後，業界内で広く普及していく可能性がありそうだ。
 |
■最新世代のプログラマブル
■レンダリング手法に対応
冒頭で述べたとおり，OpenGL ES 2.0もプログラマブルシェーダアーキテクチャに対応しているが，OpenGL ES 3.0では，その機能が一気に，OepnGL 3.3＆4.xやDirectX 9＆10に近いものにジャンプアップした。
CPUパワーとバス性能にそれほど余裕がない組み込みの世界では，CPUとGPU間で生じるデータのやりとりを抑えたい。
そこでOpenGL ES 3.0では，「Instanced Rendering」（インスタンストレンダリング）がサポートされた。これは，DirectX 9.0c世代でアピールされた「Geometry Instancing」（ジオメトリインスタンシング）に相当する機能だ。具体的には，3Dモデルの形状（＝ジオメトリ）が同一の場合，一度それをGPU側に転送したあとは，座標位置やアニメーション，テクスチャのパラメータ違いで複数個を一気にレンダリングできる機能であある。
「Transform Feedback」（トランスフォームフィードバック）もついにOpenGL ESからサポートされるようになる。
Tranform Feedbackは，頂点ステージの処理結果を頂点バッファオブジェクト（Vertex Buffer Object，VBO）に格納する機能で，DirectX 10のジオメトリシェーダで用意される「Stream Output」に相当するもの。OpenGLではOpenGL 3.0からサポートされているが，今回，OpenGL ES 3.0でも利用できるようになった次第だ。
 |
またOpenGL ES 3.0では，複数のレンダーターゲットに同時出力できる「MRT」（Multi Render Target）もサポートされる。OpenGL ES 3.0の仕様上は，MRT4（最低でも4つのレンダーターゲットに対するMRTのサポート）を保証する必要があるとのことだ（※DirectX 10以降ではMRT8）。
ちなみに，SIGGRAPH 2012のレポートで紹介した「『Mali-T604』のDeferred Renderingデモ」は，MRT4を活用したものだったりする。
 |
なおそのほか，これから描画する3Dオブジェクトの遮蔽率を求める機能である「Occlusion Queries」（オクルージョンクエリ）などもOpenGL ES 3.0ではサポートされる。
■OpenGLアプリとOpenGL ESアプリの
■相互移植性を高める拡張タグ追加
Khronosでは，「将来的に，ゲームを含むPC/ワークステーション向けアプリケーションが携帯機器向けに移植されたり，あるいは逆のパターンが発生したりするケースが多くなる」と見込んでいる。そして，そのときプログラムの書き換えを最小限にするために，OpenGL 4.3とOpenGL ES 3.0で横断的に利用できる拡張仕様APIを両APIに追加した。
タグは「KHR_」。前出のASTCは，まさにこのKHR_タグの範疇に入る機能となる。
■OpenGL ES 3.0専用ベンチマークの発表
OpenGL ES 3.0に合わせ，OpenGL ES 3.0の機能を積極的に活用したベンチマークソフト「GLBenchmark 3.0」も発表された。
開発したのはハンガリーのKishonti Informaticsで，MRTを活用したDeferred Renderingベースのグラフィックスエンジンで動作しているという。
 |
GLBenchmark 3.0のレンダリングエンジンで興味深いのは，Occlusion Queriesを，Deferred Renderingにおける「動的光源によるライティング/シェーディング」の可否判定に用いている点だ。シーン内へ無数に置かれた動的光源について，実際にライティング/シェーディング処理するかの判断を，事前にOcclusion Queriesの機能を使ってしてしまうのである。
正式リリースは未定だが，現在はシーンの一部が予告編の形で公開されているので，下に紹介しておく。
20歳を迎えたOpenGLは「4.3」に
 |
これを記念してジョークスライドが公開されている。右がそれで，「1992年に建国されたOpenGL国は，2004年のOpenGL 2.0でピクセルシェーダ大陸を発見し，2008年のOpenGL 3.0でVertex Array Object渓谷に上陸。そして2012年，OpenGL 4.3でCompute Shader平原に達した」という“地図”である。
RealityEngineでは1500Wの電力を消費して毎秒100万ポリゴンの処理能力を獲得していたが，GPUの処理能力も，今や5W以下の携帯機で100倍以上の性能があり，200W（図に書かれていないのはご愛敬？）のハイエンドGPUであれば1800倍の性能が発揮できるのだ。
 |
| OpenGL今昔物語 |
 |
| OpenGL進化の歴史 |
さて，アニバーサリーイヤーの最新OpenGLは「4.3」となった。OpenGL ES 3.0と同じように，その見どころをまとめてみることにしよう。
■Compute Shaderへの対応〜OpenCLとは共存
 |
 |
そうなると「じゃあ，OpenCLはどうなるの？」という話になるわけだが，Khronosは「Compute ShaderとOpenCLは共存する」立場をとっている。
Compute ShaderはOpenGLの一部となるため，OpenGLで取り扱うグラフィックス関連のリソースを，頂点シェーダやピクセルシェーダ，ジオメトリシェーダ，テッセレーションステージ内のシェーダで共有できる。「グラフィックスに近い目的の用途では，OpenCLよりもCompute Shaderを使うべきだ」というのがKhronosの（新しい）言い分だ。
 |
| PC版Battlefield 3では，Compute Shaderを駆使したレンダリングエンジンが採用されていた |
 |
| 実際のOpenGL Compute Shader物理シミュレーションサンプル。グラフィックスに近いGPGPU処理は，Compute Shaderで処理したほうが都合がいい |
OpenGL 4.3のCompute Shaderは，当然のことながらOpenGLフレームワークに属するため，プログラミング言語体系はシェーダプログラミング言語「GLSL」の系譜となる。フル仕様のANSI CベースとなるOpenCLとはプログラミングモデルの形態が微妙に異なるわけだ。グラフィックス系プログラマーにとっては，Compute Shaderのほうが馴染みやすい。
またKhronosは，「OpenGL 4.3の登場以降も，一般アプリケーションにおいてはOpenCLの優位性は変わらない」と主張している。
OpenCLは，マルチコアCPUやマルチGPU，あるいはCPU＋GPUに対して透過的にデータ並列コンピューティングのプログラムを走らせることができる。しかし，OpenGL 4.3のCompute Shaderはその構造上，単一のGPU内でしか走らせることができない。純粋な異種混合コンピューティングには，OpenCLのほうが向いているのだ。
1つ具体例を示すと，Adobeは「Photoshop」において，負荷の高い処理系の実装をOpenCLで進めていくという。それは，1つのOpenCLコードを，改変することなく，マルチコアCPUやCPU＋GPUといった複数の構成で動作させられるためだという。
 |
■汎用のメモリ領域を確保可能に
OpenGL 4.3では，Compute Shaderとグラフィックスパイプライン内のシェーダとの間で協調処理を行ったり同期を取ったりするために，汎用のメモリ領域を確保できるようになった。
確保先はGPUのローカルメモリ内になるので，CPU管轄下のシステムメインメモリよりもかなり高速に扱えることになる。
 |
 |
 |
■OpenGL ES 3.0との互換性の確保
■ETC2/EAC，ASTCも利用可能
PCやワークステーションと携帯機器の機能差が縮まっており，グラフィックスアプリケーションソフトにおいても，それぞれのバージョン間で，実装される機能や提供される機能の格差がなくなっていくと見込まれている。そうなると，グラフィックスアプリケーション開発者のなかでは，PCあるいはワークステーション版と携帯機器版とで同一コードを走らせたいという要望も強くなってくるだろう。そうでなくても，「PCやワークステーション側でプロトタイプを作成して，携帯機器版に持っていく」という，開発スタイル高効率化への期待は，今後ますます強くなるだろう。
そうした動向に応えるべく，OpenGL 4.3では，OpenGL ES 3.0との互換性が取られることになった。分かりやすく言い変えるならば，OpenGL 4.3は，OpenGL ES 3.0のスーパーセットになったということだ。
ETC2/EACおよびASTCに対するテクスチャ圧縮メソッドへの対応状況も，OpenGL ES 3.0に準じたものになる。
ゲームグラフィックス用APIとして，進化の止まった
DirectXに代わりOpenGLが再注目されている？
DirectX開発のコアメンバーは，Windows 8の登場後に本格始動する“かつてMetroと呼ばれていたユーザーインタフェースおよびサービス”およびそのためのAPIである「WinRT」の開発に回っているとされている。さらに，DirectXアーキテクトのDavid Blythe氏がIntelへ移籍してしまうなど，状況証拠から判断する限り，Microsoftは今のところ，DirectXに関して現状維持の体制をとっているように見える（※付記しておくと，Windows 8で統合されるDirectXは11.1だ）。
一方のOpenGLは，Khronosの管理下になって以降，開発コミュニティからの反応をまとめ，仕様の協議を毎年行っているため，進化が加速している。
 |
| DOOM 3 （C）2012 Bethesda Softworks LLC. Trademarks belong to their respective owners. All Rights Reserved |
 |
| Left 4 Dead 2 （C）2009 Valve Corporation. All rights reserved. Valve, the Valve logo, Left 4 Dead, the Left 4 Dead logo, Source, the Source logo, Half-Life, Counter-Strike, Portal and Team Fortress are trademarks or registered trademarks of Valve Corporation in the United States and/or other countries. |
DirectX 9世代におけるゲームグラフィックスのマイルストーン的存在となった「DOOM 3」（2004年）。そのソースコードが昨年公開され，OpenGLベースのゲームグラフィックス開発でお手本となりつつある。
そうした動向を受けてか，Valveは同社のヒット作「Left 4 Dead 2」をOpenGLベースでLinux上に移植し，Steamで2012年7月から配信を開始している。開発メンバーが，同一ハードウェア上でWindows（≒DirectX）版とLinux（≒OpenGL）版のLeft 4 Dead 2を動かし，その性能比較を公式blogで公開したことは，大きな反響を呼んだ。後者のほうが20％も性能が高かったのは，一部でセンセーショナルに報道されたりしたほどだ。
 |
家庭用ゲーム機も次世代機が噂され始めた最近だけに，最新グラフィックスAPIの動向は今後，ますますホットなテーマになっていくはずだ。注目していく必要があるだろう。
Khronos公式Webサイト（英語）
- 関連タイトル：
OpenGL - この記事のURL：
4Gamer.net最新情報
プラットフォーム別新着記事
総合新着記事
企画記事
新着連載
新着レビュー
新着インタビュー
