始める前に少し前置きをします。 私は常に少し不思議に思っていましたが、なぜこのゲームが提供するビジュアルのためにこれほど大きな電力消費が必要なのかということです (プラットフォームとしてのモバイルだけでなく、ROG Ally なども苦労します)。結局のところ、最近リリースされたタイトル (ここで名前を挙げていいのかわかりません) と比較すると、モバイルでの視覚的な忠実度は電力使用量と比べてかなり不釣り合いでした。
これでテストのセットアップが始まります。このデータは Snapdragon 8 Elite でキャプチャされました。 Samsung は最近 Sokatoa を発表しましたが、ほとんどが Perfetto を使用しているだけです。ただし、この情報により、なぜローエンド ハードウェアのパフォーマンスがひどいのかについてある程度の洞察が得られます。データは主に Roya でのオープンワールドのスプリントのみで収集されますが、戦闘データは、戦闘中に激しい温度上昇を引き起こすさらに深刻な問題を指摘するために一度使用されます。 (その際に記載します)
1. プリズム拒絶（核心問題）
レンダリングでは、GPU は三角形 (プリミティブ/プリズム) を処理します。最終イメージに寄与する前に、いくつかの段階を経ます。 "些細な拒否" それは最初のチェックで捨てられるときです。画面外にあるもの、ピクセルをカバーしていないもの、またはカメラの反対側を向いているもの。これは、ラスタライゼーション、テクスチャリング、ピクセル シェーディングなどの贅沢な作業の前に行われます。それは可能な限り安価な拒否です。
の 問題 ただし、そのチェックに至るまでの作業はそうではありません 無料、CPU はすでに描画呼び出し (画面上にオブジェクトをレンダリングするように GPU に指示するために CPU によって発行されるコマンド) を構築しています。 GPU はすでに頂点データをフェッチしています3D オブジェクトの形状と外観を定義する、位置、色、テクスチャ座標、法線などの情報の構造化されたコレクション。 記憶から。三角形を決定するためだけに最小限の頂点変換がすでに実行されているのは役に立ちません。その作業はすべて無駄になっています。
https://postimg.cc/svYwcZc8
これは Roya Frostlands のオープンワールド シナリオをキャプチャしたもので、拒否率は平均して約 50% になります。このような高い割合でも、 "安い" GPU にとって、拒否は負担になり始めます。
https://postimg.cc/Hc09tq0W
これを、拒否率がほぼゼロである Rainbow Six Siege Mobile と比較してください。基本的にはゴールドスタンダードです。オープンワールド ゲームの場合、ゼロに近い値を達成するのは困難ですが、それでも 50% は高すぎます。
https://postimg.cc/BXzH2ZWH
戦闘シナリオ (ロヤ フロストランド、ナイトメア ネスト、ズームしてフレームごとの情報を表示) では、拒否率が 99% に達することがあります。これは、本質的に、GPU に送信されたすべての三角形がすぐに破棄されたことを意味します。 GPU は、頂点のフェッチ、キャッシュ ルックアップ、および単一ピクセルをレンダリングしないジオメトリの部分的なシェーダー作業を実行する必要があります。これは CPU 側のカリングの失敗です。これらの三角形は、GPU に送信される前に破棄する必要があります。戦闘中のゲーム エンジンはここで意味のあるカリングを停止しているようで、GPU のハードウェア ビナーがここでガベージを分類することを強制されています。他のゲームではこの数値が低いことを考慮すると (確かに戦闘中は 99% ではなく、通常は 50%)、Kuro は間違いなくこの問題に取り組むことができます。
2. テクスチャキャッシュの効率
シェーダがテクスチャをサンプリングする必要があるたびに、まず小さい高速オンチップ キャッシュ (L1) をチェックし、次に大きくて低速なオンチップ キャッシュ (L2) をチェックします。
https://postimg.cc/k67fLMgf
WuWa の L1 テクスチャ キャッシュ ミス率は、時には 70 ～ 100% の範囲になります。最悪の場合、すべてのテクスチャ ルックアップで最速のキャッシュが完全に失われます。次は何でしょうか？ L2 ミス率は約 45% です。これは、GPU が頻繁に両方のキャッシュを通過し、テクスチャ データをメイン メモリに保存する必要があることを意味します。この要因により、テクスチャ ストール レートのメトリクスが増大します。これにより、GPU はテクスチャの到着を待機するだけになり、パフォーマンスが低下し、電力効率が悪化します。この結果は予想されています。前に見たように、描画呼び出しが無関係なテクスチャ間を間引きすることなくジャンプするため、L1 キャッシュは常に追い出され、満たされます (おそらく、同様のものをまとめてバッチ処理することさえないのでしょうか?)。
https://postimg.cc/4Y7fhsZV
さらに驚くべきことに、異方性フィルタリングは完全に存在せず、0% のままです。ここでどういうわけか測定できないだけなのかどうかはわかりません。
3. オープンワールド vs コンバットコントラスト
これが最も顕著な違いです。オープンワールド探索では:
- GPU 周波数: かなり低中層
- GPU使用率: 50%~ 以下
- フレームレート: 60FPS ロック
活発な戦闘中 (悪夢の巣):
- GPU周波数：最大/ほぼ最大
- GPU 使用率: 100%~ またはそれに近い
- フレームレート: 50< FPS (多少の低下はあるが、場合によっては 30 秒または 40 秒にまで低下する)
これは大部分が、過去に議論された問題の結果です。 L1/L2 ミスが増加し、失速が増加し、すべてが破棄され、消費電力が急増します。確かに、戦闘には通常、影響があり、さらに多くのことが要求されます。しかし、仕事のほとんどが実際に仕事が到着するのを待って停滞していたり、作業した仕事を単に破棄している場合、価値のあることを何もしないことで熱とパワーが追加されます。
https://postimg.cc/jL69g1X1
この結果がこの画像に表れており、GPU はオープンワールドであっても基本的にフレーム間で休息をとらず、グラフにズームインしても、フレーム間に呼吸する瞬間がほとんどありません。これは 8 エリートであることを忘れないでください。最速のモバイル チップの 1 つであり、低予算のものでは、GPU の呼吸が 0 になる可能性が高く、この問題はさらに悪化するでしょう。
4. シェーダの精度
シェーダーは、照明、色、視覚効果を計算するために GPU 上で実行されるプログラムです。内部の計算がどれだけ正確である必要があるかは、GPU がそれらを処理できる速度に直接影響します。WuWa は全体的に不必要に高価な計算を使用しているようです。
GPU 上のすべてのフラグメント シェーダーは、全精度 (FP32) または半精度 (FP16) で演算を実行します。特に Adreno では、FP16 は FP32 の 2 倍の速度で実行され、カラー ブレンディング、照明計算、およびほとんどのマテリアル計算に推奨されるパスです。トレースを見ると、Fragment ALU Full は一貫して約 4x Fragment ALU Half で実行されています。つまり、WuWa のシェーダーは主に半精度でも問題なく動作する完全精度の計算を行っています。これにより、Adreno の ALU スループットの半分がテーブルに残され、視覚的なメリットは得られません。オープンワールドでは、フラグメントあたり約 200 ～ 300 の ALU 命令のコストがかかります。これは複雑な PBR ゲームでは通常の範囲内であるため、管理可能です。しかし、戦闘中、VFX、パーティクル、およびオーバーラップするアルファ効果が積み重なると、GPU は同じ画面ピクセルを複数回シェーディングすることを強制されます (オーバードロー)。すでに最適化されていない FP32 ベースラインから開始しており、その重い計算がピクセルごとに 4 ～ 5 回実行されています。肥大化したシェーダーと緻密な VFX レイヤの組み合わせも、オープンワールドではそこまでひどくないのに、戦闘では GPU が 100% に達する理由の 1 つです。
5. 頂点フェッチ ストール
テクスチャ キャッシュの問題とは別に、頂点データ自体が非効率的にフェッチされています。頂点フェッチのストール率は約 40 ～ 45% にとどまっています。これは、頂点処理時間のほぼ半分が実際に作業を行うのではなく、データの待機に費やされていることを意味します。
https://postimg.cc/RNR3SMGB
これは重要です。なぜなら、些細な拒否が発生する前でさえ、GPU は頂点位置を待ってすでに停止しているからです。 ニーズ 拒否チェックを実行します。テクスチャ ミスと組み合わせると、GPU は 2 方向からのデータを同時に待機します。
6. アイロニー
これは、世界で最も高性能なモバイル GPU の 1 つです。それにもかかわらず、メモリ帯域幅のオーバーヘッドはかなり堅実です。オープンワールド WuWa は、たとえ問題があっても、単純に総当たりで突破して十分に実行できるため、要求が十分ではありません。戦闘中とはいえ、問題は複雑化する。高い拒否率、キャッシュのスラッシング、オーバードロー、頂点のストールなど、すべてが積み重なって発生します。突然、GPU の微風が完全に最大化されて息苦しくなり始めます。
このハードウェアで適切に最適化されたレンダラーであれば、オーバーワールドでは簡単に 120 fps に達する可能性が高く、戦闘では 60 fps は問題になりません。個人的には、60 を超える FPS はあまり気にしないので、代わりにビジュアルを改善するために使用できます (PC では中程度でも、すぐに遅れてしまう可能性があります)。ボリューメトリック ライティングの改善など、オプションのグラフィック設定として予算に合うかもしれません。残りの人々はより良い効率を享受できます。使用できない、またはひどいフレーム レートを持っている人は、今すぐプレイ可能なフレーム レートに達する可能性があるため、ローエンド ハードウェアのメリットが最も大きくなります。その天井は、WuWa が現在押し上げている地点をはるかに上回っています。
7. クロが直せるところ
これらはいずれも、新しいエンジンを必要とする基本的なアーキテクチャ上の問題ではありません。 "アンリアル エンジンが悪い"。これらは最適化の選択肢です。
- CPU側のカリング 特に戦闘中に苦戦していると思われる戦闘パーティクルやシャドウ パスの場合、些細な拒否を排除するために GPU の送信前に実行されます。
- マテリアルとテクスチャセットによるドローコールのソート 明らかなカリングの問題とは別に、キャッシュの一貫性を向上させ、L1/L2 ミスを削減します。
- 異方性フィルタリングを有効にする (Perfetto が正常に読み取って、実際に欠落していると仮定します) これは、8x/16x であっても、GPU にとっては本質的に無料です。
- パーティクル システム カリングの改善、戦闘 VFX エミッターがジオメトリをパスに送信し、すぐに拒否されることが、99% の戦闘の些細な拒否率の主な原因です。
- テクスチャストリーミングの改善L1/L2 ミス率が高いということは、テクスチャが必要になる前に効率的にキャッシュにプリロードされていないことも示唆しています。より優れたストリーミング システムでは、カメラの方向とプレーヤーの動きに基づいて必要なテクスチャを予測し、リアクティブなミッドフレームをフェッチするのではなく、事前に高速なメモリにテクスチャをロードします。これは、移動に応じて表示されるテクスチャ セットが常に変化する可能性があるオープンワールド ゲームでは特に重要です。また、ハイエンドの携帯電話 (12GB/16GB Ram) であっても、利用可能なメモリ (ログの r.Streaming.PoolSize:400) をチェックしているにもかかわらず、ゲームは非常に小さなテクスチャ ストリーミング プールを維持します。これはかなり高く設定することができます。
終わりに
ゲームは最新の主力携帯電話でほとんど問題なく動作しますが、これはそうではありません。 "ウーワが壊れた" 役職。ただし、GPU の現在の使用方法とその能力との間のギャップは大きく、測定可能です。私は理論的な懸念を提案しているわけではありません。それらはシステム トレースから直接収集されたデータの一部です。また、ローエンドのハードウェアがどの程度のメリットを得られるかを考慮すると、その関連性は大幅に高まります。メモリ帯域幅がはるかに大きなボトルネックとなり、途切れが発生します。
さらに付け加えておきたいのですが、このゲームには CPU 側でももっと良いコードがあったのではないかと感じています。時々、動くことすらできないカーテンや壁にぶつかって FPS が半分になったり、アカデミーで自転車を使っているだけでなぜかフレームが半分に落ちたりすることがあります。これらは修正可能な問題であると確信しています。
もちろん、PC 側にも同様の最適化の問題がある可能性がありますが、私は個人的にそのプラットフォームで主にプレイしません。ただし、この投稿は誰かが同様の分析を行うよう促す可能性があるため、投稿があれば喜んで読みます。
by xLOCKnLOAD