「Unityモバイルゲームパフォーマンス最適化略譜」は 4 つの部分に分かれています。今日は、記事の最後の部分である、画像のパフォーマンスと GPU の負荷のトレードオフ、帯域幅、オーバードロー、レンダリング効果、後処理、レンダリング戦略、シェーダーの複雑さなど、その他多くの一般的なゲーム画面のパフォーマンスの説明合計 8 つのセクションを紹介します。（全文は約6600語、読了時間の目安は約15分）
最初の 3 つの部分は、以下の対応する記事をクリックして表示できます。
[Unityモバイルゲームパフォーマンス最適化略譜2]
(https://blog.jp.uwa4d.com/2022/09/10/4611/)
[モバイルゲームパフォーマンス最適化ーーエンジンモジュールのCPU 時間チューニング]
(https://blog.jp.uwa4d.com/2022/09/16/%e3%83%a2%e3%83%90%e3%82%a4%e3%83%ab%e3%82%b2%e3%83%bc%e3%83%a0%e3%83%91%e3%83%95%e3%82%a9%e3%83%bc%e3%83%9e%e3%83%b3%e3%82%b9%e6%9c%80%e9%81%a9%e5%8c%96%e3%83%bc%e3%83%bc%e3%82%a8%e3%83%b3%e3%82%b8/)
1、概要
現在、ますます多くのモバイル ゲーム開発チームが、ますます高いグラフィックス パフォーマンスを追求しています。 GPU 側は CPU 側を凌駕し、多くのプロジェクトでパフォーマンス プレッシャーの主な原因となっています。しかし、GPU 側はハードウェア レベルでより多くの問題を伴うことがよくあります。市場に出回っているさまざまなメーカーのさまざまなチップは、さまざまな現象を反映していて、開発者はデバイス分類や標準策定を行うのは、面倒なことになってしまいました。視点を変えて見れば、GPU パフォーマンスの検出は Unity エンジンに関連するツールでは提供されないことが多く、ハードウェア メーカーが提供するさまざまなツールは数が多くて使いにくいため、眩しくて要点を把握できません。 GPU パフォーマンスの問題のトラブルシューティングと最適化に大きな困難をもたらします。
2.帯域幅
2.1 GPU ストレスと発熱/エネルギー消費
UWA は、帯域幅と発熱/エネルギー消費との関係の定量的な実装を行ったが、チップ底層の状況は、私たちが想像していたよりもはるかに複雑です。私たちの経験と、チップ メーカーのプロのハードウェア エンジニアとのコミュニケーションから得られた結論は、モバイル デバイスの GPU 帯域幅のプレッシャーは、特に発熱に関してエネルギー消費に影響を与えるということです。しかし、これは定性的記述であり、現時点では、私たちもチップ メーカーも、その影響の大きさを特定するための具体的な定量的な公式を持っていません。したがって、プロジェクトが熱を発生させたり、多くのエネルギーを消費したりする場合、開発者は帯域幅に特に注意を払う必要があります。
UWA ツールは、ゲームのテスト中にハードウェアの温度の変化を監視できます。一般的に言えば、55°C を超える温度を長時間維持することは、注意が必要です。UWA のさらなる GPU 専用のサービスでは、GPU と CPU の温度が収集され、より詳細に表示されます。
2.2 GPU プレッシャーとフレームレート
前述のように、GPU プレッシャーは、CPU が GPU の作業を完了するのを待つために必要な時間を増加させます。同時に、レンダリングモジュールの CPU 側の主要な機能の消費時間も増加させます。その結果、フレーム レートに影響し、フリーズが発生します。
また、モバイルハードウェアのサイズが小さく放熱が難しいという客観的な問題により、GPU の加熱は物理的に大きな影響を与え、同時に CPU チップの温度が上昇し、深刻な場合には周波数の低下が発生します。
UWAツールを介してGfx.WaitForPresentとレンダリングモジュールの主要な関数の時間のかかるデータを監視することに加えて、GOTオンラインOverviewモードは、テストでGPUの時間のかかるデータも反映し、視覚的にGPU パフォーマンスのボトルネックを監視するようにします。現在、GOT Online は Mali GPU 統計帯域幅の API も統合しており、Mali チップ テスターを使用してOverviewレポートを提出することで、GPU シェーディングと帯域幅のデータを取得できます。今後、Qualcomm およびその他のハードウェアの関連機能のサポートが徐々に追加されます。
UWA のさらなる GPU 専用サービスでは、帯域幅データとクロック データも組み合わせて、高プレッシャーシーンに向けてDrawCall ごとで帯域幅使用率と GPU 時間が高い理由を分析します。4.3の始まりでよく見られる原因のいくつかを説明します。
2.3 帯域幅の最適化
帯域幅データは、GPU の負荷を測定するための重要な基準です。比較的ハイエンドなMi 10モデルの場合、フル解像度の場合、30フレームを実行しても熱が安定している必要があれば、合計帯域幅を3000MB/s未満に制御する必要がありま。この目的のために、一般的な最適化方法は次のとおりです。
(1) 圧縮形式
メモリの部分で多かれ少なかれ説明したように、適切な圧縮形式を使用すると、テクスチャ帯域幅を効果的に削減できます。
(2) テクスチャミップマップ
3D シーンの場合、オブジェクトで使用されるテクスチャの Mipmap 設定を有効にすると、わずかなメモリの増加を犠牲にして帯域幅を効果的に削減できます。オブジェクトがカメラから離れている場合、エンジンはテクスチャ サンプリングに下位レベルのミップマップを使用します。ただし、Mipmap 設定は妥当なテクスチャ解像度にもリンクされています。よくある現象として、実際のレンダリング処理では、Mipmap の 0 番目のレイヤーのみが使用されるか、そのほとんどがサンプリングに使用され、メモリが浪費されるため、このタイプの テクスチャの解像度の軽減を検討してください。。
UWA ツールは、問題を特定するために、さまざまなミップマップ レベルでサンプリングされたピクセルをさまざまな色で表します。さらなるサービスでは、各シーンで上記の無駄な現象が発生しているテクスチャが、各ミップマップ レベルの使用率に従って一覧表示されます。
(3) 合理的なテクスチャ サンプリング方法
ミップマップ非ゼロ層サンプリングの合理的な使用に加えて、プロジェクトでの異方性サンプリングとトリリニア補間サンプリングにも注意を払う必要があります。一般に、テクスチャが圧縮およびサンプリングされると、キャッシュの内容が読み取られますが、読み取られない場合は、GPU から離れたシステム メモリが読み取られるため、より多くのサイクルが必要になります。サンプリング ポイントの数が増えると、キャッシュ ミスの確率が高くなり、帯域幅が増加します。異方性サンプリングの数は、Unity では 1 ～ 16 に設定されており、できるだけ 1 に設定する必要があります。トライリニア サンプリングは、バイリニア サンプリングに比べて 2 倍の 8 つの頂点を使用します。
UWA のローカル リソース検出サービスでは、異方性サンプリングまたはトライリニア サンプリングが有効になっているテクスチャ リソースをカウントして一覧表示できます。
(4) レンダリング解像度を変更する
レンダリング解像度を 0.9 倍またはそれ以下に直接変更し、テクスチャ サンプリングに関連するピクセルを減らし、帯域幅をより効果的に削減します。
また、読み込み頂点の帯域幅にも注意してください。テクスチャと比較すると、その割合は一般的に小さくなります。ただし、テクスチャとは異なり、レンダリング解像度を変更すると、テクスチャを読み取る帯域幅を効果的に削減できますが、頂点を読み取る帯域幅は影響を受けません。したがって、メッシュ リソースの制御と同じ画面上でレンダリングされるパッチの数が有効になった後、読み取り頂点の帯域幅の値が総帯域幅の 10% ～ 20% を占めるのが妥当です。
3.オーバードロー
オーバードロー、つまり、同じピクセルを複数回描画することによって発生する GPU オーバーヘッド。シーン内のレンダリング順序が適切に制御されている理想的な状況では、不透明なオブジェクトのオーバードローは 1 つのレイヤーで制御する必要があります。したがって、オーバードローの主な原因は半透明のオブジェクト、つまりパーティクル システムと UI です。
3.1 パーティクル システム
UWA のパフォーマンス分析ツールを柔軟に使用することで、GPU のプレッシャーに大きく貢献しているパーティクル システムを効果的に特定できます。
1 つの方法は、プロジェクトで使用されるパーティクル システムが順番に再生される特別な空のテスト シーンを作成し、UWA SDK を使用してパッケージ化テストを行い、GOT オンライン概要レポートを提出することです。 GPU 時間コストの曲線で、テストのスクリーンショットと組み合わせて、再生時に GPU の時間がかかるパーティクル システムを見つけます。
もう 1 つの方法は、UWA のローカル リソース検出レポートを直接使用することで、参考としてオーバードローが高くなるパーティクルのリストを直接見ることができます。
最適化が必要なパーティクル システムが選択された後、ローエンド デバイスに対してそれらの複雑さとスクリーン カバレッジを可能な限り削減します。具体的な方法は次のとおりです。
(1) ローエンドおよびミッドレンジ モデルでは、パーティクル システムの Max Particlesに制限を追加します。
修正前:
Max Particles を 10 に制限した後:
(2) ローエンドおよびミッドレンジ モデルでは、「重要な」パーティクル システムだけを保留するようにします。たとえば、炎の燃焼という特殊効果については、炎自体だけを保留し、周りの煙とほこりの効果はオフにします。
(3) 画面上のパーティクル エフェクトのカバー範囲をできるだけ小さくします。カバー範囲が広いほど、重なるカバーが生成されやすくなり、オーバードローが高くなります。
パーティクル システムの最適化に関しては、UWA DAY 2018 でモバイル ゲームの GPU パフォーマンスの最適化について分析を行いました。たくさんの実のケースと組み合わせて、GPU 側でのゲームのパフォーマンスボトルネックを分析しました。記事形なら以下の参照してください。 「モバイル ゲームの GPU パフォーマンスの最適化」（中国語注意）https://edu.uwa4d.com/course-intro/1/90.
3.2 UI
(1) 全画面 UI を開くと、背景によってブロックされている他の UI を閉じることができます。
(2) アルファが 0 の UI の場合、Canvas Renderer コンポーネントで CullTransparent Mesh を選択できます。これにより、レンダリングせずに UI イベントの応答を保証できます。
(3) Maskコンポーネントの使用を最小限に抑えましょう。これは、描画のオーバーヘッドを増加させるだけでなく、DrawCall を上昇させます。オーバードローが高い場合は、代わりに RectMask2D の使用を検討してください。
(4) URP の下に、不要な Copy Color や Copy Depth がないかどうかに特に注意する必要があります。特に、UI と戦闘シーンのカメラに同じ RendererPipelineAsset を使用すると、不要なレンダリング時間と帯域の浪費が発生しやすく、GPU に不要なオーバーヘッドが発生します。通常、UI カメラとシーン カメラには異なる RendererData を使用することをお勧めします。
4、レンダリング効果
パーティクル エフェクトに加えて、ボリューム フォグ、ボリューム ライト、水、サブサーフェス リフレクションなど、クールなレンダリング エフェクトを使用してゲームのパフォーマンスを向上させることがよくあります。ただし、そのようなエフェクトがシーンで使用されるほど、シェーダー 複雑になればなるほど、許容範囲をはるかに超えて GPU にかかる負荷が大きくなります。
最適化とトレードオフは、最終的にどのレンダリングを残すかを決定する主要な手段です。
一方では、複数のスキームから効果とパフォーマンスが優れているものを比較して選択し、独自のプロジェクトのニーズに応じてオープンソース スキームを合理化および最適化します。 UWAのブログで、十分に最適化され、実際にテストされたソリューションを見つけることができます。
５、後処理
ブルームは、開発者にとって最も好まれていてよく見られる後処理効果です。よくある問題は、Bloom がデフォルトでレンダリング解像度の 1/2 からダウンサンプリングすることです。この点で、ローエンド モデルの 1/4 解像度からのダウンサンプリングを検討するか、ダウンサンプリングの数を減らすことができます。
さまざまな後処理効果のパフォーマンス オーバーヘッドと実際の使用シナリオは異なり、実際のプロジェクトで発生する問題も異なることがよくあります。また、UWA ブログには、後処理関連の記事やリソースが多数あります。
６、レンダリング戦略
6.1 描画順
シーン内にカメラから遠い不透明なオブジェクトとカメラに近いオブジェクトがあり、2 つが重なっている場合、遠いオブジェクトが近いオブジェクトによって遮られている部分のピクセルが2 回描画され、オーバードローが発生することがあります。
これはしばしば地形で発生します。本来、不透明なオブジェクトのRender Queueが同じ場合、エンジンが自動で判断し、カメラに近いオブジェクトを優先して描画します。しかし、地形の場合、一部のパーツは他のオブジェクトよりもカメラに近く、一部のパーツは遠くにあることが多いため、優先的に描画されます。
そのため、カメラに近いオブジェクト（タスクやオブジェクトなど）が先に描画され、地形など遠方のオブジェクトが最後に描画されるように、Render Queueなどを設定する必要があります。モバイル プラットフォームでは、Early-Zメカニズムを通じて、ハードウェアがフラグメント シェーダーの前に深度テストを実行し、遠くにあるオブジェクトによって遮られたピクセルの深度検出がパスしないため、不要なフラグメント計算が節約されます。
6.2 無効な描画
視覚的にはっきりしない効果をオフにしたり、代わりにコストがより低い描画スキームを使用したりできる場合があります。
たとえば、背景を描画する一部の DrawCall は画面比率が大きく、コストが高いが、エンジンでこの DrawCall を切り替えても明らかな視覚的変化はないことがあります。これは制作プロセスで破棄され、または他の DrawCall によって完全に覆い隠されたかもしれません、オフにすることができます。
もう一つ、一部の背景はモデルで描画され、さらにぼかしや霧などの追加レンダリング効果があります。ただし、シーンでは、視野角は固定されており、これらの背景はほとんど変化しません。そのため、これらの複雑な描画を代わりに静的画像を使用することを検討してください。このように、ローエンドデバイスでは、より多くの性能をゲームロジックと表示効果に残します。
6.3 レンダリング範囲
レンダリング範囲が大きいために発生するパフォーマンスの問題は、パーティクル エフェクトに反映され、議論されています。しかし実際には、不透明なオブジェクトにも適用します。DrawCall の場合、レンダリング エリアが大きく、レンダリング リソースが多く複雑な場合、この 2 つは常に相乗効果を示します。これは、より多くのピクセルがテクスチャ サンプリングに参加し、Shader 計算に参加し、GPU がより高い圧力をもたらすことを意味します。
7、シェーダーの複雑さ
テクスチャ、メッシュ、レンダー テクスチャに加えて、シェーダーと呼ばれる GPU プレッシャーに大きく寄与するレンダリング リソースもあります。 UWA は、フラグメント シェーダーの画面比率、命令数、およびクロック サイクル数に特別な注意を払います。レンダリングされるピクセルが多くなり、複雑さが増すほど、シェーダー リソースを最適化する必要があります。
このうち、Shaderの命令数とクロック サイクル数は、Mali Offline Compiler ツールを使用して取得できます。 UWA のさらなるサービスでは、最適化が必要なシェーダー リソースとそのバリアントを特定するために、さまざまなキーワードの組み合わせでプロジェクト内の使用率が高いすべてのシェーダーのバリアントの複雑さが詳細にテストされます。
８、まとめ
この記事が略譜と呼ばれたのは、これだけの文字で至れり尽くせりに至れなくて、多くの内容がまだカバーされていないか、紙面と焦点の都合で詳しく論じることはできないかの原因でまだ触れなかった内容がたくさん残されています。問題の発見、解決、監視という順での最適化の考え方と最適化システムを構築するための基礎として、完全なパフォーマンス ツールのセットを使用する方法に基づいているため、パフォーマンスの最適化は半分の労力で 2 倍の結果を得ることができます。より優れたコンテンツについては、UWA コミュニティで検索してください。
これまでに「Unity Mobile Game Performance Optimization Notes」を更新しました.この記事では、Unity モバイル ゲームの最適化に関するいくつかの基本的な議論から始めて、近年 Unity に基づいて開発されたモバイル ゲーム プロジェクトで最も一般的なパフォーマンスのいくつかを例示および分析しています.を参照し、UWA のパフォーマンス インストルメンテーション ツールを使用してそれらを特定して解決する方法を示します。このコンテンツには、パフォーマンス最適化の基本的なロジック、UWA パフォーマンス検出ツール、および一般的なパフォーマンスの問題が含まれており、Unity 開発者により効率的な R&D 方法と実践的な経験を提供することを望んでいます。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
今なら、UWA GOTローカルツールが15日間に無償試用できます！！
よければ、ぜひ！
UWA公式サイト：https://jp.uwa4d.com
UWA GOT OnlineレポートDemo：https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ：https://blog.jp.uwa4d.com