オススメ機能
Twitter
お気に入り
記事履歴
ランキング
お気に入りタイトル/ワード

タイトル/ワード名(記事数)

最近記事を読んだタイトル/ワード

タイトル/ワード名(記事数)

LINEで4Gamerアカウントを登録
[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
特集記事一覧
注目のレビュー
注目のムービー

メディアパートナー

印刷2013/08/23 17:44

イベント

[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 いまや有力なゲームプラットフォームに成長したスマートフォン。ゲームデベロッパ各社は,スマートフォン上で動作するゲーム開発に取り組んでおり,CEDEC 2013でもそれをテーマにしたエンジニアリングセッションがいくつか組まれている。

左から,トライエース研究開発部の永野和博氏,大嶋貴史氏,デイビス・エリオット氏
画像(002)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
 最先端のスマートフォンは,家庭用ゲーム機に迫るグラフィックス性能を持っているが,その性能を引き出したゲーム開発には,いろいろと難しいところがあるようだ。「CEDEC 2013」の2日めとなる22日に開かれた「モバイルGPUでのハイエンドレンダリングエンジン開発事例」というセッションでは,スマートフォン向けグラフィックスエンジン開発のどこに困難があったのかが解説された。
 セッションを担当したのは,ゲームデベロッパであるトライエースの研究開発部に所属する,永野和博氏と大嶋貴史氏,デイビス・エリオット氏である。早速セッションの概要をレポートしよう。


AndroidスマートフォンのGPUは千差万別


トライエースのスマートフォン用グラフィックスエンジンは,iOS 5以上とAndroid 2.3以上に対応する
画像(003)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
 トライエースはPlayStation 3とXbox 360で動作する,自社開発のグラフィックスエンジンを持っている。大嶋氏によれば,「そのエンジンをスマートフォン上で動作するように」移植する作業を,3氏が担当したという。グラフィックスエンジン開発を進めていくなかで,彼らがどのような困難に直面し,それをどう解決していったのかが本セッションのテーマである。
 ちなみに,開発されたグラフィックスエンジンは,iOS 5.0以上とAndroid 2.3以上に対応しているとのことで,現在利用されているスマートフォンの大部分をカバーする汎用性の高いものだ。

 iOSとAndroidを比較して,グラフィックスエンジン開発が難しいのはどちらかといえば,4Gamer読者なら「それはAndroidのほうじゃないか」と想像が付くだろう。iOS端末はApple製のハードウェアしか存在せず種類も少ないが,Android端末は多数のメーカーが手がけており,スペックも性能も千差万別である。大嶋氏も,Android端末向けに開発することの難しさを真っ先に挙げていた。

 現在のスマートフォンで使われているモバイル端末用GPUは,QualcommのSoC(System-on-a-Chip)「Snapdragon」が搭載する「Adreno」シリーズや,NVIDIAのSoC「Tegra」シリーズといった,あらかじめSoCに搭載されているものと,英Imagination Technologyの「PowerVR」シリーズや,ARMの「Mali」シリーズのように,IPとしてSoCベンダーに提供されるGPUコアの2通りに分かれている。
 モバイルGPUは種類が多いだけでなく,世代に応じて実装している機能は違うし,当然性能も違っており,かなり混沌とした状況にあるのが現状だ。

トライエースがターゲットにしたスマートフォンに搭載されている主要なGPU。iOS端末は一貫してPowerVRシリーズが採用されており,バリエーションも4種類しかない。一方,Android端末ははるかに多い
画像(004)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 AndroidではGPUだけでなく,iOSに比べて開発環境にも問題になる点があるという。Android用アプリの開発環境である「Eclipse」は,一般的なAndroidアプリの開発に使う「Java」のデバッグなら問題ないのだが,性能を引き出すためにネイティブコードでプログラミングをすると,デバッグ機能の不十分な点が表面化する。

Android向け開発における,開発環境に起因するデバッグの困難さを説明。止まるはずのブレークポイントで止まらないというのは,かなりやっかいな問題だ
画像(005)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
 大嶋氏は,「ネイティブコードはブレークポイントで(プログラムの動作を)止められないことがある。そのため,『printf』※1でパラメータを出力しながらデバッグしたが,非常に困難な作業だった」という。
※1 画面に文字列を表示する命令のこと。

 C++言語を使って作られた家庭用ゲーム機用グラフィックスエンジンを移植するには,「JNI」(Java Native Interface)を使ったネイティブコードで開発することになるが,Androidの開発環境はそこが不十分というわけだ。

 市場に出回っているスマートフォンの性能差が大きいのも問題点だ。大嶋氏は,「ローエンドとハイエンド機の性能差は,軽く10〜15倍ほどもある」という。
 さて,性能差があるプラットフォームでは,性能が低い方に合わせてゲームを制作するのがセオリーだが,それでは高性能な端末の能力を引き出せず,グラフィックスの品質を高めるのは難しい。そこでトライエースでは,「可能な限り(高性能な)端末の最大性能を引き出して,良い映像を実現すべき」(大嶋氏)という方針の元に,高性能端末の能力を引き出す方向で開発に取り組んだという。

 近い将来,さらに高性能なスマートフォンが登場することは明らかであり,グラフィックスエンジンは高い性能を持つハードを生かしたグラフィックスを表現できるように,開発する必要があると大嶋氏は述べる。そこで重要になるのは,「グラフィックスエンジンのスケーラビリティ」(大嶋氏)を確保することである。
 トライエースのグラフィックスエンジンでは,端末の性能に合わせて自動的に照明の数を増減したり,ポストプロセスの設定を変えるといった方法で負荷を調節して,端末の性能に最適な動作をするように設計されたそうだ。

画像(006)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
トライエースでは低い性能に合わせる方法は選ばず,高性能スマートフォンの性能を引き出せるグラフィックスエンジンの実装を目指した
画像(007)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
トライエースのグラフィックスエンジンが採用した,スケーラビリティを実現する手法の例。PCゲームでも似たような手法が使われている


予想以上に困難だったAndroidへの移植


 こうした方針を立てて,グラフィックスエンジンの移植に取りかかった大嶋氏らは,まず開発環境が整っていて,端末ごとの差異も少ないiOSに移植したうえで,それをさらにAndroidへと移植するという手順で開発を進めたそうだ。

iOSからAndroidへの移植で必要になった変更点をまとめたスライド。右はトライエースのグラフィックスエンジンのフローで,メイン,ワーカー,レンダーという3つのスレッドで構成されている
画像(008)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 iOSとAndroidのどちらも,3DグラフィックスAPIには「OpenGL ES 2.0」を採用しているので,「iOSからAndroidへの移植は簡単だろうと当初は考えていた」(大嶋氏)そうだが,楽観的な予想は覆されて,次々と困難に直面したそうだ。

Android 4.0以前は垂直同期のタイミングが取得できないという問題があるのに加えて,機種ごとにリフレッシュレートが異なっていた
画像(009)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
 たとえば,Android端末ではリフレッシュレートが機種によって異なるうえに,OSから得たリフレッシュレートと実際のリフレッシュレートが違うという,驚くべき事実が分かったという。
 トライエースのグラフィックスエンジンは,画面の更新を垂直同期にあわせて行う仕様なので,正しいリフレッシュレートが分からないのは,頭の痛い問題だったようだ。

機種別のリフレッシュレートを調べた結果。問い合わせた値と実測値が多少だがずれている
画像(010)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

AndroidではOpenGLコンテキストが1つしか使えない機種があったため,グラフィックスエンジンの設計を変える必要があった。スライドで水色の部分が,本来はコンテキストが必要なスレッドで,Androidではレンダーとシェーダコンパイルを1つのスレッドにまとめている
画像(011)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
 マルチスレッドでのレンダリングについても,「OpenGLコンテキストが,1つしか使えない機種があった」(エリオット氏)ため,Android端末では困難にぶつかったという。
 OpenGLでは,コンテキストのハンドル(識別符号)を得てレンダリングを制御する。そのため,レンダリングをマルチスレッドで行う場合,各スレッドがこの識別符号を得る必要がある。だが,OpenGLコンテキストが1つしか使えない端末では,レンダリングを複数のスレッドに分けるのは困難だ。
 そこでAndroidでは,OpenGLコンテキストが必要になる「シェーダのコンパイル」を,レンダースレッドに移すといった設計変更を実施したという。

 レンダースレッドを使う場合と使わない場合の性能を計測した結果を,エリオット氏が披露していたが,これがなかなか興味深い。
 シングルコアCPUでは,スレッドの切り替えがオーバーヘッドになるため,レンダースレッドを使うと性能はむしろ低下するはずだ。ところがグラフを見ると,シングルコアCPUを搭載する「Xperia acro SO-02C」で,「レンダースレッド有り」のほうがなぜか性能が高いのだ。

エリオット氏が披露した,スマートフォン4機種でレンダースレッドの効果を測定したグラフ。シングルコアCPUのXperia acro SO-02Cは,なぜかレンダースレッド有りのほうが好成績だった
画像(012)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 エリオット氏はその理由として,「OpenGL ES 2.0のAPI内では,スレッドを明示的に“ウェイト”状態にしているため,そのCPU時間が使えているからではないか」との推測を披露した。この推測を元に考えると,API内部でスレッドをウェイトにして,CPU時間を他のスレッドに与えると性能が向上するということは,「OpenGL ES 2.0のオーバーヘッドが(iOSに比べて)大きいということ」(エリオット氏)にもなるわけだ。

 そのほかにもAndroid端末では,配列を持った構造体をuniform変数で扱う場合,配列のサイズを取得すると機種によって結果が異なるという問題や,フロントバッファをスワップさせたときに,カラーバッファの内容が保持される/されないといった動作が,GPUによって異なるといった問題点があったという。


ポリゴンの描画順を変えるだけで,GPUによっては性能が変わる


 永野氏からは,GPU別の最適化についてが解説された。その中でも,オブジェクトの描画順によって,見えないものを描画しないように描画対象から外す処理である「Early Z Culling」が,どう機能するかをGPU別に調べたという話題は興味深かった。

 約30fpsで描画できるように調節したシェーダを使い,まず不透明のオブジェクトを手前側(カメラ側)から描いた場合と,奥から描いた場合のフレームレートを比較したのが次のグラフだ。

30fpsを基準値として,不透明のオブジェクトを1ポリゴンのみ描画した場合と,手前から6ポリゴン描画した場合,奥から6ポリゴン描画した場合のフレームレート比較
画像(013)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 手前側からポリゴンを重ねて描くと,見えないポリゴンは描画されないのでフレームレートに悪影響はないが,逆に奥側から描くと,最終的に見えないポリゴンも描かなくてはならないので(オーバードローと呼ぶ),フレームレートは下がる。AdrenoやMali,Tegraの結果はそれを反映しているが,PowerVRだけは,奥から描いてもフレームレートが下がっていない。これは「描画順に関わらず,不透明描画時にオーバードローが発生しないというPowerVRの特性」(永野氏)によるものだという。

 2つめのグラフは,板に穴を開けたような“パンチスルー”オブジェクトを使った同様のテスト結果だ。「パンチスルーのシェーダは,不透明オブジェクトのシェーダにdiscard命令を追加したもの」(永野氏)を使用したという。discard命令とは,任意のピクセルを描かないようにする命令である。今回は穴の部分でこれを使うことで,パンチスルーオブジェクトを表現したわけだ。
 さてその結果であるが,パンチスルーオブジェクトではどのGPUでも,描画順に関係なくオーバードローが発生して,フレームレートが低下している。

パンチスルーオブジェクトを描画し,描画順によってオーバードローが発生するかどうかを調べた結果のグラフ。すべてのGPUで,描画順に関係なくオーバードローが発生し,フレームレートが低下した
画像(014)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 とはいえ永野氏によれば,「PowerVRでは,すべてのケースでオーバードローが発生するわけではない。軽いシェーダなら発生しない場合もある」とのこと。なお,PowerVRは1ポリゴンのみの描画でも,わずかにフレームレートが低下しているが,これについて永野氏は,「PowerVRに特有な,discard命令のオーバーヘッドによるもの」と説明していた。

 最後には,不透明オブジェクトとパンチスルーオブジェクトを交互に描いた場合の結果が示されたが,これはGPUによって結果が大きく異なっていた。

 まず奥から描く場合は,すべてのGPUでオーバードローが発生する。これは先の結果と同じで納得がいく。しかし,手前から「不透明,パンチスルー,不透明」という順で描くと,なぜかAdrenoとTegraでオーバードローが発生している。
 さらに,手前から「パンチスルー,不透明,パンチスルー」という逆の順序で描くと,Maliでもオーバードローが発生。PowerVR以外のGPUでは,オーバードローが避けられないという結果となった。

不透明とパンチスルーを交互に描いた結果のグラフ。手前から描いた場合はGPUによって大きく異なった
画像(015)[CEDEC 2013]性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関

 オブジェクトの描画順によって,GPUごとにここまで大きな性能差が出るというのは興味深い。逆に言えば,GPUごとに描画順を変えるだけでも,GPUの性能を引き出せる可能性があるともいえるだろう。

 さて,このセッションでは,Androidへグラフィックスエンジンを移植するときの難しさが語られたわけだが,各GPUや機種による興味深い差異が紹介され,参考になった。移植は困難を極めただろうが,こうした問題を突きとめて解決したことで,今後より高性能なモバイルGPUを搭載するAndroid端末が登場してきた時に対応できる柔軟さを,トライエースのグラフィックスエンジンは獲得したのではないだろうか。こういった取り組みがより広く,ノウハウとして広まっていくことにも期待しておきたい。

CEDEC 2013 公式Webサイト

  • この記事のURL:
4Gamer.net最新情報
プラットフォーム別新着記事
総合新着記事
企画記事
トピックス
スペシャルコンテンツ
注目記事ランキング
集計:10月19日〜10月20日
タイトル評価ランキング
93
72
原神 (PC)
68
58
VALORANT (PC)
50
LOST ARK (PC)
2020年04月〜2020年10月