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

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

左から，トライエース研究開発部の永野和博氏，大嶋貴史氏，デイビス・エリオット氏

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

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

トライエースのスマートフォン用グラフィックスエンジンは，iOS 5以上とAndroid 2.3以上に対応する

　トライエースは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端末ははるかに多い

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

Android向け開発における，開発環境に起因するデバッグの困難さを説明。止まるはずのブレークポイントで止まらないというのは，かなりやっかいな問題だ

　大嶋氏は，「ネイティブコードはブレークポイントで（プログラムの動作を）止められないことがある。そのため，『printf』^※1でパラメータを出力しながらデバッグしたが，非常に困難な作業だった」という。
^{※1 画面に文字列を表示する命令のこと。}

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

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

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

トライエースでは低い性能に合わせる方法は選ばず，高性能スマートフォンの性能を引き出せるグラフィックスエンジンの実装を目指した

トライエースのグラフィックスエンジンが採用した，スケーラビリティを実現する手法の例。PCゲームでも似たような手法が使われている

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

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

iOSからAndroidへの移植で必要になった変更点をまとめたスライド。右はトライエースのグラフィックスエンジンのフローで，メイン，ワーカー，レンダーという3つのスレッドで構成されている

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

Android 4.0以前は垂直同期のタイミングが取得できないという問題があるのに加えて，機種ごとにリフレッシュレートが異なっていた

　たとえば，Android端末ではリフレッシュレートが機種によって異なるうえに，OSから得たリフレッシュレートと実際のリフレッシュレートが違うという，驚くべき事実が分かったという。
　トライエースのグラフィックスエンジンは，画面の更新を垂直同期にあわせて行う仕様なので，正しいリフレッシュレートが分からないのは，頭の痛い問題だったようだ。

機種別のリフレッシュレートを調べた結果。問い合わせた値と実測値が多少だがずれている

AndroidではOpenGLコンテキストが1つしか使えない機種があったため，グラフィックスエンジンの設計を変える必要があった。スライドで水色の部分が，本来はコンテキストが必要なスレッドで，Androidではレンダーとシェーダコンパイルを1つのスレッドにまとめている

　マルチスレッドでのレンダリングについても，「OpenGLコンテキストが，1つしか使えない機種があった」（エリオット氏）ため，Android端末では困難にぶつかったという。
　OpenGLでは，コンテキストのハンドル（識別符号）を得てレンダリングを制御する。そのため，レンダリングをマルチスレッドで行う場合，各スレッドがこの識別符号を得る必要がある。だが，OpenGLコンテキストが1つしか使えない端末では，レンダリングを複数のスレッドに分けるのは困難だ。
　そこでAndroidでは，OpenGLコンテキストが必要になる「シェーダのコンパイル」を，レンダースレッドに移すといった設計変更を実施したという。

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

エリオット氏が披露した，スマートフォン4機種でレンダースレッドの効果を測定したグラフ。シングルコアCPUのXperia acro SO-02Cは，なぜかレンダースレッド有りのほうが好成績だった

　エリオット氏はその理由として，「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ポリゴン描画した場合のフレームレート比較

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

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

パンチスルーオブジェクトを描画し，描画順によってオーバードローが発生するかどうかを調べた結果のグラフ。すべてのGPUで，描画順に関係なくオーバードローが発生し，フレームレートが低下した

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

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

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

不透明とパンチスルーを交互に描いた結果のグラフ。手前から描いた場合はGPUによって大きく異なった

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

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

CEDEC 2013 公式Webサイト