Androidゲーム向けに自動化されたパフォーマンスアドバイス

制作 : Arm株式会社

モバイルゲームは急速に高度化しており、最新スマートフォンのパフォーマンス性能を活用した忠実度の高い3Dゲームの数は増え続けています。コンテンツが複雑になるにつれて、手作業でプレイテストをしてパフォーマンスを確認するという従来の手法は、リスクがますます高まっています。この傾向は特に、開発プロセスが進めば進むほど顕著に現れます。

多様なデバイスに対応するタイトルをリリースする制作スタジオは、できるだけ多くのプレイヤーベースに到達することが求められますが、パフォーマンスプロファイルを追加すればするほど、手作業でテストを行うときのコストは増える一方です。このプロセスをより簡単にするために、継続的インテグレーション開発プロセスの一環として デバイスでのパフォーマンス分析を自動化する新しいツールをリリースします。このツールにより、読みやすいパフォーマンスレポートと、ダッシュボードとの融和性が高いJSONエクスポートが提供されるため、データを細かく分析することができます。

CIをお勧めする理由

ソフトウェア開発において継続的インテグレーションを行う主な目的は、開発チームが高品質の製品を生み出せるようにすることです。開発者がアプリケーションを変更するたびに機能テストとパフォーマンステストが自動で実行されれば、開発者は自分の作業に関するフィードバックを適宜得ることができます。即座に行われるフィードバックが、問題の解決も迅速にします。その変更がメインの製品コードラインへコミットされる前であっても、バグが及ぼす影響とそれを修正するためのコストが軽減されることが理想的です。

同じ原則はゲーム開発にも当てはまりますが、大きな違いが1つあります。大半のゲーム制作スタジオでは、コーダーの人数よりもユーザーインタフェース、キャラクター、ゲーム環境を生み出すクリエイティブチームの人数の方が多いことです。アーティストには、中核をなすレンダリング技術を構築する開発者と同じくらいの深い技術知識はない場合がありますが、アーティストが作成するアートアセットは、ゲームの成功に大きく影響する可能性があります。ゲームチームに十分に力を発揮してもらうには、自動化ツールフローによって、チームメンバー全員が理解できるフィードバックを提供することが必要不可欠です。

Performance Advisorの導入

Performance Advisorは、 Arm Mobile Studioの一部としてリリースされたものですが、Arm CPUとMali GPUを備えたプラットフォームから収集できる豊富な技術パフォーマンスデータに基づいて、読みやすいパフォーマンスレポートを生成できる新しいツールです。このレポートの目的は、「ヘルスチェック」
「自分のゲームはパフォーマンス目標に達しているだろうか?」
…と「トリアージナース」
「どこを改善できるだろうか?」
…の両方の役割を果たすことであり、全体的な目的は、最適化のエキスパートでない人がレポートを読んでも理解できるようにすることです。

Performance Advisorのレポートは、当社のStreamlineプロファイラーが提供するより高度なデータ視覚化を補足するためにデザインされています。Streamlineは問題を深掘りするためのすばらしいツールですが、ステータスチェックを手早く行うだけのときには、情報過多かもしれません。Performance Advisorは、Streamlineと同じハードウェア・パフォーマンス・カウンター・データと、軽量APIインターセプターまたはアプリケーション自体によって生成される注釈データとを組み合わせて取り込みます。また、調査対象となる問題が起こりそうなエリアについての初回ガイダンスと、最適化アプローチについてのアドバイスを備える読みやすい概要を生成します。

状況によっては、一式揃ったStreamlineまたはGraphics Analyzerツール群を使って、特定された問題についてさらに詳しく調べなければならないこともあります。しかし、少なくともPerformance Advisorを使えば、詳しい調査が必要かどうかと、どこから調べればよいのかが簡単に分かります。

ヘルスチェック

モニタリングワークフローの最初の項目は、定期的なヘルスチェックです。開発中に問題が起きることはほとんどないため、すべての作業が順調に進んでいるかどうかのチェックに毎日数分以上をかけたくはありません。Performance Advisorレポートの冒頭部分には、アプリケーションについて一目で分かる概要が記載されています。そこには平均フレームレート、CPUとGPUの平均負荷、およびゲームの特定部分の速度が低下している理由を示すボトルネックグラフが示されます。

上の例では、テストシーン (GFXBench Manhattan) の平均パフォーマンスは23FPSであることが分かります。ご想像通り、ロード画面はCPUバウンドです。そして開始部に近い2つの部分が、このデバイスの目標である30FPSに達すべく管理を行っています。ところが、シナリオの大半はGPUパフォーマンスの制約を受けているため、さらに深堀する必要があります。

リージョン分析

ほぼすべてのゲームが、ロード画面、シーン遷移、レベル選択、オープンゲームプレイ、カットシーンなど、明確に区別できる複数の部分から構成されています。これらはすべて一般的な要素です。各セクションのワークロードは大きく異なる場合が多く、Performance Advisorでは開発者がテストシナリオ内でいくつかのリージョンを定めることができ、各リージョンのパフォーマンス結果が個別にレポートされます。

1フレーム当たりのコストメトリック

ゲーム開発中にアプリケーションパフォーマンスを把握する簡単な方法は、1フレーム当たりのワークロードコストを調べることです。一定量の処理能力で、目標とするフレームレートが念頭にある場合は、フレーム数を減らす前に、1フレーム当たり可能な最大作業量が存在するのは仕方のないことです。本来、Streamlineはこのビューを提示しません。システムプロファイラーとしてのビューは、経時的なパフォーマンスを中心に構築されます。しかし、Performance Advisorは、データ分析中にそのデータをより直感的な1フレームごとののワークロードに変換します。

上の例では、シェーダーサイクル数の増加とフレームレートの低下の間に明確な相関があることが分かります。したがって、最適化を図るために最初に調べるべきなのは、シェーダーの複雑性です。このツールではこれらのチャートに加えて、当社の開発者ポータルへの役立つリンクも提示します。このポータルでは、初回の最適化アドバイスを受けることができます。この場合、シェーダーの算術的な複雑性が高いことでコンテンツに悪影響が及んでいることが分析から分かったため、リンク先のページでは、シェーダーの算術負荷の軽減を図るためのアイデアが紹介されています。

入手できるチャートには、次の主要なパフォーマンスメトリックが含まれています。

  • 1フレーム当たりの全体のGPUサイクル数 (ワークロードタイプ別にレポート)
  • 1フレーム当たりのGPUシェーダーサイクル数 (パイプライン別にレポート)
  • 1フレーム当たりのGPU帯域幅 (読み出しアクセスと書き込みアクセスについてレポート)

また、次の主要コンテンツメトリックも含まれています。

  • 1フレーム当たりのドローコール数
  • 1フレーム当たりのプリミティブ数 (総プリミティブと表示されているプリミティブについてレポート)
  • 1フレーム当たりのピクセル数
  • 平均オーバードローレート

フレームバジェッティング

1フレームごとのチャートの有効な活用法の1つは、ターゲットデバイスで想定されるGPUパフォーマンスに基づいてGPUバジェットを設定することです。たとえば、上の例ではデバイスに最高周波数940MHzのGPUが搭載されています。最小フレームレートを20FPS (これは非常に複雑なベンチマークです) にする場合、1フレーム当たりのGPUコストの絶対的なリミットは次のようになります。

940M / 20 = 47Mサイクル

実際のパフォーマンスをこのバジェットと比較することで、コンテンツの複雑性が原因で目標とするパフォーマンスに到達できないエリアを明確に把握できます。

許容可能なオーバードローレベルや、プリミティブのターゲット可視性レートなど、GPUパフォーマンスに直接結び付けられていないコンテンツメトリックについても同様のプロセスを踏むことができます。

バジェッティング・ワークフローで特に便利なのが、自分がアクセスできないデバイスについてもバジェットを設定できることです。いくつかの簡単な計算を使って周波数とシェーダーコア数を調整するだけで、別のデバイスでのパフォーマンスを概算することができます。レポートに記載されているGPUパフォーマンスデータはすべて、GPUシェーダーコア数で正規化されています。そのため、ターゲットデバイスと使用中のテストデバイス間のシェーダーコア比に基づいて、バジェットを修正する必要があります。たとえば、量産向けデバイスのバジェットを比較的ハイエンドなテストコンフィギュレーションに基づいて設定するとします。

  • テスト・デバイス・コンフィギュレーション: Mali-G72 MP10
  • ターゲット・デバイス・コンフィギュレーション: Mali-G72 MP3、900MHz、60FPS

このターゲットデバイスの場合、バジェットは1フレーム当たり15Mサイクル (900/60) となります。ところが、テストデバイスにはターゲットよりも多くのシェーダーコアがあるため、テストデバイスで15Mサイクルだと、ワークロードがあまりにも多過ぎることになります。3/10のシェーダーコア比でスケーリングすることでバジェットを調整できるため、ターゲットバジェットは4.5Mサイクルになります。

これらのバジェットは理想的なものです。実際の環境では使用率が100%になることはあり得ません。しかし、これらのバジェットは、開発者が堅く守るべき境界を設定するうえで役立ちます。

低速フレームの特定

Performance Advisorの軽量インターセプターを使用してAPIコールをモニタリングする場合、FPSがしきい値を下回ったときのスクリーンショットを撮影して、パフォーマンスが低下したときに画面では何が起きていたのかに関する視覚的なフィードバックを提供することができます。

これによってデバッグ時に役立つコンテキストが得られ、速度の低下が繰り返し発生する場合に共通する要素を特定することができます。上の例では、3枚すべてのスクリーンショットに共通する視覚要素は、サーチライトを点灯したヘリコプターです。これで、調べ始めるべきポイントについてヒントが得られます。先ほど確認したGPUサイクルチャートから、算術的に重いシェーダーを探していることが分かっているため、この2つの情報を基に、Mobile StudioのAPIデバッガであるGraphics Analyzerを使用してコンテンツを確認することができます。

この場合、3枚の低速フレームすべてに含まれているヘリコプターのスポットライト点灯シェーダーが、計算的に重いチェックを実際に行って、各ピクセル座標にあるオブジェクトがスポットライトの光と交差しているかどうかを判断していることがすぐに分かりました。詳細については、低速フレームキャプチャーに関するチュートリアルを参照してください。

使用モデル

Mobile Studio Starter EditionのPerformance Advisorは、特別な設定なしに、Streamlineや軽量インターセプターと使用して、アプリケーションパフォーマンスの初期分析を行うことができます。問題が特定された場合、同じデータをStreamlineで開き、キャプチャーされたすべての利用可能なCPUカウンターおよびGPUカウンターを使ってさらに詳しく調査することができます。

さらに的を絞ったレポートを得るため、Performance Advisorとの統合における次のステップは、ゲームに注釈を追加して、テストシナリオをコンポーネントリージョンに落とし込むことです。これにより、生成されるレポートは内容がさらに充実し、パフォーマンスデータに関するリージョンごとの内訳が提示されます。

Mobile Studio Professional Editionは2020年中にリリース予定ですが、これによって、自動化されたCIワークフローでMobile Studioのツール群を使用できるようになります。この使用モデルでは、人間がGUIを使ってツールを操作することなくデバイスからデータをキャプチャーできるように、Streamlineがヘッドレスモードで実行されます。そして、このヘッドレスデータキャプチャーからPerformance Advisorレポートが作成されます。さらに、Performance Advisorは、オンデバイステストから得られた詳細データを既存のパフォーマンス・モニタリング・システムに統合できるように、主要なメトリックをJSONレポートとしてエクスポートする機能をサポートします。

ご意見、ご感想をお寄せください

当社のベータプログラムにご参加いただいた開発者の皆様に、この場を借りて感謝を申し上げたいと存じます。好意的なものもそうでないものも含め、皆様からのご意見、ご感想のおかげで、本製品を形作り、今日の姿にすることができました。

するべきことはまだ他にもあります。レポートを改善するためのアイデアや、お見せできるようになりたいその他のメトリックもまだたくさんあります。重要なのは、当社のレポートが開発者の皆様の役に立ち、正しい情報を理解できる形でご提供することです。このブログで使用したPerformance Advisorレポートはダウンロードすることができます。ご意見、ご感想、追加してほしい機能などがございましたら、フィードバックフォームからご連絡ください。

Mobile Studioのダウンロードはこちら

  1. 「なに!?ハスケル子ちゃんからワイに相談やと!?」feat.やめ太郎
  2. ITインフラ自動化のあらゆるトピック・事例が紹介された、Red Hat Ansible Automates Tokyo 2020 Day1