［GDC 2014］ゲーム開発者の取り込みを狙うIntel，統合型グラフィックス機能の性能を引き出す最適化セッションを実施

　北米時間3月17日から21日まで開かれたGame Developers Conference 2014（以下，GDC 2014）で，Intelは，ゲーム開発者や報道関係者に向けて積極的なアピールを行った。そのうち，デスクトップPCやAndroid端末，そして3Dカメラを活用したナチュラルUI「Intel RealSense Technology」の話題は，それぞれレポートを掲載済みだ。
　今回は，IntelがGDC 2014で実施したスポンサーセッションの中から，ここまで取り上げていない「ゲーム開発と関わりの深いグラフィックス関連のセッション」を3つ紹介し，そこでIntelが何を訴えていたのかをレポートしたい。

統合型グラフィックスで性能を引き出す最適化手法

　現在，Intel CPUの統合型グラフィックス機能（以下，iGPU）といえば，上はデスクトップPC向けの「Core i7-4700」シリーズから，下はタブレット向けの「Atom Z3000」シリーズ（開発コードネーム Bay Trail）までの幅広い製品で，「Intel HD Graphics」や「Intel Iris Graphics」と呼ばれる，同社独自のアーキテクチャを使用している。

　IntelもiGPUの性能向上に取り組んではいるが，現在最上位のiGPUである「Iris Pro Graphics 5200」（以下，Iris Pro 5200）であっても，単体GPUのエントリークラスと比べるのがせいぜいで，少なくとも，ミドルクラス以上のGPUと戦えるほどの性能はない。

Blake Taylor氏（Graphics Software Development and Validation，Intel）

　だがそれゆえに，IntelにとってiGPU向けにゲームグラフィックスを最適化してもらうのは非常に重要である。GDC 2014におけるグラフィックス関連セッションの1つめは，そんなiGPU向けの最適化テクニックを解説するセッションだ。タイトルは「Achieving the Best Performance with IA Graphics Tips，Tricks，and Clever Bits」（IA Graphicsで最高のパフォーマンスを達成するためのTips，トリック，そしてクレバーな小ネタ）。講演を行ったのは，Intelにてグラフィックスソフトウェアの開発や評価を担当するBlake Taylor氏である。

　氏のセッションはかなりハイレベルで，iGPU向けにゲームグラフィックスを最適化するにあたって役立つ重要なヒントが数多く披露された。とくに，iGPUの構造と性能の特徴が分かりやすく解説されたので，今回はその部分に絞って紹介してみよう。

　まず，Taylor氏が性能改善のポイントとして挙げたのは，メモリアクセスの最適化だ。iGPUに限った話ではないが，グラフィックス性能を引き出すには，グラフィックスメモリへのアクセスをいかに削減するか，あるいは効率を上げるかが重要になる。メモリアクセスは性能面のペナルティが極めて大きいからである。
　メモリアクセスの効率を上げるために頭に入れておくべきなのが，GPUのメモリ階層構造だ。下に掲載したスライドは，iGPUのメモリ階層を概念的に表したもので，iGPUから見たメインメモリはLast Level Cache（以下，LLC）よりも遠い階層にある。

Intel製iGPUのメモリ階層を示した概念図。詳細は直後で述べるが，「eDRAM」がLLCと同じ階層に置かれている点は押さえておいてほしい

　この図で注目すべきは，GPUのメモリインタフェースと「eDRAM」（embedded DRAM，組み込みDRAM）をつなぐ矢印がある点である。これはIris Pro 5200だけが備えるオンチップの高速DRAMだが，メモリ容量や細かい仕様について，Intelは依然として，学会以外の場では情報を明らかにしていない。
　しかし，この図からすると，iGPUのメモリインタフェースとeDRAMを，ダイレクトに結ぶ経路があることになる。Intelは以前にこのeDRAMを，「LLCの外にあるキャッシュのようなもの」と説明していたが，この図のとおりならそうではなく，実際にはLLCと“同じ”階層にあるGPU用のバッファとでもいうべきものだろう。

　ところで筆者は，このセッションでeDRAMに関する仕様が明らかになったりしないものかと期待していたのだが，Taylor氏も「Iris Pro Graphics 5200にはeDRAMがある」と述べただけで，仕様の詳細に踏み込んだりはしなかった。eDRAMの動作はアプリケーション側から制御できるものではないので，「（開発者は）あることだけ知ってればいい」というスタンスのようである。

　iGPUの内部アーキテクチャに関する解説もあった。iGPUの内部は，「Slice」（スライス）と呼ばれる単位で構成されており，Slice単位で拡張が可能な設計となっている。1基のSliceは，2基の「Sub Slice」と1基の「Common Slice」を束ねたものだ。Sub Sliceは，Intelが「Execution Unit」（EU）と呼ぶ演算器のことで，一方のCommon Sliceは，ラスタライズの機能とSub Sliceに対する命令のディスパッチ（シェーダコードの実行）を行う機能を持つユニットである。
　構造面では大違いなので，いささか無理のある喩えになるが，Sub Sliceは，NVIDIAの「Kepler」コアでいう「SMX」（Streaming Multiprocessor eXtreme）で，Sliceは同じく「GPC」（Graphics Processing Cluster）に相当する……といったところだろうか。

iGPUの内部アーキテクチャを概念的に示したスライド。Sliceの中には，2基のSub SliceとCommon Sliceがある

　上のスライドではSliceの外側に「Fixed Function」というブロックも見える。これもIntel製iGPUが持つ特徴の1つで，ジオメトリ処理専用の固定機能を搭載するものだ。Fixed Functionをうまく利用すると，ジオメトリ処理の性能を上げられると，Taylor氏は解説していた。

　さて，次に示したスライドは，シェーダ演算におけるデータの流れと，演算に使うSub Sliceの数，得られる性能の相関を示したものだ。iGPUのアーキテクチャでは，演算に使うSub Sliceが増えれば，性能はほぼリニアに上がっていくので，うまくSub Sliceを並列動作させることが重要となってくる。

演算におけるデータの流れ（スライド右）と，Sub Sliceの数に対する演算性能の関係を示したグラフ（スライド左下）

　シェーダの演算で使用する命令にもスループット――たいていは実行に要するクロック数と同義――の違いがあるため，「その違いを頭に入れてシェーダコードを最適化することで，最大の性能が得られる」と，Taylor氏は主張している。
　下に掲載したスライドがそれを示すもので，右上にあるグラフは，「SIMD8」と「SIMD16」での演算性能を比較したものだ。これを見ると，ベクタ長が短いSIMD8のほうが高速というわけではなく，SIMD16よりも性能が落ちてしまうらしい。少なくともIntelのiGPUで，SIMD8を使うメリットはあまりないように読める。
　右下の棒グラフも興味深い。こちらはEUが処理する演算命令による性能の違いを示したものだ。「1」が最大性能なので，命令によっては極端に遅いことが分かる。逆にいえば，iGPUの性能を発揮させるには，こうした命令はなるべく減らすほうがいいということが見えてくるわけだ。

iGPUで演算性能を示したグラフ。右上はSIMD8とSIMD16の比較で，右下は命令別の処理性能を比較したものだ

　Taylor氏のセッションではほかにも，演算に使うSub Slice数とフィルレートの関係なども検証していた。IntelのiGPUでも快適に動くゲームを作りたいという開発者にとっては，なかなか参考になる情報が多いので，興味のある人は，IntelのGDC特設ページにあるPDFを参照してほしい。

x86 CPU搭載Android端末向けにゲームを移植するときの実践的テクニック

　3月22日掲載の記事でも報じたが，IntelはBay Trail-T搭載Android端末でのOpenGL ES 3.1サポートを発表している。IntelはOpenGL ES 3.1を使うことで，Bay Trail-T搭載Android端末にPCゲームを移植しやすくなると述べているのだが，その実例を示したセッションも2つ開かれた。

Alex Aptekar氏（Electronic Arts）

　1つめは「SSX: Bringing a PS3 game to Android」（PS3用ゲーム「SSX」をAndroidに移植する）だ。Electronic ArtsのAlex Aptekar氏が，スノーボードゲーム「SSX」をx86版CPU搭載Androidタブレット向けに移植したときの事情を語り，Aptekar氏らのチームを支援したIntelのOmar A Rodriguez氏が，その最適化テクニックを解説するという内容だった。

　Aptekar氏によると，まずシェーダプログラムなどは内製だったので，大きな問題もなく移植できたそうだ。努力を要したのは，各種のデータやアセット（※ここでは素材の意）などをシェイプアップして，メモリ消費量やCPU負荷を抑えるほうだったという。
　ちなみに，筆者がAptekar氏の話で驚いたのは，SSXで使ったスクリプト言語の「Lua」が，「Andoroidでは重すぎたため，C＋＋に書き直した」（Aptekar氏）というくだりである。PCにおいては，Luaは軽量なスクリプト言語として知られているのだが，Android端末に使うSoCの処理能力ではそれすら重いということだろうか。単に少しでも実行速度を稼ぐため，というだけの理由かもしれないが。

オリジナルのアセット（上）を，Android向けにシェイプアップした例（下）。見た目をさほど損なうことなく軽量化できたそうだ

　一方，移植に協力したIntelでは，iGPUの活用によるパーティクルの表現を追加したほか，地形のデータをソートして高速化を図るために，性能チューニングツール「Intel Graphics Performance Analyzer」（以下，GPA）を活用したと説明していた。Aptekar氏が「SSXはGPAのいいストレステストになりましたね」と述べて，来場者の笑いを誘う一幕もあったりした。

Steve Hughes氏（Gameloft）

　もう1つの移植に関するセッションは「Adding high-end graphical effects to GT Racing 2 on Android x86」（GT2 Racing 2のx86版Androidにハイエンドグラフィックスのエフェクトを追加する）というものだ。セッションの内容はタイトルどおりで，IntelのiGPU用にエフェクトを追加するためのテクニックが説明された。
　セッションを担当したのは，Gameloftで「GT Racing 2: The Real Car Experience」（以下，GTR2）の開発に携わったSteve Hughes氏である。

　x86 CPU搭載のAndroidタブレットでGTR2を動かすと，「Depth of Field」（被写界深度の表現），「Heat Haze」（陽炎の表現），そして「Lightshafts」（光が雲間から差し込む表現）といった3種類の表現が，ゲームグラフィックスに追加されるという。
　下に，Depth of Fieldのありなしでの違いを示したスクリーンショットを掲載しておこう。左がx86でないプロセッサ――要するにARMベースのSoC――を搭載するAndroidタブレットによる描画で，Depth of Fieldがないために，背景までくっきり描かれている。一方，右はx86版CPUが搭載されたAndroidタブレットによる描画で，Depth of Fieldが有効な状態であるため，背景がちょっとわざとらしいくらいにぼやけているのが分かる。

左が非x86 CPU搭載Androidタブレット，右がx86版CPU搭載Androidタブレットによる画面。Depth of Fieldの有無がはっきりと分かる

　Heat HazeやLightshaftsも，概念の説明図やサンプルコードを使って，それぞれの表現をx86 CPUでどう実現したのかや，その表現にどれくらい描画時間を必要とするかといった，実践的な情報がHughes氏により解説された。
　個々の内容は専門的すぎるので割愛するが，実際にx86版CPUへ向けた最適化を考えている人には役に立つ情報が豊富に含まれている印象だ。こちらのスライドもIntelのGDC特設ページに掲載されているので，興味のある人は見てほしい。

上のスライドがHeat Haze，下はLightshaftsの効果を示したスライドで，どちらも，左がARMベース，右がIntelベースのCPUで描画したものだ

　優れた性能を持つBay Trail-TでAndroid端末の市場に攻め込むために，Intelはゲーム開発者への働きかけを非常に強めている。それが実感されたGDC 2014ではあったが，実のところ，これらセッションはどれも人の入りが今ひとつで，ゲーム開発者側の注目を集めていたとは言い難い。Intelは今後も，ゲーム開発者に対する継続的なアピールを続けていく必要があるようだ。

Intel＠GDC 2014（英語）