ワールド・オブ・タンクス・ブリッツ (WoT Blitz) は、リリースから 7 年間にわたり、Wargaming 社で最も古くて大きなモバイル スタジオである MS-1 によって継続的にアップデートされてきたセッションベースの戦車シューターです。2014 年には iOS と Android 対応のゲームが発売され、数年後には、デスクトップ プラットフォームの Windows および macOS 向けにリリースされました。また、2020 年には Nintendo Switch で WoT Blitz がデビューしました。Android と iOS は引き続き Wargaming 社の主要なプラットフォームであり、低価格帯のモバイル デバイスから最新のフラッグシップ機まで、スケーラブルなパフォーマンスの実現に向けて取り組んでいます。
すべてのゲームにとって、パフォーマンスは非常に重要です。独立した学際的な Arm 社の開発チームで働く約 200 人のスタッフにより、毎年約 10 回の主要なアップデートを行っています。このペースとスケールに対応するには、多くのプロセスを自動化する必要があり、パフォーマンス テストも例外ではありません。この記事では、継続的インテグレーション (CI) テストを利用して、WoT Blitz のプレーヤー向けに最適なエクスペリエンスを実現する方法をご紹介します。また、以下のトピックについてもご説明します。
- 自動パフォーマンス テスト方法の概要
- CPU プロファイリング
- ワークフローにおける Arm Mobile Studio およびパフォーマンス アドバイザーの役割
WoT Blitz のパフォーマンス テスト方法の概要
ゲーム ロビーはさておき、実際のゲームプレイ (バトル アリーナ) のみを考えた場合、パフォーマンス テストには下記のメトリクスに対する制御が含まれています。
- プロセスによって使用されるメモリ
- マップの読み込み時間
- フレーム時間
自動化されたテストは、メインラインのビルドに対して毎晩トリガーされます。QA エンジニアは、以下のいずれかを含むチェンジセットを検証する際に、これらのテストをトリガーします。
- コンテンツの変更
- パフォーマンスに影響を与える可能性のあるコードの変更
テスト デバイスがビルド エージェントの役割を果たす継続的インテグレーション (CI) サーバーを使用して、テストを実行します。Arm 社のデバイス ファームは、サポートされているすべてのプラットフォームと全体のパフォーマンス レベル スペクトルなどの計 30 個以上のデバイスで構成されています。
Arm では、メインラインに入る前に問題を特定できるよう最善を尽くしていますが、万が一メインラインで問題が発生した場合は、夜間の回帰テストで表示されます。コンテンツとデバイス モデルが豊富であるため、夜間のテスト結果をすべて表示するための特別なダッシュボードを作成しました。以下は、マップの読み込み時間のテスト向けに提供されるダッシュボードの一部の状態 (フル バージョンでは 13 列、30 行) になります。
Arm では、メインラインに入る前に問題を特定できるよう最善を尽くしていますが、万が一メインラインで問題が発生した場合は、夜間の回帰テストで表示されます。コンテンツとデバイス モデルが豊富であるため、夜間のテスト結果をすべて表示するための特別なダッシュボードを作成しました。以下は、マップの読み込み時間のテスト向けに提供されるダッシュボードの一部の状態 (フル バージョンでは 13 列、30 行) になります。
コンテンツや、サポートされるプラットフォームとパフォーマンス レベルの数を考慮すると、開発には自動化されたパフォーマンス テストが必要不可欠であることは明白です。
- 自動化されたプロセスによって夜間にトリガーされるテストをすべて手動で実行しなければならない場合、そのためだけに 2 ～ 3 人の常勤雇用の社員を割り当てる必要があります。それだけでなく、デバイスやコンテンツのカバレッジ、回帰テストの頻度などが低下し、開発スピードに悪影響を及ぼす可能性があります。
- パフォーマンス テストを必要とする新しいコンテンツや機能のテストには、現在よりも 10 ～ 20 ％ も多くの時間がかかります。また、手動のパフォーマンス テストは信頼性が低いため、より多くの問題がメインラインで発生する可能性があります。
レポートにおける詳細データの必要性
前述したように、メインラインの問題を 1 営業日以内に解決することは非常に重要です。しかし、多くの独立した専門チームが存在するため、まずはどのチーム内で問題が発生したのかについて調べなければなりません。テストは夜間に行われますが、Arm の開発規模では、毎日 10 ～ 15 個の重要な PR がメインラインにマージされます。また、コードを確認するだけでは、問題を原因となるコードを見分けることが困難です。そのため、一部のメトリクスにおける正確な変更要因について、可能な限り詳細な情報が必要でした。
レポートの追加データは、メインラインで発生した問題の修正に関して責任のあるチームを定義するだけでなく、機能テストにおいて非常に役立ちます。レポートで実行に時間が掛かった機能を特定するなど、レポートで詳細データを確認することで、プログラマーは、ゲームを手動でプロファイリングせずに問題を特定できます。同様に、この種のデータにアクセスできるコンテンツ メーカーは、どこを最適化すればよいかをすぐに特定できます。
たとえば、メモリ テストには、メモリ プロファイラーを備えた特別なビルドを使用します。これにより、使用されているメモリ プール全体を約 30 種類も存在する「カテゴリー」に分け、プロセスによる全体のメモリ使用量の変化だけでなく、より詳細なスクリーンショットを確認できます。
マップの読み込み時間のテストでは、レポートには読み込み時間の数値だけが含まれます。
ただし、問題が発生した場合は、テスト アーティファクトでプロファイラー トレースを使用して json を見つけることができます。
マップの読み込み時間の増加に対応するには、2 つのテストランの json ファイルをダウンロードし、chrome://tracing を使用して比較するだけで十分です。
Arm では、FPS 測定テストのレポートで詳細を表示するための便利な方法をかなりの時間をかけて検討しました。その結果を説明する前に、この種類のテストに対する Arm の一般的なアプローチについて簡単にご紹介します。
メリット:
- テストはプレーヤーが見る画面に非常に近いものです。
リプレイの過程で、さまざまなゲームのプレイイベントが発生し、実際のゲームと同様の量のグラフィック要素 (UI、パーティクル) が表示されます。 - 新しいマップのテストは簡単に取得できます。スクリプトの段階はなく、プレイテストのみが必要です。もちろん、このようなテストをアリーナのコンテンツの完全なテストと呼ぶことはできません。プレイテストでは、特定のプレーヤーが通るルートを確認するだけです。ただし、コンテンツを確認するために、カメラを 8×8 グリッドのポイントに配置し、それぞれを 45 度ずつ完全に回転させる個別のテストを行います。
デメリット:
- テストにはかなりの時間がかかります。1 つのマップは約 4 分以内に処理され、それをマップの数 (30) で乗算すると、2 時間になります。
- リプレイでは、ゲームの状態が非常に動的に変化し、FPS の短時間の低下をリプレイの具体的な部分に紐づけることが難しい場合があります。
CPU プロファイラーによる FPS 測定テスト レポートの強化
長い間、レポートに表示される唯一の結果は、FPS の平均値でした。また、テストランのアーティファクトの中には、ポイントによって 1 秒の長い間隔の FPS の平均値を表す詳細なチャートがあります。ただ、単一の長いフレームが認識されていなかったため、後者には誤りがあることが分かりました。この事実が判明した際、すべてのフレームの長さを測定するのではなく、内部の CPU プロファイラーをオンにしてテストを行いました。ローエンドのデバイスでプロファイラーがフレーム時間に影響を与えないようにするため、フレームごとにカウンターの数を制限する必要がありました。そこで、コード内のすべてのカウンターをタグ付けし、グループをオンまたはオフに切り替えることができるタグ付け機能を追加しました。デフォルトでは、自動テストが開始されると、フレームあたり 70 個以下のカウンターがあります。
自動テストでプロファイラーをオンにすると、各機能の作業時間の予算を設定することができます。これにより、特定のシステムのパフォーマンスの急な上昇をトラッキングできます。また、予算を立てることで、新しいシステムをゲームに導入する際の判断がしやすくなります。たとえば、数年前にゲームの戦闘時の UI コントロールの自動レイアウトを追加することを決めたとき、テストで FPS の値に影響を与えないことを確認しました。プロファイラーを導入してからは、自動レイアウトに費やすフレーム時間が長いことに非常に驚きました。本来であれば、新しいシステムを導入する前に、予算を決めておくのが正しい方法です。たとえば、「Samsung S8 では、レイアウト処理は 1 フレームあたり 1 ミリ秒以内である必要がある」など、コードやコンテンツの変更によって予算オーバーにならないように、自動テストでさらに管理する必要があります。
リプレイの最後には、プロファイラーのトレースを分析し、予算を超えた機能を持つフレームのみを含む json をアーティファクトに配置します。次の例では、数十個のフレームがリストアップされていますが、それぞれのフレームで Scene::Update 機能の実行に必要以上に時間がかかっているのが分かります。
急な上昇に気づくのは比較的簡単ですが、一部の関数の実行時間のわずかな増加に簡単に気づくための表現は何でしょうか。2 つの 4 分間のトレースを比較するというオプションは受け入れられないように見えましたので、いくつかの統計から始めることにしました。最も興味深い関数の小さなセットについて、関数の実行時間が特定の範囲に達するフレームの数を計算し、度数分布を取得します。
次に、このデータを bigquery に送信し、データ スタジオを使って可視化します。
上のチャートでは、Engine::OnFrame の実行に 24 ～ 28 ミリ秒かかったフレームの数が、9月 27日には大幅に増加したことがわかります。この原因は、次の簡単なシーケンスで特定できます。
- コールスタックのレベルを 1 つ下げます。
- 問題の原因となっている関数が見つかるまで、ダッシュボード フィルターを使用して先程のコールスタックのレベルから関数を連続して選択します。
- 最下層のレベルに達していない場合は、ステップ 1 に戻ります。
最下層のレベルまで到達して問題のある関数を見つけた場合は良いですが、すべての関数で実行時間が増加したり、不均一な場合はどうでしょうか。これには、いくつかの理由が考えられます。
- モバイル デバイスでのパフォーマンス テストにおける最大の問題点の 1 つであるサーマル スロットリングの可能性が非常に高いです。Arm では、テスト デバイス ファームを寒い部屋に置くことで、この問題を解決しました。少し非現実的な条件でテストを行いましたが、ほとんどのデバイスで安定した結果を得ることができました。
- 新しいスレッドが出現し、CPU 時間 (プロセッサー時間) がコードと競合しています。これは、サンプリング プロファイラーで確認できます。
インストルメンテーション CPU プロファイラーをテストに導入しても、サンプリング プロファイラーを使用する必要性は排除されませんが、サンプリング プロファイラーが必要になるケースの数は減少しました。また、アセンブラー コード内の個別の命令の実行時間を確認する必要があるマイクロ最適化のようなケースも減少しました。
さて、話を「9月 27日」の問題に戻しましょう。前述の一連の動作を適用した結果、rhi::DevicePresent 関数が原因であることがわかりました。この関数は、バッファー スワップを呼び出すだけなので、ボトルネックは GPU 側にあるはずです。しかし、GPU によるフレーム処理時間が長くなった原因については、レポートからどうやって知ることができるでしょうか？
GPU メトリクス
注意深い方は、データ スタジオのスクリーンショットに表示されている前のフィルターの値の 1 つが、関数である “DrawCallCount” には見えないことにお気づきかもしれません。このようなメトリクスには、”PrimitiveCount” “TriangleCount” “VertexCount ” なども含まれます。残念ながら、GPU 側の速度低下の原因を突き止めるために CPU 側で収集できるデータはこれだけです。しかし、「9月 27日」の問題を解決するには、このデータだけで十分でした。
最終的には、多くのフレームで 150,000 以上のプリミティブを描画することができました。このデータを、2 つのテストランの間にマージされた PR のリストと照合することにより、問題のある変更セットを速やかに特定することができました (グラフから 3 日間の間隔があることがわかりますが、そのうちの 2 日間はテストを実行していない週末でした)。
しかし、根本的な問題の原因がシェーダーの複雑化にあった場合はどうでしょうか? あるいは、描画の順番が変わったことで結果的にオーバードローが増えた場合や、深度バッファーが誤ってメイン メモリに保存され始め、帯域幅に悪影響を及ぼした場合はどうでしょうか?
オーバードローの場合、これらのメトリクスをゲーム内でトラッキングすることは難しく、シェーダーの複雑化や帯域幅の場合は不可能です。ここで、Arm Mobile Studio Pro Edition が非常に貴重な役割を果たしてくれます。
Arm Mobile Studio Pro Edition による GPU 負荷に関する洞察の提供
Arm Mobile Studio Pro Edition では、CI サーバー上で自動テストを実行しながら、Mali™ GPU のハードウェア カウンターを記録することができ、3 種類のタスクの解決に役立ちます
- 回帰テストにおいて、GPU 側での正確な変化を特定する。
- 新しいコンテンツのテストでボトルネックを特定し、最適化すべき箇所を理解する。
- 新しいグラフィック機能を導入する際に、ターゲット デバイスを意識して選択する (前述の通り、非常に幅広いデバイスがサポートされており、グラフィック機能は一般的にグラフィック設定メニューで有効化されます)。
Arm Mobile Studio にはパフォーマンス アドバイザーという非常に重要な機能があり、テスト中に記録されたプロファイラー トレースを、読みやすい html のレポートとして表示することができます。
ここでは、Arm Mobile Studio (特にパフォーマンス アドバイザー) がどのように 3 つ目のタスクの解決を加速するかを見ていきましょう。
Arm では、最近エンジンにデカールを追加したのですが、テクニカル アーティストはアリーナのジオメトリとデカールを重ね合わせるためのバジェットを定義するという課題に直面しました。このタスクの詳細は次の通りです。
- 機能を利用できるようにしたいターゲット デバイスを定義する。
- FPS テストの結果が出ている既存のマップにデカールを追加し、テストコンテンツを準備する。
- ターゲット デバイス上で、変更したコンテンツを含むビルドの自動テストを実行する。
- 結果を評価し、FPS レベルが大幅に低下している場合は、コンテンツのバジェットを確認してステージ 2 に戻るか、ターゲット デバイスのリストを見直す。
パフォーマンス アドバイザーは、4 つ目のタスクを大幅に簡素化します。例えば、1 つ目のタスクでターゲット デバイスとして、Mali™-G72 MP3 を搭載した「Samsung Galaxy A50」を選択したとします。このデバイスでテストを行った場合、パフォーマンス アドバイザーのレポートの最初の部分は次のようになります (グラフィック品質の設定は高くなりますが、現時点ではデカールはありません)。
FPS の観察結果は以下になります。
- FPS は特定の時間に 30 に低下しました。これは、パフォーマンス アドバイザーがなくても特定できます。
- 問題のある箇所では、デバイスは明らかにフラグメントがバインドされていました。これは、デカールでコンテンツの予測を立てることができます。
デカールを使用してビルドのテストを開始し、アーティファクト内でパフォーマンス アドバイザーによって生成された html のレポートを見つけて、それを開きます。
今回のデバイスでは、テクニカル アーティストが最初の反復で追加したデカールの数により、フラグメントにバインドされたフレームの割合が大幅に増加しました。
パフォーマンス アドバイザーは、すべてのケースでボトルネックを直接示すわけではありません。たとえば、強力なデバイスでは、未知の境界がある場合があります。
このような状況では、完成したキャプチャ ファイルが役立ちます。テストランのアーティファクトからこれらをダウンロードし、Streamline で分析できます。幸いなことに、パフォーマンス カウンターはドキュメントで詳細に説明されており、Arm のエンジニアも相談に応じることができます。
Arm Mobile Studio Professional Edition は、簡単かつ迅速に CI ワークフローの一部となりました。便利なパフォーマンス アドバイザーのレポートとプロファイラーの完全なトレースに加えて、パフォーマンス アドバイザーのレポートのグラフに表示されているすべてのメトリクスの平均値とパーセンタイルを含む json ファイルも受信します。近い将来、このデータを bigquery に送信し、CPU プロファイラーのデータに対してすでに行っているように、データ スタジオを使用して視覚化する予定です。メトリクス自体については、こちらをご覧ください。
Arm Mobile Studio では、Mali™ 系列の GPU についてのみ追加データを取得できますが、これらはプレーヤー ベース内で最も普及している GPU です。同様に、Mali™ GPU ファミリを搭載したデバイスで実行したテストから得られた多くの結果は、他のデバイスでも有効です。たとえば、Mali™ で帯域幅が増加した場合、他の GPU でも増加している可能性が高く、おそらく他のプラットフォームでも増加していると思われます。
つまり、自動テストのレポートに GPU パフォーマンスに関するデータがないという問題を解決することができたのです。
まとめ
MS-1 (Wargaming 社) では、積極的に日常業務の自動化に取り組んでいます。パフォーマンス テストは、長い間自動化されていましたが、まだ改善の余地がありました。
テスト レポートの冗長性に力を入れた結果、テストと問題の調査、両方の時間を節約する自動フレームワークができました。これで、手動でプロファイリングを設定するという退屈な段階をスキップして、コードやコンテンツの多くの問題を特定できます。自動化されたテスト環境でプロファイリング データを収集することは、データへのアクセスを容易にするだけでなく、データの品質も向上させます。
- 安定したテスト環境は、より安定したデータを意味します。室温が 3 〜 5℃ 違うだけでテスト結果に影響を与えるモバイル デバイスでは、特に重要です。
- 過去のデータにアクセスすることで、パフォーマンス メトリクスの大きな変化とノイズを見分けることができます。また、データの質は解析の速度に大きく影響します。
Arm では、自動化されたパフォーマンス テストは、中規模または大規模なゲーム スタジオにとって必須であると考えています。作業時間を削減するだけでなく、テストやリスク管理の質にもつながります。夜間のテストを行うことにより、最終的なプレイテスト中に発生したパフォーマンスの問題が、リリース スケジュールに影響を与える心配はありません。
Arm Mobile Studio を入手する
継続的インテグレーションのワークフローにパフォーマンス解析プロセスを組み込むことができる Arm Mobile Studio Professional Edition は、30 日間無償でお試しいただけます。
Arm Mobile Studio の詳細は、こちらの製品ページからご確認ください。
30 日間無償評価版は、こちらからダウンロードできます。
この記事は、Arm 社の Graphics and Gaming Blog に公開されている「World of Tanks Blitz: Automated performance testing for modern graphics needs」の日本語参考訳です。
