ニュース
スマホでPS4世代のグラフィックスを実現? OpenGL ES 3.1の拡張機能「Google AEP」や次世代OpenGLの話をKhronos Group代表に聞いてみた
OpenGL 4.5の新機能とは?
「Direct State Access」(DSA)は,テクスチャなどを含む各種バッファオブシェクトをバインド手続きなしに直接読み書きができるようにする機能だ。
「Flush Control」は,コマンドを「クリア」(Flush)するときの振る舞いを,コンテクストスイッチ時に制御するものだ。
「Robustness」は,GPU上で動作中のアプリケーションがクラッシュしても,同時に実行されている別のアプリケーションを巻き込んでクラッシュしないようにするための技術である。Trevett氏によれば,これを利用することで「WebGL」を使うWebアプリケーションと,それを実行するWebブラウザの安定性を向上させられるとのことだ。
「DirectX 11 Emulation Features」は名前からも想像できるように,OpenGLとDirectXで細かい仕様が異なる部分を吸収する拡張機能のこと。DirectXベースのアプリケーションをOpenGLベースに移植する手間を低減するために実装されたという。
最後の「OpenGL ES 3.1 API and Shader Compatibility」は,OpenGL 4.5環境下でOpenGL ES 3.1ベースのアプリケーションを開発したり,実行したりできるようにするための仕組みである。OpenGL 4.3以降,OpenGLはOpenGL ES 3.0との親和性を高める方向に進んでいるが,OpenGL 4.5でも,OpenGL ESの最新版であるOpenGL ES 3.1に対応すべく導入されたのだと,Trevett氏は説明した。
OpenGL ES 3.1に,次世代Android向けの独自拡張仕様「Google AEP」が発表に
2014年6月にGoogleが次期Android OS「Android L」を発表したときに(関連記事),OpenGL ES 3.1が同OSに採用されることも発表された。ところが,高性能な組み込み機器向けGPUを提供している企業からは,「同世代のOpenGLに対して,OpenGL ES 3.1でサポートされる機能は低レベルすぎる」という意見が,Googleに対して寄せられたのだという。
そこでGoogleは,次期OpenGL ESの機能を先取りする,あるいはOpenGL 4.xの機能を取り込む形で,独自の拡張機能セットを定義した。それが「Google Android Extension Pack」(以下,Google AEP)だ。
Google AEPに含まれる主な機能は,「ジオメトリシェーダ」「テッセレーションステージ」「ASTCテクスチャ圧縮」の3点となる。
ARMやImagination Technologies,QualcommにNVIDIAといったGPUメーカーが発表済みの最新世代GPUは,すでにこれらの機能をサポート済みであるどころか,OpenGL 4.xに対応できるだけのスペックを備えているのが現状だ。ところが,OpenGL ES 3.1ではこれらの機能が利用できないため,せっかくの機能が宝の持ち腐れとなってしまう。そこで,Google AEPでこれらを利用できるようにしたというわけだ。
アプリケーションがAndroid L環境下でGoogle AEPを利用する場合,OpenGL ES 3.1に対して「使えるかどうか」の問い合わせを事前に一度行い,「使える」という結果が返ってきたら利用するという取り決めになっている。つまり,Android L世代ではロー〜ミドルクラスの「OpenGL ES 3.1環境」とハイエンドの「Google AEP対応環境」という2種類の端末が存在しうるともいえるだろう。
ゲーム開発者にとっては手間が増える話かもしれないが,Google AEP環境下では,DirectX 11世代GPUの機能をフルに活用したゲームグラフィックスを扱えるようになるのだから軽視はできない。大げさにいえば,OpenGL 4.xベースで作られるPlayStation 4(以下,
Google AEPへの対応に積極的なのがNVIDIAで,いち早く対応を表明しただけでなく,Kepler世代GPUを統合したSoC(System-on-a-Chip)「Tegra K1」で,
今回,Trevett氏はNVIDIA製タブレット端末「SHIELD Tablet」の実機で,UE4のデモを見せてくれた。SHIELD Tablet上で動いている様子を動画で撮影したので,Google I/O 2014で披露されたデモ動画と合わせて見てほしい。
残念ながら,ブースではこのデモに関する詳しい説明がなく,説明員は「OpenGL ES 3.1と,ARM独自拡張機能によって実現している」と話しただけだった。このデモがGoogle AEPを使っていたのかどうかはともかく,Qualcomm製SoCでもGoogle AEP対応に向けた準備が進められている,と見て間違いはないだろう。
Mantle/DirectX 12風の次世代OpenGL開発プロジェクトがスタート
OpenGLやOpenGL ES以外にも,Khronos Groupが策定を進めるオープンスタンダードAPIはある。これらの動向と将来のプロジェクトを簡単にまとめてみたい。
まず,Webブラウザ上で3Dグラフィックスを利用する「WebGL」は,採用の動きが加速している。とくに,これまではWebGLに消極的だったMicrosoftとAppleが重い腰を上げて採用に動いたのが大きい。Internet Explorerは最新の「Internet Explorer 11」でWebGLに標準対応したし,AppleのWebブラウザ「Safari」もまた,次期バージョンの「Safari 8」でWebGLに標準対応する予定とされている(※現バージョンでも対応しているが,標準ではオフ)。
さらに,Microsoftも2014年になって,Khronos Groupへの加入を表明したそうだ。Trevett氏曰く,Khronos Groupとしては「2014年最大のニュース」だという。
WebGLに対応するWebブラウザを示したスライド。緑色が標準対応するもので,主要Webブラウザはすべてが対応する予定。Firefoxも対応済みだが,標準ではオフになっている |
Khronos Groupへの参加企業を列挙したスライドだが,ここにMicrosoftの名前が加わった。黄色いトゲトゲでロゴマークを囲んで歓迎の意を示している |
さて,Khronos Groupが規格化するもう1つの代表的APIである「OpenCL」にも,新しい動きが見られる。2014年1月にKhronos Groupは,OpenCL 1.xを特定ハードウェアに依存しない中間言語(Intermediate Representation)で表現する規格「SPIR」(Standard Portable Intermediate Representation)を発表済みだ。このSPIRをOpenCL 2.0に対応させた「SPIR 2.0」の暫定仕様が,SIGGRAPH 2014会期中に発表されている。
GPGPUに代表されるデータ並列コンピューティングでは,GPUメーカーのハードウェアアーキテクチャに応じて,コンパイラのバックエンドを実装しなければならない。SPIRは,そうしたアーキテクチャの違いを隠蔽する中間言語表現規格に相当するもので,GPUメーカーはそれぞれのハードウェア上で,SPIR形式のバイナリが動作するドライバソフトを制作するだけで,OpenCLアプリケーションを動作させやすく,あるいは移植しやすくできるのだ。
たとえば「OpenACC」,「C++ AMP」,「Python」を使ってデータ並列演算プログラムを作る開発者なら,SPIR形式のバイナリを生成するようにプログラムを実装することで,SPIR型式に対応したGPU上でアプリケーションを動作させられるのである。
ちなみに,現在のSPIR 1.2はOpenCLの仮想マシンである「LLVM」規格の「LLVM 3.2」ベースだが,SPIR 2.0ではより新しい「LLVM 3.4」をベースにしたものになるとTrevett氏は説明した。
OpenCLのエコシステムを示したスライド。SPIRの存在が急拡大しているという |
SPIRの新バージョンであるSPIR 2.0の暫定仕様がSIGGRAPH 2014に合わせて公開された |
この次世代OpenGLが,「OpenGL 5.X」になるのか,それともOpenGL ESのような別のシリーズになるのかは,現在も議論が続いているとのことだが,22年にわたって拡張と増築を繰り返してきたOpenGLと決別しようという動きが出てきたというのだ。
基本となる開発コンセプトは,マルチコアCPUやメニーコアGPUといった近代的なプロセッサアーキテクチャとの親和性に優れた,モダンなデザインのAPIに刷新すること,マルチスレッドおよびマルチコアの優位性を積極的に活用した構造として,シンプルでオーバーヘッドの少ないAPI設計にすることが掲げられている。
とくに,現在のOpenGLのような,アプリケーションからは見えない,GPUドライバ側が行っている「黒魔術的な不透明な部分」(Trevett氏)を極力排除することで,アプリケーションから見て透明で,かつパフォーマンスや実行結果を予測しやすい機能デザインを心がけるとTrevett氏は述べている。
このアプローチは,AMDの「Mantle」や,Microsoftの「DirectX 12」のコンセプトと合致する。MantleやDirectX 12が目指している「ハードウェアに近いダイレクトなAPI」を,OpenGLでも実現しようとしていると言っても過言ではあるまい。
ただし,オープンスタンダードAPIを手がけるKhronos Groupが規格化する以上,特定メーカーの都合に合わせた設計をするわけにもいかないので,「中立的な立ち位置」を意識した設計になる。
たとえば,さまざまなコマンド表現やシェーダ言語は,中間言語(Intermediate Representation,IR)で抽象化することが必須となるだろう。「そうした部分の仕様は,OpenCLにおけるSPIRのようなものになるだろう」とTrevett氏は述べていた。
またTrevett氏は,現在は別々の存在であるOpenGLとOpenGL ESの統合も,外せない課題だとしている。両者を統合したうえで,既存のOpenGLとの互換性にも極力配慮したものを次世代OpenGLでは目指しているということのようだ。
Trevett氏によると,現在は開発プロジェクトへの参加を募っているところとのこと。現時点ではプロセッサメーカーやソフトウェアメーカー,ゲームスタジオなどを含む20社以上が名乗りを上げているという。かつてのOpenGLは,プロセッサメーカーとOSメーカーだけで決められていたものだが,次世代OpenGL開発プロジェクトではゲームスタジオやゲームエンジンメーカーが初期段階から名を連ねているのが興味深いし,なんとも今風でモダンであるといえる。
次世代OpenGLのロードマップは示されていないのだが,競合となるMantleはすでにリリース済みで,DirectX 12は2015年登場予定であることを考えると,筆者の勝手な予想では,暫定仕様が早ければ2015年,遅くとも2016年には固まるのではないだろうか。筆者の予想が当たるかどうかはともかく,次世代OpenGLがどのようなものになるのか,今後の展開が楽しみである。
Khronos Group公式Webサイト(英語)
SIGGRAPH 2014 公式Webサイト
- 関連タイトル:
OpenGL
- この記事のURL: