M3とA17 Proの新しいMetalプロファイリングツール

こんにちは 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を使用すると 最高のレイトレーシング パフォーマンスが得られます

ご視聴ありがとうございました

（音声なし）