2013年3月15日星期五

OpenGLはDirectX 11を超え,OpenGL ESは据え置き型ゲーム機と同等以上に。Khronosの最新動向レポート THQ

Neil Trevett氏(President, Khronos Group)。氏はNVIDIAのMobile Content部門副社長でもある
 OpenGLやOpenCLなど,さまざまなオープンAPI規格を司るKhronos Group(クロノスグループ,以下 Khronos)は,2012年8月のSIGGRAPH 2012に合わせて,2つの大きな発表を行っている。

 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


2013年度以降,ハイエンドスマートフォンのグラフィックスは,一気にOpenGL ES 3.0へ移行すると言われている。それくらい注目のAPIだ
 冒頭で紹介した順番からすれば,OpenGL 4.3のほうから紹介していくのが妥当だが,今回は,開発コードネーム「Halti」(ハルティ)として,長い間その登場が待ち望まれてきた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テクスチャのサポートも付け加えられた。

ARMによるレースゲーム風技術デモ。影生成には新機能を活用しているとのことだ

 ゲームグラフィックスの描画に直接“効いて”くる新要素としては「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」といった運用がなされることになる。

Ericssonが開発した新しいテクスチャ圧縮技法がOpenGL ES 3.0で正式採用に(※OpenGL 4.3においても標準仕様として採用されている)。Ericsson製だが,当然のことながらロイヤリティフリーなので,使用にあたって特許使用料の支払いは発生しない

■OpenGL 4.3との共通要素として加わった
■新しいテクスチャ圧縮法(2)?ASTC

 OpenGL ES 3.0では,ハイダイナミックレンジ(HDR)テクスチャの圧縮にも対応した。1要素?4要素までのテクスチャを高画伽藞R縮する新技法「ASTC」が,「Khronos標準拡張仕様」の形でサポートされたのだ。
 ASTCを開発したのは組み込みの世界の巨人,ARMである。ただ,ASTCの「A」はARMの略ではなく,全体が「Adaptive Scalable Texture Compression」(適応型かつ可変長なテクスチャ圧縮)と略とされている。

 さて,ASTCは「まさに新世代のテクスチャ圧縮技法」といった感じであり,アルゴリズムは複雑。デコードには専用ハードウェアロジックが必須だ。
 テクスチャ圧縮のアルゴリズムにおいて,シェーダユニットは与えられたテクスチャ座標から一意的にテクセルをサンプルできなければならないので,基本的には,モードごとに圧縮率を固定化したアルゴリズムでなければならい。

 それに対しASTCでは,圧縮対象テクチャの特伽搐趣耍猢`ドのバリエーションが非常に豊富となっているのだ。そのため,「Adaptive」(適応型)というキーワードが名前に入っているのである。
 またDXTC(=S3TC)などのクラシックなテクスチャ圧縮技法だとブロックサイズは4×4テクセルで固定化されていたが,ASTCでは4×4テクセル?12×12テクセルまでの可変サイズとなっている。これが「Scalable」(可変長)というキーワードの由来だ。

 より詳細なアルゴリズムには,(英語)を参照してほしい。

ATSCにおける,ブロックサイズと,1ピクセルあたりのbit数(BPP,Bit Per Pixel),圧縮率の関係対応。同じBPPならば従来手法よりもノイズが乗りにくいのがASTCの特徴だ

 なお,rmt,ASTCもロイヤリティフリーの技術として公開されており,OpenGL ES 3.0およびOpenGL 4.3時点では前述のとおり「Khronos標準拡張仕様」という扱いになっているが,近い将来,OpenGLおよびOpenGL ESの標準仕様に組み込まれる見込みとなっている。筆者も,NVIDIAの次世代GPU——TegraなのかGeForceなのかは不明——がASTCのハードウェアデコーダを実装する計画があるという情報を掴んでいるので,ASTCは今後,業界内で広く普及していく可能性がありそうだ。

ASTCは近未来的にOpenGL ES(&OpenGL)の標準仕様へ

■最新世代のプログラマブル
■レンダリング手法に対応

 冒頭で述べたとおり,OpenGL ES 2.0もプログラマブルシェーダアーキテクチャに対応しているが,OpenGL ES 3.0では,その機能が一気に,OepnGL 3.3&4.xやDirectX 9&10に近いものにジャンプアップした。

 CPUパワーとバス性能にそれほど余裕がない組み込みの世界では,CPUとGPU間で生じるデータのやりとりを抑えたい。
 そこでOpenGL ES 3.0では,rmt,「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でサポートされる

 またOpenGL ES 3.0では,複数のレンダーターゲットに同時出力できる「MRT」(Multi Render Target)もサポートされる。OpenGL ES 3.0の仕様上は,MRT4(最低でも4つのレンダーターゲットに対するMRTのサポート)を保証する必要があるとのことだ(※DirectX 10以降ではMRT8)。
 ちなみに,「『Mali-T604』のDeferred Renderingデモ」は,MRT4を活用したものだったりする。

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」も発表された。
 開発したのはハンガリーので,MRTを活用したDeferred Renderingベースのグラフィックスエンジンで動作しているという。

GLBenchmark 3.0のスクリーンショット
 シーンに登場する自動車はジオメトリインスタンシングによって描画され,影描画にはDepth Textures with Shadow Comparesが利用される。
 GLBenchmark 3.0のレンダリングエンジンで興味深いのは,Occlusion Queriesを,Deferred Renderingにおける「動的光源によるライティング/シェーディング」の可否判定に用いている点だ。シーン内へ無数に置かれた動的光源について,実際にライティング/シェーディング処理するかの判断を,事前にOcclusion Queriesの機能を使ってしてしまうのである。
 正式リリースは未定だが,現在はシーンの一部が予告編の形で公開されているので,下に紹介しておく。


20歳を迎えたOpenGLは「4.3」に


OpenGLの世界地図(?)
 OpenGLが誕生したのは1992年。Silicon Graphicsの3Dグラフィックスアーキテクチャ「RealityEngine」とほぼ同時期の誕生とされる。つまり2012年は,OpenGLにとって20歳の誕生年になるのだ。

 これを記念してジョークスライドが公開されている。右がそれで,「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とは共存

Compute ShaderはARB拡張の形態で提供される
 OpenCLを抱えることもあって,これまでKhronosは「GPGPU用途はOpenCLを活用する」というコンセプトを訴えてきたのだが,「グラフィックス寄りのGPGPU処理なら,DirectXのCompute Shader(=DirectCompute)はやっぱり便利である」という声が多く寄せられたのだそうで,OpenGL 4.3では,DirectX 11相当のCompute Shader仕様をそのまま取り入れることになった。

ついにOpenGLにもCompute Shaderが搭載された


 そうなると「じゃあ,OpenCLはどうなるの?」という話になるわけだが,Khronosは「Compute ShaderとOpenCLは共存する」立場をとっている。
 Compute ShaderはOpenGLの一部となるため,OpenGLで取り扱うグラフィックス関連のリソースを,頂点シェーダやピクセルシェーダ,ジオメトリシェーダ,テッセレーションステージ内のシェーダで共有できる。「グラフィックスに近い目的の用途では,OpenCLよりもCompute Shaderを使うべきだ」というのがKhronosの(新しい)言い分だ。

PC版Battlefield 3では,Compute Shaderを駆使したレンダリングエンジンが採用されていた
実際のOpenGL Compute Shader物理シミュレーションサンプル。グラフィックスに近いGPGPU処理は,Compute Shaderで処理したほうが都合がいい
 たとえば,EA DICEのFrostbite 2エンジンを用いたPC版「」では,Deferred Renderingのライティングやシェーディング処理をDirectX 11のCompute Shaderで実装していたが,そういった処理なら,OpenGL 4.3はそのままDirectX 11から持ってこられることになる。

 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といった複数の構成で動作させられるためだという。

OpenCLとOpenGLのCompute Shaderは共存するというのがKhronosの主張だ

■汎用のメモリ領域を確保可能に

 OpenGL 4.3では,Compute Shaderとグラフィックスパイプライン内のシェーダとの間で協調処理を行ったり同期を取ったりするために,汎用のメモリ領域を確保できるようになった。
 確保先はGPUのローカルメモリ内になるので,CPU管轄下のシステムメインメモリよりもかなり高速に扱えることになる。

Compute Shaderとグラフィックス系シェーダとで相互に読み書きできる汎用バッファを確保できるようになった。従来も「読み出し限定」であればできなくはなかったが,OpenGL 4.3では書き込みもOK
新しいテクスチャの参照方法も追加された

■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を見限り始めている」ということはない。しかし,「OpenGLを見直そう」という動きが生まれ始めているのは確かなのだ。
 DirectX 9世代におけるゲームグラフィックスのマイルストーン的存在となった「」(2004年)。そのソースコードが昨年公開され,OpenGLベースのゲームグラフィックス開発でお手本となりつつある。

 そうした動向を受けてか,Valveは同社のヒット作「」をOpenGLベースでLinux上に移植し,Steamで2012年7月から配信を開始している。開発メンバーが,同一ハードウェア上でWindows(≒DirectX)版とLinux(≒OpenGL)版のLeft 4 Dead 2を動かし,その性能比較をことは,大きな反響を呼んだ。後者のほうが20%も性能が高かったのは,一部でセンセーショナルに報道されたりしたほどだ。

OpenGL最新事情
 WindowsでもOpenGLは動くので,ゲームデベロッパ側が,PCゲームをOpenGL 4.3で開発し,それを少ない手間でOpenGL ES 3.0ベースの携帯機器へ移植する……という流れを選択していくことは,自然な流れだともいえる。

 家庭用ゲーム機も次世代機が噂され始めた最近だけに,最新グラフィックスAPIの動向は今後,ますますホットなテーマになっていくはずだ。注目していく必要があるだろう。

 THQは,ウクライナの4A Gamesが開発中のサバイバルシューティング「Metro: Last Light」( / / / )の短編実写ムービーを公開した。
 このムービーは,ゲーム本編が始まる20年ほど前に起きた核戦争において,モスクワ市民たちが地下鉄構内へと避難する様子を描いたものだ。?Moscow Metro?という名の地下鉄は,実際に第2次世界大戦時の空襲時に避難場所として利用され,?世界最大の核シェルター?とも言われている。
 ムービーには,ゲーム開始時に21歳になっている主人公Artyomが幼い姿で登場。どこか切なさが漂う柵筏椁筏の镎Zが展開する。



 Metro: Last Lightは,2010年にリリースされたの続編だ。SF小説家ドミトリー?グルホフスキー氏の小説をベースにしたストーリーで,ファシスト勢力やミュータントと戦いながら,Dark Oneとの決戦を目指してゲームを進めていく。現在のところ,2013年第1四半期にリリース予定となっている。



関連トピック記事:

没有评论:

发表评论