Optimize Metal Performance for Apple silicon Macs

ハイライト

Apple は、Apple シリコン Mac 上の Metal のパフォーマンス調整パスについて説明しています。レンダリングパスの依存関係と帯域幅を削減し、タイルシェーダを使用してオンチップデータを保持し、Apple シェーダコア機能に従ってシェーダを書き換えます。

主要内容

多くの Mac グラフィックスアプリには、すでに完成度の高いレンダラーが備わっています。これらは何年も Intel または AMD GPU で実行されており、一般的な最適化はイミディエイトモードレンダリングを中心に展開されています。 Apple Silicon Mac に移行した後、アプリを最初に Rosetta で実行し、その後ネイティブバージョンに再コンパイルできますが、これは「実行」の問題のみを解決します。フレームレートと消費電力に実際に影響を与えるのは、レンダラが Apple GPU のタイルベース遅延レンダリング (TBDR、タイルベース遅延レンダリング) アーキテクチャを理解しているかどうかです。

TBDR の主な変更点はタイルメモリ (オンチップタイルメモリ) です。 Apple GPU は、まずレンダーパスの頂点を処理し、ジオメトリを画面タイルに分割し、次にチップ上の各タイルのフラグメント作業を完了します。ロードアクションとストアアクションは、添付ファイルがタイルメモリに出入りする方法を決定します。これまでは、複数のパスに分割し、中間結果を頻繁にクリアし、頻繁に保存することにより、システムメモリの帯域幅が直接圧迫されていました。

このセッションの説明は非常に明確です。最初に GPU タイムラインの穴を見つけ、次にレンダーパスによって引き起こされるロード/ストアを削減し、次に隠れたサーフェスの削除を使用して非効果的なシェーディングを削減し、最後にディファードシェーディング、ライトカリング、およびシェーダのデータタイプを Apple GPU に適した形状に変更します。

開発者にとって、焦点は API 名の置換ではありません。より実際的な作業は、ワークロードを再配置し、元々同じ論理パスに属していたレンダリングをマージし、中間のアタッチメントを選択することです。.memoryless次に、Metal System Trace、GPU フレームデバッガー、パイプライン統計を使用して結果を確認します。

詳細

1. 頂点、フラグメント、計算を可能な限りオーバーラップさせます

(04:17) Apple GPU には、頂点、フラグメント、および計算作業を処理するための独立したハードウェアチャネルがあります。データの依存関係がない場合、Metal はそれらを自動的にオーバーラップします。パフォーマンスの問題は、「共有リソースのように見えるが、実際のデータとは何の関係もない」誤った依存関係で発生することがよくあります。

(06:05) レンダーパス 0 によって書き込まれたリソースがレンダーパス 1 の頂点ステージによって読み取られる場合、Metal はリソースレベルで依存関係を確立します。 2 つのパスが同じリソースの異なる領域を使用している場合でも、スケジューラはデータが無関係であることを知る方法がありません。ソリューションには 2 種類あります。データを異なるリソースに分割します。または、リソースを追跡なしに設定し、開発者がメタルフェンスまたはイベントを使用して必要な同期を挿入できるようにします。

(07:23) もう 1 つの低コストの方法は、パスの並べ替えです。独立したコンピューティングパスまたはレンダーパスは、タイムラインの穴を埋めるためにできるだけ早くエンコードする必要があります。 Metal は独立したパスを再配置することがありますが、確認できる情報は限られており、明示的な再配置の方が信頼性が高くなります。

ここでの実行可能境界は次のとおりです。隣接するパスが同じ Metal リソースを共有しているが、無関係なデータの読み取りと書き込みを行う場合、それらは最初に異なるリソースに分割されます。分割できない場合は、リソースを未追跡としてマークし、Metal が依存関係を確立するためにリソース全体に依存しなくなります。次に、アプリケーションはメタルフェンスまたはイベントを使用して、本当に必要な同期を挿入します。

キーポイント:

誤った依存関係は、API が誤って書かれたものではなく、リソースレベルの追跡から発生します。
Metal は 2 つのパスが関連していないことを自動的に認識できるため、リソースを分割することが最も直接的な修正です。
追跡されていないリソースは自動依存関係を削除するため、開発者は実際のデータが依存するフェンスまたはイベントのみを使用する必要があります。
パスの並べ替えは、リソースの依存関係を修正した後に配置し、タイムラインの穴を独立したコンピューティング/レンダリングパスで埋める必要があります。

2. 並列レンダリングコマンドエンコーダーを使用して、論理的に同一のパスをマージします

(09:08) Apple GPU レンダーパスの添付ファイルはタイルストレージで処理されます。添付ファイルのロードとストアはそれぞれ、システムメモリ帯域幅を消費します。よくある問題は、CPU マルチスレッドエンコーディングのために、同じ G バッファの異なる部分を複数のコマンドバッファに分割することです。 GPU は複数のレンダーパスを認識するため、添付ファイルの同じバッチを繰り返しロード/保存します。

(10:49) Metal の並列レンダーコマンドエンコーダーは、このシナリオを解決します。CPU は引き続きマルチスレッドでエンコードでき、GPU 側は依然としてレンダーパスです。

// Encoding with parallel render commands

let parallelDescriptor = MTLRenderPassDescriptor()
// … setup render pass as usual …

let parallelEncoder = commandBuffer.makeParallelRenderCommandEncoder(descriptor:parallelDescriptor)

let subEncoder0 = parallelEncoder.makeRenderCommandEncoder()
let subEncoder1 = parallelEncoder.makeRenderCommandEncoder()

let syncPoint = DispatchGroup()
DispatchQueue.global(qos: .userInteractive).async(group: syncPoint) {
    /* … encode with subEncoder0 … */ }
DispatchQueue.global(qos: .userInteractive).async(group: syncPoint) {
    /* … encode with subEncoder1 … */ }

syncPoint.wait()
parallelEncoder.end()

キーポイント:

MTLRenderPassDescriptor()通常のレンダーパスと同じアタッチメント構成を使用し、すべてのサブエンコーダーがこの構成を共有します。
makeParallelRenderCommandEncoder並列エンコーダーを作成すると、Metal はサブエンコーダーを単一のレンダーパスに合成して実行します。
makeRenderCommandEncoder()作成順序によってサブエンコーダコマンドの実行順序が決まるため、想定される順序で最初に作成してください。
二DispatchQueue.globalこのブロックはエンコーディングをさまざまなワーカースレッドに分散し、CPU の並列性を維持します。
syncPoint.wait()電話をかける前にすべてのサブタスクが完了していることを確認してくださいparallelEncoder.end()そうでない場合、パラレルエンコーダーはまだコマンドストリームを完了していません。

3. 接続ピンポンと冗長ストアを削減する

(12:12) もう 1 つの帯域幅の罠は、ロード/ストアアクションが変更されたという理由だけでパスを破棄することです。たとえば、フォワードレンダラーは最初に不透明を描画し、次に半透明を描画します。添付ファイルのコレクションが同じ場合、2 つの描画を同じパスで組み合わせることができ、色は最後に 1 回だけ保存されます。深度アタッチメントがパスの外で使用されなくなった場合は、ストアアクションを次のように設定する必要があります。.dontCare、テクスチャを次のように設定することもできます。.memoryless。

(13:29) アタッチメントのピンポンはさらに微妙です。たとえば、各ライトは最初にスクリーン空間の減衰テクスチャを生成し、それをメインシーンに合成します。各ライトの 1 つのパスにより、メインシーンのアタッチメントが繰り返しロード/保存されます。 Metal はパスごとに最大 8 つのカラーアタッチメントをサポートし、メインシーンと減衰を同じパスに入れることができます。

// Multiple render target setup

let textureDescriptor = MTLTextureDescriptor.texture2DDescriptor(…)
let lightingTexture = device.makeTexture(descriptor: textureDescriptor)

textureDescriptor.storageMode = .memoryless
let attenuationTexture = device.makeTexture(descriptor: textureDescriptor)

let renderPassDesc = MTLRenderPassDescriptor()
renderPassDesc.colorAttachments[0].texture      = lightingTexture
renderPassDesc.colorAttachments[0].loadAction   = .clear
renderPassDesc.colorAttachments[0].storeAction  = .store
renderPassDesc.colorAttachments[1].texture      = attenuationTexture
renderPassDesc.colorAttachments[1].loadAction   = .clear
renderPassDesc.colorAttachments[1].storeAction  = .dontCare

let renderPass = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDesc);

キーポイント:

lightingTextureこれはメインシーンの出力であり、パスが終了した後も必要となるため、storeActionはい.store。
textureDescriptor.storageMode = .memorylessパス内でのみ使用されるデータに対するシステムメモリバッキングの割り当てを避けるために、中間減衰テクスチャで使用されます。
colorAttachments[0]そしてcolorAttachments[1]レンダーパス記述子にも表示され、ピンポンが排除されます。
attenuationTextureのstoreActionはい.dontCareパス外では読み取られないため。
makeRenderCommandEncoderこの記述子を使用して単一パスを開始し、中間のロード/ストアを削減します。

(15:17) 画面のクリアも、実際に必要なレンダーパスに組み込む必要があります。別のクリアパスは添付ファイルをクリアするためにのみ使用され、追加のメモリトラフィックが生成されます。 MSAA の解決も同様です。サンプルデータは通常、パス内でのみ役立ち、前のパス内で解決される必要があります。マルチサンプル添付ファイルはメモリレスに設定できます。

4. 隠面の削除による無効なフラグメントの作業を減らす

(17:09) Apple GPU の隠面除去 (HSR、隠面除去) の目標は、可視ピクセルのみをシェーディングすることです。描画順序は効率に影響します。最初は不透明、次にフィードバック、最後に半透明になります。不透明描画の内部順序は通常、マテリアルシステムによって決まります。フィードバックと半透明は、独自の順序を考慮する必要があります。

(19:01) フラグメント関数がバッファまたは非レンダーパステクスチャを書き込むとき、Metal はメモリ書き込みの決定性を確保するためにデフォルトでこれらのフラグメントを実行します。ブロックされたフラグメントの書き込みが結果にとって意味がない場合は、初期フラグメントテスト属性をフラグメント関数に追加して、深さテストに失敗したフラグメントが実行されないようにすることができます。

(19:47)書き込みマスクも HSR 効率を低下させます。予約されたチャネルは基礎となるフラグメントから生成する必要があるため、追加のシェーディングが発生します。

let descriptor = MTLRenderPipelineDescriptor();
// ...
descriptor.colorAttachments[0].writeMask = .red | .green;

キーポイント:

MTLRenderPipelineDescriptorパイプラインのカラーアタッチメントの動作を制御します。
writeMask = .red | .greenフラグメント関数が赤と緑のチャネルのみを更新することを示します。
ブルーチャンネルとアルファチャンネルは古い値を保持するため、Apple GPU はこれらの値を取得するためにシェードアンダーラップフラグメントを必要とする場合があります。
本当にマスクを記述する必要がある場合は、それを使用できます。シェーダーで特定のアタッチメントだけが欠落している場合は、代わりにすべてのアタッチメントを入力する必要があります。

(21:15) G バッファの生成フェーズ中に添付ファイルが誤って見逃されることがよくあります。セッションによって与えられた修正は、特定のステージを 0 に初期化するだけでよい場合でも、すべてのレンダーパスアタッチメントに値を書き込むことです。

struct FragInput { ... };
struct FragOutput { float3 albedo; float3 normals; float3 lighting; };

fragment FragOutput GenerateGbuffer(
                         FragInput in [[stage_in]]) {
    FragOutput out;
    out.albedo = sampleAlbedo(in);
    out.normals = interpolateNormals(in);
    out.lighting = float3(0, 0, 0);
    return out;
}

キーポイント:

FragOutputアルベド、法線、ライティングの 3 つの出力を明示的にリストし、G バッファーアタッチメントと位置合わせします。
sampleAlbedo(in)マテリアルの色を書き込みます。
interpolateNormals(in)法線を書きます。
out.lighting = float3(0, 0, 0)未書き込みによる書き込みマスク動作を回避するために、ライティングアタッチメントをアクティブに初期化します。
return out完全な出力を一度に返すことで、HSR による不透明なフラグメントの処理が容易になります。

5. タイルシェーダを使用してチップ上でディファードシェーディングを維持する

(23:22) ディファードシェーディングは通常、最初に G バッファを生成し、次に G バッファを読み取ってライティングを計算します。従来の 2 パス書き込み方法では、アルベド、法線、ラフネス、およびその他のアタッチメントをシステムメモリに書き込み、すぐにそれらを読み取ります。 Apple GPU でのより良い方法は、プログラム可能なブレンディングとメモリレスレンダーターゲットを使用して、G バッファデータをタイルメモリに保持することです。

(28:29) レンダラーがレンダリングと計算 (タイルベースのライトカリングなど) を混合する場合、通常の計算エンコーダーはプロセスを複数のパスに分割します。 Apple GPU は、A11 Bionic 以降、タイルベースのコンピューティングディスパッチをサポートします。タイルシェーダは、レンダーコマンドエンコーダ内でタイルごとに実行でき、イメージブロック、スレッドグループメモリ、デバイスメモリを読み取ります。

(30:19) 次のレンダーパス記述子は、G バッファーをメモリレスに設定し、.dontCare保存、最終的な照明テクスチャのみを保存します。

let renderPassDesc = MTLRenderPassDescriptor()

renderPassDesc.tileWidth = 32
renderPassDesc.tileHeight = 32

renderPassDesc.threadgroupMemoryLength = MemoryLayout<LightInfo>.size * 8

renderPassDesc.colorAttachments[0].texture      = albedoMemorylessTexture
renderPassDesc.colorAttachments[0].loadAction   = .clear
renderPassDesc.colorAttachments[0].storeAction  = .dontCare
renderPassDesc.colorAttachments[1].texture      = normalsMemorylessTexture
renderPassDesc.colorAttachments[1].loadAction   = .clear
renderPassDesc.colorAttachments[1].storeAction  = .dontCare
renderPassDesc.colorAttachments[2].texture      = roughnessMemorylessTexture
renderPassDesc.colorAttachments[2].loadAction   = .clear
renderPassDesc.colorAttachments[2].storeAction  = .dontCare
renderPassDesc.colorAttachments[3].texture      = lightingTexture
renderPassDesc.colorAttachments[3].loadAction   = .clear
renderPassDesc.colorAttachments[3].storeAction  = .store

キーポイント:

tileWidthそしてtileHeightオンチップタイルサイズを定義します。この例では 32×32 を使用し、ライトカリングスキームに合わせます。
threadgroupMemoryLengthスレッドグループメモリを各タイルのライトリストに割り当てます。例は 8 です。LightInfo計算します。
アルベド、法線、ラフネスの 3 つのアタッチメントはメモリレステクスチャを使用し、パスの終了時にシステムメモリに書き戻されません。
これらの中間アタッチメントstoreAction全て.dontCare後続のステージで同じレンダーパス内でそれらが消費されるためです。
lightingTextureは最終出力なので、storeActionはい.store。

(32:20) タイルシェーダーはイメージブロックのレイアウトを再配置することもできます。この例では、イメージブロックをディファードシェーディングからマルチレイヤーアルファブレンディングに必要なレイアウトに変換し、ライティングと深度を新しい構造に保存します。

// Transitioning from deferred rendering to multi-layer alpha blending layout
struct DeferredShadingFragment {
    rgba8unorm<half4> albedo;
    rg11b10f<half3>   normal;
    float             depth;
    rgb9e5<half3>     lighting;
};
struct MultiLayerAlphaBlendFragments {
    half4 color_and_transmittence[3];
    float depth[3];
};
struct FragmentOutput {
    MultiLayerAlphaBlendFragments v [[imageblock_data]];
};
fragment FragmentOutput my_tile_shader(DeferredShadingFragment input [[imageblock_data]]) {
    FragmentOutput output;
    output.v.color_and_transmittence[0] = half4(input.lighting, 0.0h);
    output.v.depth[0]                   = input.depth;
    return output;
}

キーポイント:

DeferredShadingFragmentアルベド、法線、深度、照明などの古いイメージブロックレイアウトについて説明します。
MultiLayerAlphaBlendFragments新しいレイアウトを説明し、マルチレイヤー透明ブレンド用の色/透過率と深度の配列を準備します。
[[imageblock_data]]タイルメモリ内のデータの入出力をマークします。
my_tile_shader古いレイアウトから照明と深度を読み取り、新しいレイアウトのレイヤー 0 に書き込みます。
0.0h後のシェーダーコアの章の 16 ビットの推奨事項と一致するように、ハーフリテラルを使用します。

6. Apple シェーダコアに従ってシェーダデータアクセスを書き換えます

(34:11) Metal Shading Language のアドレス空間はパフォーマンスに影響します。device大量のデータの読み取りと書き込みに適しており、サイズは固定されておらず、各スレッドは異なる要素にアクセスします。constant読み取り専用でサイズが制限されており、同じ描画またはディスパッチで複数のスレッドによって繰り返し読み取られるデータに適しています。

(36:03) コンパイラが定数バッファを均一レジスタにプリロードしやすくするために、定数は次のようにして単一の構造体に編成する必要があります。constantアドレス空間は参照によって渡されます。配列のサイズはコンパイル時に最もよくわかります。このセクションの焦点は、新しいシェーダーエントリではなく、データ構成にあります。

キーポイント:

deviceアドレス空間は、サイズが固定されておらず、各スレッドが異なる要素を読み取るデータに適しています。
constantアドレス空間は、読み取り専用でサイズが制限され、複数のスレッドによって繰り返し読み取られるデータに適しています。
コンパイル時に定数の配列サイズがわかっている場合、コンパイラがデータをユニフォームレジスタにプリロードすることが容易になります。
定数データは単一の構造体として参照によって渡されます。これは、デバイスのアドレス空間から動的配列を読み取るよりも、この最適化目標との一貫性が高くなります。

(37:43) Apple GPU は 16 ビットタイプに最適化されています。使用できますhalfそしてshortデフォルトを使用しないでくださいfloatそしてint。 16 ビットタイプでは、レジスタの負荷が軽減され、シェーダコアの占有率が向上し、多くの場合、ALU の使用率が向上します。

(40:04) 見落とされやすいメモリアクセスの問題が 3 つあります。動的インデックスを持つスタック割り当て配列を避けることです。コンパイラが符号なしのラッピングセマンティクスを保持する必要がないように、メモリインデックスには符号付き型を使用するようにしてください。構造体内で一緒に読み取られるフィールドは、できるだけ隣接するか、コンパイラのマージロードを支援するためにベクトル型に直接変更する必要があります。

重要ポイント

1. レンダーパス帯域幅監査パネルを作成する

やるべきこと: フレームごとのレンダーパスの数、各アタッチメントのロード/ストアアクション、およびメモリレスの使用状況をエンジンデバッグメニューにリストします。
実行する価値がある理由: セッションは、ロード/ストアトラフィックを Apple GPU の主要な帯域幅ソースとして定義します。パスの分割、独立したクリア、MSAA サンプルストアによりコストが増大します。
開始方法: フレームグラフまたはレンダーパス記述子からアタッチメント設定を収集し、.store、.load、非メモリレスの中間テクスチャを強調表示し、メタルシステムトレースを使用して検証します。

2. シングルパス Apple GPU パスを G-Buffer パイプラインに追加する

何をすべきか: Apple GPU 固有のパスを遅延レンダラーに追加し、G バッファ、ライトカリング、およびライティングをできるだけ 1 つのレンダーパスに組み込みます。
実行する価値がある理由: プログラマブルブレンディング、メモリレスレンダーターゲット、タイルシェーダにより、中間 G バッファをタイルメモリに保持し、システムメモリの読み取りと書き込みを削減できます。
開始方法: まず、アルベド、法線、ラフネスをメモリレスアタッチメントに変更し、次にタイルシェーダーを使用してレンダーコマンドエンコーダーでタイルごとのライトリストを構築し、最終的なライティングテクスチャのみを保存します。

3. HSR 対応の描画ソートチェッカーを作成する

何をすべきか: レンダラーのデバッグビルドで不透明、フィードバック、半透明描画をマークし、これらがこの順序で送信されているかどうかを確認します。
実行する価値がある理由: Apple GPU の隠面除去により、隠れたフラグメントのシェーディングを節約できます。間違った順序、意図しない書き込みマスク、フラグメントリソースの書き込みにより効率が低下します。
開始方法: ブレンディング、破棄、深度出力、マスクの書き込みなどのステータスをマテリアルまたはパイプラインのメタデータに記録します。不透明ステージでアタッチメントが欠落していることが判明すると、ゼロパディング出力が要求されます。

4. シェーダーアドレス空間と 16 ビットタイプの lint を追加します。

何をすべきか: メタルシェーダの静的チェックを追加します。プロンプトは次のように変更できます。constant読み取り専用データは次のように変更できます。half/shortのローカル計算、不足h接尾辞の半分リテラル。
価値がある理由: セッションでは、一定のプリロード、16 ビット ALU、およびより低いレジスタプレッシャーが Apple シェーダコアのパフォーマンスに影響を与えると指摘しています。
開始方法: まず、シェーダー内のバッファーパラメーター、配列サイズ、浮動リテラル、および符号なしループインデックスをスキャンし、候補ポイントを警告として出力し、次に GPU フレームデバッガーを使用してパイプライン統計を表示します。

5. Rosetta と移植された Mac ゲームのネイティブパフォーマンスを比較する

作業内容: 同じシーン内の、Rosetta、最適化されていないネイティブ、および最適化されたネイティブ Apple GPU の GPU タイムラインと帯域幅メトリクスを記録します。
実行する価値がある理由: セッションの冒頭では、Rosetta と整合性機能がパフォーマンスにコストをもたらすことを説明します。ネイティブコンパイル後も、パスとシェーダーを TBDR 用に調整する必要があります。
開始方法: 固定カメラパスでメタルシステムトレースをキャプチャし、パスマージ、メモリレス、HSR ソート、シェーダータイプの最適化を 1 つずつ適用し、データの各ステップを保持します。

Optimize Metal Performance for Apple silicon Macs

ハイライト

主要内容

詳細

1. 頂点、フラグメント、計算を可能な限りオーバーラップさせます

2. 並列レンダリングコマンドエンコーダーを使用して、論理的に同一のパスをマージします

3. 接続ピンポンと冗長ストアを削減する

4. 隠面の削除による無効なフラグメントの作業を減らす

5. タイルシェーダを使用してチップ上でディファードシェーディングを維持する

6. Apple シェーダコアに従ってシェーダデータアクセスを書き換えます

重要ポイント

1. レンダーパス帯域幅監査パネルを作成する

2. シングルパス Apple GPU パスを G-Buffer パイプラインに追加する

3. HSR 対応の描画ソートチェッカーを作成する

4. シェーダーアドレス空間と 16 ビットタイプの lint を追加します。

5. Rosetta と移植された Mac ゲームのネイティブパフォーマンスを比較する

関連セッション

コメント

ハイライト

主要内容

詳細

1. 頂点、フラグメント、計算を可能な限りオーバーラップさせます

2. 並列レンダリング コマンド エンコーダーを使用して、論理的に同一のパスをマージします

3. 接続ピンポンと冗長ストアを削減する

4. 隠面の削除による無効なフラグメントの作業を減らす

5. タイル シェーダを使用してチップ上でディファード シェーディングを維持する

6. Apple シェーダ コアに従ってシェーダ データ アクセスを書き換えます

重要ポイント

1. レンダーパス帯域幅監査パネルを作成する

2. シングルパス Apple GPU パスを G-Buffer パイプラインに追加する

3. HSR 対応の描画ソート チェッカーを作成する

4. シェーダー アドレス空間と 16 ビット タイプの lint を追加します。

5. Rosetta と移植された Mac ゲームのネイティブ パフォーマンスを比較する

関連セッション

コメント

2. 並列レンダリングコマンドエンコーダーを使用して、論理的に同一のパスをマージします

5. タイルシェーダを使用してチップ上でディファードシェーディングを維持する

6. Apple シェーダコアに従ってシェーダデータアクセスを書き換えます

3. HSR 対応の描画ソートチェッカーを作成する

4. シェーダーアドレス空間と 16 ビットタイプの lint を追加します。

5. Rosetta と移植された Mac ゲームのネイティブパフォーマンスを比較する