WWDC Quick Look 💓 By SwiftGGTeam
Gain insights into your Metal app with Xcode 12

Gain insights into your Metal app with Xcode 12

元の動画を見る

ハイライト

Xcode 12 では、サマリー、インサイト、シェーダー タイムライン、およびパフォーマンス リミッター トラックが Metal Debugger および Instruments に追加され、開発者が単一フレーム キャプチャから帯域幅の無駄、冗長パス、シェーダー実行ホットスポットを検出できるようになります。

主要内容

Complex Metal アプリでは、1 か所だけで問題が発生することはほとんどありません。フレームには、数十のレンダリング コマンド エンコーダ、数千の描画呼び出し、および複数の中間テクスチャが含まれる場合があります。画像は正常に表示される可能性がありますが、GPU は冗長なストア アクション、深度パスの繰り返し、またはシェーダー ホットスポットで時間を無駄にしている可能性があります。

以前は、この種の問題をトラブルシューティングするには、開発者はまず Apple GPU のアーキテクチャを理解し、次にコマンド バッファ、エンコーダ、カウンタ、テクスチャ割り当てから手がかりを探す必要がありました。初心者によくあるジレンマは、アプリが GPU に依存していることはすでに知っていますが、最初のステップがメモリ、帯域幅、シェーダー、またはレンダー パスの依存関係を確認することなのかがわからないということです。

このセッションでは、Xcode 12 Metal ツールチェーンをより明確なパスに置きます。 Metal Debugger は単一フレーム分析を担当します。最初にフレームをキャプチャし、次に概要とインサイトを使用してエントリを見つけます。 Metal System Trace は、一定期間にわたる実行ステータスを管理します。タイムラインを使用して、途切れ、フレーム落ち、メモリ リーク、および熱状態を観察します。

Apple は、Larian Studios の Divinity: Original Sin 2 の iPad バージョンを例として使用しています。このフレームには 4 つのコマンド バッファ、53 のレンダリング コマンド エンコーダ、約 1000 の描画呼び出しがあり、レンダリング時間は約 26 ミリ秒です。 Xcode の Insights は、2 つの実用的な問題を指摘しました。1 つの深度/ステンシル リソースはストアに保存された後に使用されず、もう 1 つの深度プリパスは Apple GPU で削除される可能性があります。

詳細

概要ビュー: 単一フレームの概要から始めます

(01:22) Metal Debugger への入り口はフレーム キャプチャです。開発者はまず、Xcode スキームで GPU フレーム キャプチャを有効にし、Metal アプリを実行して、分析する画面上のデバッグ バーにあるカメラ ボタンをクリックします。

Xcode 12 の新しい概要ビューでは、エンコーダーの概要、パフォーマンス数値、メモリ使用量が同じページに表示されます。ページ上の分析情報により、メモリ使用量、帯域幅、パフォーマンス、または Metal API の使用量に影響を与える問題が発生します。各インサイトには、問題の説明、修正のヒント、関連ドキュメントへのリンクが含まれています。

キーポイント:

  • フレーム キャプチャにより、開発者は繰り返し検査できる単一フレームのスナップショットを取得できます。
  • サマリー ビューでは、概要、パフォーマンス、メモリ、インサイトが 1 か所にまとめられ、複数のパネル間の検索にかかる時間が短縮されます。
  • Insights の価値は、質問から依存関係ビューアー、メモリ ビューアー、またはその他の対応するツールに直接ジャンプできることです。

依存関係ビューア: 依存関係行を使用して帯域幅の無駄を判断する

(02:23) 依存関係ビューアーは、概要ビューの依存関係の表示から、またはナビゲーターのコマンド バッファーまたはエンコーダーから入力できます。すべての GPU パスの鳥瞰図が得られ、ロード/ストア アクションや帯域幅の問題を確認するのに適しています。

(10:37) サンプル プロジェクトでは、Insights は、エンコーダーがその後使用されないリソースを保存していることを通知します。スピーカーが依存関係ビューアにジャンプした後、デプス テクスチャとステンシル テクスチャが両方とも Store に設定されていることがわかりますが、これらのテクスチャから後続のレンダリング コマンド エンコーダへの行がありません。したがって、Xcode ではストア アクションを次のように変更することをお勧めします。Don't Care、約 11MB のメモリ帯域幅を節約できます。

キーポイント:

  • Store添付ファイルの結果はレンダー パスの終了後に書き戻され、そのコストはメモリ帯域幅です。
  • 送信依存関係はありません。これは、このフレームの後にこれらの深度/ステンシル結果を読み取るエンコーダーがないことを示します。
  • Don't Care使用されなくなったアタッチメントに適しています。ここでの判断は、Dependency Viewer のリソースの依存関係に基づいて行われます。

シェーダー プロファイラーとシェーダー デバッガー: シェーダーの問題をソース コード行に落とし込みます。

(03:34) シェーダーのパフォーマンスの問題のために、Xcode はシェーダー プロファイラーを提供します。開発者は「パイプライン状態ごとにフレームを表示」に切り替えてレンダー パイプラインを選択すると、Apple GPU 上のシェーダー ソース コードの行ごとのパフォーマンスの内訳を確認できます。プロファイラは、シェーダ ソースの直接編集やパフォーマンスの変化の観察もサポートしています。

(04:04) シェーダー結果エラーのために、Xcode はシェーダー デバッガーを提供します。入り口はデバッグバーのデバッグボタンです。開発者は、フラグメント シェーダーをデバッグするためにピクセルを選択し、頂点シェーダーをデバッグするためにジオメトリを選択し、コンピューティング シェーダーをデバッグするためにスレッドを選択できます。

シェーダー デバッガーは、複数のスレッドにわたる変数のステータスを表示し、シェーダーの実行全体を通じて値を表示できるようにします。従来の CPU デバッガは、「ステップ オーバー ステップ」の問題を抱えがちです。ここでは、実行中の変数値がデバッグ ビューに一度保持されているため、繰り返しステップ オーバーまたはステップ インする必要はありません。講演者が挙げた例は、ループの 28 回目の反復のステータスを直接見ることでした。

キーポイント:

  • Shader Profiler はパフォーマンス指向であり、シェーダー ソース コード ライン内のホット スポットを特定します。
  • シェーダー デバッガーは、ピクセル、ジオメトリ、または計算スレッドの変数状態を正確に拡張します。
  • シェーダ ソースを直接編集できるため、デバッグ段階での仮定を迅速に検証できます。

メモリ ビューア: リソースのプロパティと使用状況を確認する

(05:24) Memory Viewer は、Metal Debugger でメモリ使用量を確認するための入り口です。最新のレンダリング パイプラインにより、開発者はより明示的にメモリを制御できるようになりますが、その代償としてリソースの量とライフサイクルの管理がより困難になります。

Memory Viewer は、アプリ内のリソースとプロパティを一覧表示し、揮発性、リソース タイプ、アクセス、およびそれらが使用されているかどうかによるフィルター処理をサポートします。このビューは、どのリソースがメモリを占有しているのか、どのリソースが現在のフレームで実際には使用されていないのかという 2 つの質問に答えるのに適しています。

キーポイント:

  • リソースの内訳は、開発​​者がタイプおよびアクセス方法ごとにメモリ使用量を確認するのに役立ちます。
  • 「使用済みかどうか」フィルタリングは、現在のフレームに参加していないリソースをクリーンアップするのに適しています。
  • メモリ ビューアは概要ビューのメモリ領域に接続されており、概要からリソース レベルの検査にジャンプできます。

Metal System Trace: ラグをタイムラインに戻す

(06:27) Metal Debugger は 1 つのフレームを調べ、Metal System Trace は一定期間を調べます。これは Instruments のテンプレートであり、スタッター、フレーム落ち、メモリ リークなどの時間関連の問題を特定するのに適しています。ゲーム テンプレートには、ゲーム分析に適したトラックのセットも提供されます。

(06:50) エンコーダー タイムラインは、GPU トラックの下にあるコマンド バッファーのタイムラインをフレームごとに色分けして表示します。開発者は、エンコーダー間にオーバーラップがあるかどうか、GPU にアイドル状態のバブルがあるかどうかを確認し、GPU ステータスを他のシステム トラックに関連付けることができます。講演者が挙げた例は熱状態です。エンコーダーの速度が低下したときにデバイスがすでに危険な状態にある場合、アプリはデバイスを冷却するために作業負荷を軽減する必要がある可能性があります。

(07:25) シェーダー タイムラインは Xcode 12 の新しいトラックであり、メタル アプリケーションの記録オプションで有効にする必要があります。コマンド エンコーダーの実行中にサンプリングされたシェーダーが表示されます。サンプル数とおおよその GPU 時間が下の表に示されています。

(07:58)パフォーマンス リミッター トラックは、GPU カウンター セットのメタル アプリケーション記録オプションでも有効になります。リミッター値が時間の経過とともにどのように変化するかを示します。講演者は、2020 GPU カウンターが Apple 以外の GPU でも利用可能になることにも言及しました。

(08:32) メモリ割り当てトラックには、バッファとテクスチャの割り当てと解放のタイミングが表示されます。これは、メモリ リークのトラブルシューティングと全体のメモリ フットプリントの削減に適しています。

キーポイント:

  • エンコーダー タイムラインは、GPU が継続的に動作しているかどうか、またはアイドル バブルがあるかどうかを確認するのに適しています。
  • シェーダー タイムラインは、サンプリングされたシェーダーとおおよその GPU 時間が表示されるため、特定のエンコーダーに時間がかかる理由を説明するのに適しています。
  • パフォーマンス リミッター トラック タイムラインにリミッター値を配置して、フレームや熱状態などの信号との調整を容易にします。
  • メモリ割り当てトラックは、リソースのライフサイクルに注意を払い、単一フレームのメモリ ビューアでは表示できない時間の次元を補完します。

Insights を使用して 2 つの実際の問題を見つける

(09:45) 「Divinity: Original Sin 2」の例では、概要ビューは、このフレームに 4 つのコマンド バッファー、53 のレンダリング コマンド エンコーダー、約 1000 の描画コール、約 26 ミリ秒のレンダリング時間、約 450 万の頂点を処理していることを示しています。

(10:37) 最初の質問は、Bandwidth Insights からのものです。深度/ステンシルのアタッチメントは保存されますが、依存関係ビューアにはその後の使用が表示されません。ストアアクションを次のように変更しますDon't Care最終的に、ほぼ 11MB のメモリ帯域幅を節約できます。

(11:49) 2 番目の質問は、パフォーマンス カテゴリからのものです。 Xcode は、特定のレンダリング コマンド エンコーダーが不要な深度パスである可能性があることを通知します。このエンコーダは 1.71 ミリ秒の GPU 時間を要し、約 100 万の頂点を処理し、サムネイルではシーン全体が深度/ステンシル テクスチャに描画されていることがわかりました。次に、別のエンコーダーがシーン全体を描画します。

講演者は、これが従来のデプスプリパスによく似ていると判断しました。 Apple 以外の GPU では、このテクニックはオーバードローを減らすためによく使用されます。 Apple GPU のタイルベースの遅延レンダリング アーキテクチャは自動的に隠面の削除を実行するため、このパスを削除して 1.71 ミリ秒の GPU 時間を節約できます。

キーポイント:

  • Xcode は、単に「フレームが遅い」という結論を与えるのではなく、問題を特定のエンコーダ、リソース、ストア アクションに落とし込みます。
  • 依存関係ビューアーはリソースの依存関係を使用して、ストア アクションが必要かどうかを検証します。
  • サムネイル ポップオーバーは、深度パスがシーン全体を再描画しているかどうかを確認するのに役立ちます。
  • Apple GPU の隠面除去は、深度プリパス除去の基礎です。

重要ポイント

  1. フレームキャプチャヘルスチェックパネルを作成
  • やるべきこと: チーム内で固定プロセスを確立し、各メジャー バージョンの前に重要なシーンのフレームをキャプチャし、コマンド バッファーの数、エンコーダーの数、描画呼び出しの数、フレーム時間、およびインサイトを記録します。
  • 実行する価値がある理由: セッションの例では、概要ビューは 26 ミリ秒のフレーム、53 のレンダー エンコーダー、および 1000 近くの描画呼び出しを一目で公開します。
  • 開始方法: Xcode で GPU フレーム キャプチャから開始し、概要ビューで概要、パフォーマンス、メモリ、インサイトを確認します。
  1. 帯域幅回帰リストを作成します
  • 対処方法: 深度、ステンシル、カラー アタッチメントのストア アクションを具体的に確認して、ストア後に使用されないリソースを見つけます。
  • 実行する価値がある理由: この例では、深度/ステンシル ストア アクションを 1 つ変更するだけで、メモリ帯域幅を約 11MB 節約できます。
  • 開始方法: インサイトから依存関係ビューアーの対応するエンコーダーにジャンプし、リソースに送信依存関係があるかどうかを確認し、不要なストアを次のように変更します。Don't Care
  1. Apple GPU 専用レンダリング パスの監査を実行します
  • 内容: 他の GPU アーキテクチャから継承された深度プリパス、オーバードロー回避パス、および中間テクスチャ ライトバック戦略を確認します。
  • 実行する価値がある理由: Apple GPU の隠面除去により、従来の深度プリパスの価値が失われます。この例では、パスを 1 つ削除することで GPU 時間を 1.71 ミリ秒節約できます。
  • 開始方法: Performance Insights を使用して高コストの深度パスを見つけ、サムネイル ポップオーバーと依存関係ビューアーを使用してシーン全体を再描画するかどうかを決定します。
  1. Caton アンケート テンプレートを作成する
  • 何をすべきか: プレイヤーが途切れやフレーム落ちに反応したときは、Instruments の Metal System Trace を使用して、単一のフレームだけを見るのではなく、プロセスのセグメントをキャプチャします。
  • 実行する価値がある理由: Metal System Trace は、エンコーダー タイムライン、熱状態、シェーダー タイムライン、パフォーマンス リミッター、およびメモリ割り当てを同じタイムラインに配置できます。
  • 開始方法: ゲーム テンプレートを使用してリプレイ シーンを記録し、まず GPU トラックにアイドル状態のバブルがあるかどうかを確認してから、シェーダー タイムラインとパフォーマンス リミッター トラックを開きます。
  1. シェーダ ホットスポット修復ループを作成します
  • 何をすべきか: シェーダのパフォーマンスの問題を 2 つの問題に分割します。「どのソース コード行が遅いか」と「どの変数ステータスが間違っているか」です。
  • 実行する価値がある理由: シェーダー プロファイラーは行ごとのパフォーマンスの内訳を示し、シェーダー デバッガーは複数のスレッドおよび実行プロセス全体にわたる変数値を表示できます。
  • 開始方法: フレーム キャプチャで、パイプライン状態ごとにフレームを表示に切り替え、レンダー パイプラインを選択します。パフォーマンスの問題についてはシェーダー プロファイラーに移動し、エラー結果についてはシェーダー デバッガーに移動してください。

関連セッション

コメント

GitHub Issues · utterances