ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
M3とA17 Proの新しいMetalプロファイリングツール
Xcode 15の新しいプロファイリングツールを活用してApple family 9 GPUで最高のMetalパフォーマンスを実現する方法を紹介します。Metalコードのプロファイリングと最適化を行うにあたって、Shader Cost Graph、Performance Heat Maps、Shader Execution Historyの各ツールを使用する方法について説明します。新しいGPUカウンタを使用してGPU占有率とレイトレーシングのパフォーマンスを最適化する方法を確認しましょう。
リソース
関連ビデオ
Tech Talks
WWDC23
WWDC22
-
ダウンロード
こんにちは Ruiweiです Metalデベロッパツールの ソフトウェアエンジニアです 本日は同僚のIrfanと一緒に 最新のMetalプロファイリング ツールを紹介します
Apple family 9 GPU M3 A17 Proは まったく新しいシェーダコア アーキテクチャを備えています
これを機会に私たちは プロファイリングツールを作り変え 最先端の新しいワークフローを構築しました
この新しいアーキテクチャの 詳細については 「M3とA17 ProでのGPUの進化」を ご覧ください
この解説では まずXcode 15の 優れた新ツールを紹介します
次に 占有率管理は最高のパフォーマンスを 実現するために非常に 重要であることを踏まえ 新しい一連の パフォーマンスカウンタを使用して 占有率をプロファイリングする方法を Irfanが説明します
最後に この新しいアーキテクチャで レイトレーシングを プロファイリングする方法を説明します
まず新プロファイリングツールについて確認します
道路のレンダリングを 最新のGPUを使用するパイプラインで 処理します
レンダリングした画像は美しく見えますが パフォーマンスの問題に気が付きました
この種のアプリケーションで パフォーマンスの ボトルネックを解決するには 主に2つのアプローチがあります
1つは最もコストの高いシェーダを特定し そこでコストのかかる関数とコードが どれであるかを把握します
もう1つのアプローチとしては コストの高い オブジェクトまたは ピクセルを最初に見つけます シェーダを扱う場合 フラグメントの位置や スレッドIDに応じて シェーダの動作が異なる場合があります
M3とA17 Proの新しいプロファイリング アーキテクチャのおかげで Xcode 15には これらのタスクを 簡素化するための 新しいツールが複数含まれています ここで 新しいツールを 使用してワークロードの パフォーマンスの問題を 見つける方法を説明します
まず Shader Cost Graphを紹介します この新しいツールは 高コストのシェーダを見つけて 選別するのに役立ちます
これはXcode 15で プロファイリングしたばかりの ワークロードの GPUキャプチャです 「Performance」ビューに移動すると GPUタイムラインに ワークロードの実行カウンタと パフォーマンスカウンタが表示されています
Shader Cost Graphを表示するには 新しい「Shaders」タブに切り替えます
左側のパフォーマンスナビゲータには パスとパイプライン状態のリストが コスト順に表示されます
GBuffer Passは総コストの 約50%であり これは想定よりも大きな値です
調査のため GBuffer Passで使用される コストの高いパイプラインの 状態をまず調べます
ナビゲータでパイプライン 状態を選択すると Shader Cost Graphが表示されます
ランダムなパイプライン表示の場合 デフォルトで フラグメントシェーダが選択されます
Shader Cost Graphは大きく 2つの部分に分かれています 上にあるのはコストが高い シェーダ関数を 視覚化したフレームグラフです
グラフの下には 対応するシェーダの ソースコードが表示されます
今回初めてMetalシェーダ用フレームグラフを 導入しましたが 見事な出来です フレームグラフを使用すると フラグメントシェーダの 最もコストの高い関数を 簡単に特定できます グラフ内の関数を選択すると 該当するソースがソースエディタに表示されます
ソースコードの左側のサイドバーに パフォーマンス に関する注釈が表示され 各行のコストが示されます
これは画像内のすべての ピクセルに照明を適用する フルスクリーンシェーダです
左側サイドバーにある パフォーマンスに関する 注釈を使用すると 最もコストの高い シェーダソース行をすぐに特定できます
円グラフにカーソルを合わせると パフォーマンスの ポップオーバーが表示されます
ポップオーバーには GPUによって実行された 命令の正確な数や 様々な命令カテゴリのコストなど
その行の詳細な内訳が表示されます
これはフルスクリーンシェーダであるため フラグメントの場所に応じて 動作が変化する可能性があり 特定の領域やピクセルが 原因でパフォーマンスの ボトルネックが発生している 可能性があります 問題を完全に理解するには コストが高めのピクセルを 見つける必要があります これは次に紹介する新しいツール Performance Heat Mapsを 使用する絶好の機会です
Performance Heat Mapsではピクセルや 計算スレッド情報 パフォーマンスメトリックスを視覚化します マップはフラグメントの位置または GPUスレッドの計算スレッドIDを 使用して構築されます
GBuffer Passの様々なタイプの Performance Heat Mapsを 見てみましょう
まず Shader Execution Cost ヒートマップです コストは実行時間とGPU スレッドの遅延隠蔽を 確認して計算されます
画像の右半分のピクセルが 赤色で表示されており これらのピクセルの コストがより高いことを意味しています
次はThread Divergenceヒートマップです SIMDグループ内のGPUスレッドの 分岐の量を視覚化しています
スレッド間の制御フローの 違いにより分岐が増加します これは条件分岐により発生する可能性と ジオメトリの形状が 原因の非アクティブなスレッドにより 発生する可能性があります
Overdrawヒートマップは 複数のGPUスレッドによって レンダリングされた ピクセルを視覚化します
これは 1つ以上のレンダリング コマンドで有効になったブレンドによる ジオメトリの重なりが 原因である可能性があります GPUコマンドは必ず 不透明なオブジェクトが 最初にレンダリングされ 次に透明なオブジェクトが レンダリングされるように グループ化してください これによりApple GPUで最高の パフォーマンスが実現します
Instruction Countヒートマップは ピクセルや SIMDグループごとにGPU上で 実行された命令の数を 正確に表示します
そして最後にDraw IDヒートマップでは 様々なGPUコマンドを色分けします この場合 ワークロードの大半が 1つのコマンドで レンダリングされていることがわかります 透明な窓でのみ別のコマンドが 使用されています
ヒートマップの概要と見え方が わかったところで Xcode 15でヒートマップにアクセスする 方法を見てみましょう
Performance Heat Mapsに アクセスするには 上部バーにある「Heat Map」 タブをクリックします
デフォルトではShader Execution Costヒートマップと 最初のアタッチメントが表示されます
シーンの道路部分の実行コストが 特に高いことに注意してください 詳しく調べるためにヒートマップを 追加してみます
下部バーのプラスボタンをクリックすると ヒートマップのポップオーバーが 表示されます
これにより 様々な タイプのヒートマップを すばやく有効または無効にできます
Instruction CountヒートマップはGPUが 道路のピクセルに対してより多くの 命令を実行していることを 明確に示しており これが高コストの説明に なる可能性があります
ポインタをピクセルの上に移動すると コストのパーセンタイルや 命令の正確な数などの 詳細を確認できます
ヒートマップから これらのピクセルの コストが高い理由を十分に推測できます
さらに 別の新しいツールである Shader Execution Historyを使用して シェーダがこれらのピクセルを どのようにレンダリングするかを 正確に確認することもできます
Performance Heat Maps内の ピクセルをクリックすると 基になっているSIMD グループが選択されます
これにより ヒートマップの 下にSIMDグループの シェーダの実行履歴が表示されます
Shader Execution Historyは 2つの主要部分に分かれています 上部のタイムラインとその下の シェーダソースコードです
タイムラインは 選択したSIMDグループの 進行状況を 左から右に向かって示します 上から下に向かっては 実行の各時点におけるすべての シェーダ呼び出しスタックが表示されます
この強力な視覚化により SIMDグループが Apple GPUでどのように 実行されるかを初めて 正確に確認できるようになりました
タイムラインを確認すると 実行時間の大部分を費やしている シェーダ関数をすぐに特定できます また Metalデバッガはループを 自動的に検出するため 進行状況が理解しやすくなります
最もコストの高いシェーダ関数の下には 12回の繰り返しを含むループがあり SIMDグループの合計実行時間の 79%を占めます
各繰り返しの中でapplySpotlightが 呼び出されています 関数呼び出し内にさらにループがあります テクスチャのサンプリングです
これは不自然です 12個のスポットライトで 街路のピクセルを照らす 必要はありません
ワークロードをチェックした結果 スポットライトを複製しているという 設定ミスに気付きました 余分な照明を削除した後 GBuffer Passのパフォーマンスは 大幅に向上しました
まとめると Shader Execution Historyは SIMDグループがGPUで実行された 様子を視覚化します
これには スレッドの状態や 関数コールスタック ループが含まれます
これにより 以前はできなかった シェーダ実行に関する詳細な 理解が可能になります
以上がM3とA17 Proで利用できる Xcode 15の新しい プロファイリングツールです これらのツールをご活用ください
続いて Irfanが プロファイリングの占有率について説明します
Ruiwei ありがとうございます M3とA17 ProのGPU用の 新しいツールとワークフローについて よくわかりました こんにちは Irfanです 最初に 新しいGPUアーキテクチャでの 占有率プロファイリングの仕組みと ハードウェアレイトレーシング ワークロードの プロファイリングに役立つ 新しいカウンタを紹介します
占有率をプロファイリングする 方法の説明の前に 「M3とA17 ProでのGPUの進化」を 視聴することを お勧めします そうすることで 以降の説明が より理解しやすくなります まず このセクションに関連する いくつかの重要な概念を説明します
Apple family 9 GPUにはM3と A17 Proが含まれます
両チップのGPUには様々な コンポーネントがあります 各シェーダコアには FP32やFP16 テクスチャリソースやバッファ リソースの読み取りと書き込みなど 様々なタイプの命令を実行するための 複数の実行パイプラインがあります
また シェーダプログラムで 使用する可能性のある 様々なタイプのデータを格納するための オンチップメモリも備えており 変数の値を保存するレジスタや 計算スレッドグループ全体で 共有されるデータや タイル全体で共有される カラーアタッチメントデータを保存する スレッドグループやタイルメモリ などがあります
これらのオンチップメモリは L1キャッシュを共有し GPUラストレベルキャッシュとデバイス メモリによってサポートされています
では GPUのパフォーマンスと 占有率が互いにどのような 関係にあるかを説明します
MetalシェーダがALU実行 パイプラインを使用して いくつかの数学演算を実行した後 バッファを読み取り その結果が直後に 使用されるとします
バッファにアクセスするには デバイスメモリにまでアクセスしなければ ならない場合があり 大きな 遅延が生じる可能性があります この間 SIMDグループは ほかの操作を実行できず ALUパイプラインは使用されません
これを緩和するために シェーダコアは 別のSIMDグループの 命令を実行でき このSIMDグループには独自の ALU命令が含まれる場合があります
これによりALUが使用 されない時間を短縮し SIMDグループを 並列で実行できることで パフォーマンスが向上します
シェーダコアで実行する 追加のSIMDグループがある場合は これは何度も繰り返すことができ ALUやその他の実行パイプラインで 実行する命令が 不足することはありません
シェーダコア上で同時に 実行するSIMDグループの数を そのコアの占有率と呼びます 最適なパフォーマンスを実現するには シェーダコア上のALUが できる限り使用状態になるように 占有率を高める必要があります
次に Apple family 9 GPUでの 占有率管理の目的を簡単に説明します
レジスタ スレッドグループ タイルスタックなどの シェーダコアメモリタイプは L1キャッシュから動的に割り当てられ GPUラストレベルキャッシュと デバイスメモリによって サポートされています
各SIMDグループは様々なシェーダ プログラムオンチップメモリを 大量に使用する場合があります SIMDグループの数が増えると オンチップストレージで利用可能な メモリを超えるメモリを ワークロードが使用する状況に なることがあり 次のキャッシュレベルへの スピルを引き起こします
シェーダコアはメモリキャッシュの スラッシングを防ぐために スレッド占有率とキャッシュ使用率の バランスを調整します
これによりシェーダデータが チップ上に留まり 実行パイプラインが 使用状態に保たれ シェーダのパフォーマンスが 向上します
Xcode 15は 新しい一連の パフォーマンスカウンタを備え これはワークロードの占有率低下の 原因を簡単に特定して対処し 優れたパフォーマンスを 達成するのに役立ちます
次に 占有率を高めることで ワークロードのパフォーマンス目標を 達成するのに役立つ ワークフローを示します
最初に確認する必要があるのは Metalワークロードが GPU上でどのように実行されているかと 実行中の占有率は どのくらいかということです そのためにMetalデバッガを 使用する方法を説明します ここに表示されているのは GPUでのワークロードの実行状況です 「Timeline」タブを選択して確認できます
各シェーダステージのすべての ワークロードエンコーダの 継続時間が表示されています 各シェーダステージのセクションで シェーダパイプラインの実行を 確認することもできます
エンコーダセクションの下には カウンタセクションがあり 概要レベルでパフォーマンスの リミッタや使用率 占有率などの役立つ パフォーマンスカウンタを確認できます
ワークロードがGPUで 実行されている間 これらのカウンタの情報は 定期的に収集されます
この解説ではパフォーマンスの 使用率とリミッタに 頻繁に言及するので
その意味を簡単に説明します
ワークは ALUの算術命令や MMUのアドレス変換リクエストなど ハードウェアブロックで処理される アイテムの数です ストールは利用可能なアイテムが 下流ブロックによって 保留された回数です 例えば メモリ命令リクエストが キャッシュによって停止され 次のレベルのキャッシュまたは デバイスメモリから リクエストが戻ってくるのを待つ場合が ストールとしてカウントされます ハードウェアブロックの 使用率とリミッタを 計算する数式を次に示します 使用率はサンプル期間中に ハードウェアブロックによって 行われたワークをハードウェアブロックの ピーク処理率とサンプル期間の積に対する 割合として表したものです リミッタも同様に計算しますが サンプル期間内のワークと ストールの両方が含まれます
次に 低い占有率を選別する 方法を説明します
カウンタトラックを確認すると
合計占有率が低いように見えます 占有率が低い場合のほかのパフォーマンス リミッタも確認してみます
合計占有率は低いですが ALUサブユニットである FP16のパフォーマンスリミッタが
約100%であることがわかります この期間全体を通じてFP16が 使用状態であったことを意味します このシナリオでは 占有率を 高めようとしても 新しく追加したSIMDグループが 主にFP16ワークを実行する場合 パフォーマンスがまったく 改善されない可能性があります
シェーダ内のFP16命令を 減らすとシェーダ全体の パフォーマンスが向上する 可能性が高くなります
別のワークロードを示します 占有率とすべてのALUリミッタが 共に低いことがわかります つまり 占有率が高くないため ALUの使用率低下を回避できません 占有率の影響でALUユニットの 使用率が低下しているとしたら 実際にはALUを 使用中の状態に保つという 最適化の目標に反しています
占有率が低い理由を選別して 占有率を十分に高め 占有率ではなくALUまたは メモリ帯域幅によって ワークロードが制限される 状態にする方法を示します
Shader Launch Limiterカウンタは シェーダコアでスレッドを 起動するために実行されたワークと バックプレッシャによりスレッドを 起動できない場合のストールの 両方が対象です このカウンタの値が低い場合は ワークロードサイズが小さいために 十分なスレッドが 起動されていないことを示します 逆に 高い値はそうでない ことを示します
最初に 十分な数のシェーダスレッドが シェーダコアに起動されているか 確認するために 「Counters」トラック内の このカウンタ値を調べます ここで「Compute Shader Launch Limiter」がわずか0.07%である ことがわかります すでに説明したように カウンタ値が小さいことは このワークロードがGPUを 使い切るほど大きくないため シェーダコアの使用率が 低下していることを示します
次に 私がプロファイリングした 別のワークロードを見てみましょう
「Shader Launch Limiter」が 高いことがわかります これは 十分な数の スレッドが起動しているか またはスレッドの起動に必要なメモリ リソースをおそらく使い果たしたため バックプレッシャによって スレッドの起動が停止している ことを意味します
調査を続けるため 次に何を すべきかを検討しましょう
「Shader Launch Limiter」 カウンタが高い場合 占有率が低い理由は いくつかあります まず この期間に実行状態の 計算ディスパッチが スレッドグループメモリを 大量に使用しているかどうかを確認します 大量に使用している場合 シェーダコアは スレッドグループメモリを それ以上使用できないため 新しいスレッドの起動を停止し 占有率が低下します
これは別のより単純なワークロードを プロファイリングしたもので 1つの計算パスのみで構成されています GPUタイムラインでは 任意の時点で 実行されていたディスパッチを 確認できます GPUタイムラインで「Compute」 エンコーダを選択すると そのエンコーダのディスパッチごとに 設定されている スレッドグループメモリの 量を確認できます ディスパッチでのスレッド グループメモリの使用量は わずか2KBと少ないため スレッドグループメモリが シェーダの起動停止を引き起こす 可能性は排除できます シェーダコアでは占有率マネージャを 使用して最大占有率の目標を設定し スレッド使用率とキャッシュ スラッシングのバランスを 取ることができます
現在のワークロードについて GPUが占有率を制限しているかどうかを Occupancy Manager Target カウンタを使用して確認します
この制限はレジスタ スレッドグループ タイル スタックメモリを オンチップに維持するために行われます タイムラインカウンタトラックで 「Occupancy Manager Target」 カウンタを確認できます ご覧のとおり「Occupancy Manager Target」カウンタは 100%を下回っています これは占有率マネージャが GPUと連携して様々な シェーダデータメモリタイプを オンチップに維持していることを示します これを行わないと GPUへのスピル ラストレベルキャッシュへのスピル さらにはデバイスメモリ へのスピルが生じます
このフローチャートを使用すると 「Occupancy Manager Target」カウンタが 低い場合に低い占有率を 選別できます まずL1のエビクション発生率 カウンタを調べます これは どれだけのレジスタ スレッドグループ タイル スタックメモリが 次のレベルのキャッシュへスピルせずに オンチップに留まるかの目安になります この「L1 Eviction Rate」 カウンタトラックでは カウンタに大きなスパイクが見られます これは高負荷のシェーダコアメモリ アクセスによりL1キャッシュが スラッシングされ エビクションが 発生していることを示しています
ここで シェーダコアメモリのどれが エビクションの原因なのかを 特定する方法を説明します
L1を使用するどのシェーダコア オンチップメモリが エビクションの原因となっているのかを 特定するには どのメモリタイプが L1に最も頻繁にアクセスしているのかと どのメモリに最も大きな割合の キャッシュラインが割り当てられたのかを 確認する必要があります
GPUタイムラインでL1のロード帯域幅と ストア帯域幅のカウンタトラックを 調べると L1を使用する 様々なオンチップメモリの L1帯域幅を確認できます Imageblock L1の L1メモリストア帯域幅が 最も大きいことがわかります
同様にImageblock L1の L1ロード帯域幅が最も大きく L1エビクションのほとんどを 引き起こしています
L1 Residencyカウンタトラックには 様々なオンチップメモリ間の L1キャッシュ割り当ての 詳細が表示されるため L1での割り当てが最大である シェーダコアメモリを 確認できます
また Imageblock L1メモリは ワーキングセットサイズが最大であり L1のエビクション発生率が大きい 原因である可能性が高いと考えられます
この場合 最小のピクセル 形式を使用することで L1のエビクション発生率を 低減できます MSAAを使用していて ワークロードに非常に複雑な ジオメトリがある場合 サンプル数を減らすと L1のエビクション発生率を 低減できます
L1エビクションの原因となる アクセス頻度と オンチップメモリの割り当て サイズを減らした後 これらの変更で期待する 効果が得られたかを 確認する必要があります
メモリを最適化して再プロファイリング した後 ワークロードが ALUまたはメモリ帯域幅によって 制限されていないことを確認します まずはほかのリミッタをチェックします そうであれば ワークロードは 占有率によって 制限されていないので 低い占有率を選別する 必要はありません ワークロードがALUまたはメモリ 帯域幅によって制限されていなければ 占有率の値と Occupancy Manager Target カウンタを再度確認し L1のエビクション発生率が小さくなるまで このプロセスを繰り返します
ではL1のエビクション発生率が 低い場合です この場合 GPUラストレベルキャッシュか MMUのストールによって占有率 マネージャのターゲットが 高くなっていると考えられます これは デバイスがメモリアクセス ラストレベルキャッシュのスラッシング またはTLBミスの生成を行うときに 発生する可能性があります 各種のワークロードで これらのストールを 確認する方法を説明します GPUのラストレベルキャッシュの使用率は GPUが読み取りおよび書き込み リクエストを処理した時間を ピークラストレベルキャッシュ帯域幅の 割合として測定します ラストレベルキャッシュリミッタには キャッシュの使用時間と キャッシュスラッシングまたは メインメモリからのバックプレッシャが 原因でキャッシュが停止している 時間が含まれます GPUのラストレベルキャッシュリミッタが 使用率よりもはるかに高い場合は キャッシュスラッシングが原因で 頻繁に停止していることを示しています バッファサイズを減らすことで こうした停止を削減でき 空間的および時間的局所性が 改善されます
同様にMMUカウンタトラックで MMUのリミッタがMMUの 使用率よりもはるかに大きい場合 デバイスのバッファアクセスにより TLBミスが発生し MMUがスラッシングされます バッファへの不均一な メモリアクセスの削減が こうした停止を低減するのに 役立つ可能性があります
デバイスのメモリアクセスを最適化し ワークロードを更新したら 再度プロファイリングします
ほかのリミッタが高い場合 それらのリミッタの低減に注力します これ以上ワークロードは占有率に よって制限されないためです ほかのリミッタが低い場合は 前に示したように 低い占有率によってワークロードが 制限されなくなるまで 選別プロセスを繰り返します
これらの新しく追加された パフォーマンスカウンタを使用すると 命令実行パイプラインを 使用状態に保つことができ 優れたシェーダパフォーマンスが 得られます 次に レイトレーシングの プロファイリングに進みます Apple family 9 GPUの 新しいレイトレーシング ハードウェアアクセラレータを使用すると 本物のようなシーンをリアルタイムで レンダリングできます XcodeのMetalデバッガが レイトレーシングワークロードの パフォーマンス最適化に どう役立つかを説明します
私はこのアプリを活用して トラックをレンダリングしています レイトレーシングを使用して 素晴らしい反射をレンダリングしました 新しいハードウェアではすでに 驚くほど高速に レンダリングできますが さらに高速化できるかどうかに 興味があります
そこで 最適なレイトレーシング パフォーマンスを実現できるように XcodeにはAcceleration Structure Viewerに加えて 新しい一連のレイトレーシング カウンタが備わっています きっと気に入っていただけるでしょう Ruiweiが先ほど説明した Shader Cost Graphを使用して シェーダやカスタム交差関数を 分析することもできます まずはカウンタから始めましょう
レンダラのフレームをキャプチャし Performanceタイムラインを開きました Xcodeには新しいレイトレーシング グループが備わっています これには一連の 幅広いトラックが含まれ 新しいレイトレーシングハードウェアで ワークロードがどのように 実行されているかを 理解するのに役立ちます
それぞれを確認してみましょう
最初のトラックは光線占有率を示します このハードウェアは多数の光線を 同時に実行でき 光線占有率は アクティブ状態の割合を示します またスレッド占有率と同様に Apple family 9 GPUの シェーダコアは 光線占有率も自動的に最適化し アプリの最大限のパフォーマンスを 実現します
ワークロードの使用率は光線の数によって 低下することがないと仮定して 占有率マネージャのターゲットを 確認することから始めます
前と同じプロセスに従いますが L1 Residencyと帯域幅内の レイトレーシングスクラッチカテゴリに 特に注意してください
レイトレーシングユニットは L1のかなりの部分を スクラッチバッファとして使用します これはペイロードサイズを 最適化することで削減できます
再プロファイリングし 前のセクションで説明した 選別プロセスを繰り返します
次の一連のトラックはアクティブな光線が 実行している内容の割合を示しています これにより 改善すべき範囲を より深く理解できます 例えば この時点ではアクティブな光線の 75%がインスタンスの変換を 実行していました このシーンにはトラックの インスタンスが2つしかないので これはかなり高いと考えられます
ワークロードでこのような問題に 気付いた場合は シーンを調べてインスタンスの重複を 最小限にするとよいでしょう これについては 後でAcceleration Structure Viewerを使用して 詳しく説明します ここでは 先に進みましょう
最後に「Intersection Tests」トラックは 実行中のプリミティブの交差の 割合を示します
このレンダラでは ハードウェアが モーションなしで Opaque Triangle Testのみを 実行していることがわかります 最高のパフォーマンスを実現するには Opaque Triangle Testを最大化し アルファテストが必要なオブジェクトなど カスタム交差関数が必要な ジオメトリではカスタム交差関数 のみを使用してください
新しいレイトレーシングカウンタ については以上です これらはハードウェアがワークロードを どのように実行しているかを 理解するのに役立ち パフォーマンスの選別を始める 取り掛かりとして最適です
この場合 インスタンスの変換が 異常に高いことが わかりました これはシーンに 問題がある可能性を示します
インスタンスの重複などが考えられ シーンの問題を選別するには Acceleration Structure Viewerを 使用できます これについて説明します まず アクセラレーション構造を使用する ディスパッチを見つけましょう タイムラインでエンコーダをクリックし
ディスパッチを選択します
その後 インスタンス化された アクセラレーション構造を ダブルクリックします
これにより Acceleration Structure Viewerが開きます
左側にアクセラレーション構造の 詳細が表示され 右側にプレビューが表示されます
アクセラレーション構造の各要素を ハイライトすることもできます
ここでは変換を調べたいので 「Instance Traversals」ハイライト モードをオンにします ホットスポットが青色で表示されます プレビューを見ると予想していた 2つのインスタンスよりも 多くのインスタンスがあるように見えます この濃い青色の領域の上にマウスを移動して 光線がトラバースしているインスタンスの 数を正確に調べます 8です つまり 光線は最も近い 交差を見つけるまでに 8つのインスタンスを トラバースする必要があります これは2つをはるかに上回っています これが ほとんどのアクティブな光線が インスタンスの変換を実行していた 理由を示しています なぜこれほど多いのでしょうか
「Instances」ハイライト モードに切り替えましょう 各インスタンスに異なる色が付きます
なるほど トラックの部分ごとに インスタンスが異なるようです また それらは重なり合っています この場合 最高のパフォーマンスを 実現するには インスタンスを連結して単一の プリミティブアクセラレーション構造に 変換する必要があります ただし それが最も重要な変更では ないかもしれません このアクセラレーション構造の問題は アセットパイプラインの問題に起因する 可能性があります
そこで調査を行い 新しいトラックアセットに変更し
問題を解決しました
Instance Traversalsの大幅な 改善に注目してください
まとめです 新しいレイ トレーシングカウンタと Acceleration Structure Viewerの 両方を使用して Apple family 9 GPUの優れた レイトレーシング パフォーマンスを引き出すことができます
また レイトレーシングの ベストプラクティスにも 引き続き従う必要があります
ここに示したほかの解説で 詳しく学ぶことができます
本日説明した内容をすべてまとめます
Xcode 15にApple family 9 GPUで 利用できる最先端の 新しいGPUプロファイリング ツールが追加されました Shader Cost Graphを使用すると 高コストのシェーダを すぐに見つけて選別できます
Performance Heat Mapsを使用すると シェーダのコストが高い 原因となっている オブジェクトやピクセルを 正確に判断できます
Shader Execution History ツールを使用すると 実行時間の大部分を費やしている シェーダ関数を簡単に特定できます
Xcode 15に新しく追加された パフォーマンスカウンタを 使用して 占有率が低い原因を選別し 最高のパフォーマンスを実現できます
レイトレーシング用の新しい パフォーマンスカウンタに加えて Acceleration Structure Viewerを使用すると 最高のレイトレーシング パフォーマンスが得られます
ご視聴ありがとうございました
(音声なし)
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。