Metalのコンパイルワークフロー

Metalのコンパイルワークフロー

Metalシェーディング言語は強力なC++ベース言語で、柔軟なシェーダ開発パイプラインを維持しながら、Appで驚くべき効果をレンダリングすることができます。ダイナミックライブラリとファンクションポインタを使用して、レンダリングパイプラインをより簡単に構築・拡張する方法について確認します。また、バイナリ関数アーカイブ、関数リンキング、関数スティッチングを使用して、ランタイムでのシェーダのコンパイルを高速化する方法も紹介します。

リソース
関連ビデオ

WWDC23
- Macへのゲーム展開 Part 2：シェーダーをコンパイルする
- MetalでGPUレンダリングを最適化
WWDC22
- Metal 3で、GPUバイナリをターゲットにして最適化する
WWDC21
- Metalのデバッグ、プロファイリング、アセット作成ツール
WWDC20
- MetalでGPUバイナリを作成する
- Metal関数ポインタの紹介
ダウンロード

こんにちは Rini Patelです GPUソフトウェアエンジニアリング担当です今回は Metalの新しいシェーダコンパイルのワークフローを紹介します Metalシェーディング言語は C++ベースの言語でありそのコンパイルモデルは CPUのモデルに似ています GPUのワークロードが複雑化し Metalも最新ユースケースをサポートするため柔軟にパフォーマンスを上げましたシェーダをオーサリングする際によくある既存の課題はパイプライン間でのユーティリティコードの共有再コンパイルせずに実行時にシェーダの動作の変更 App起動間でコンパイルされた GPUバイナリを再利用することなどがあります簡単なシェーダのコードでシナリオを検討してみます
条件の結果に応じてfoo() またはbar()の結果を返すシンプルなフラグメントシェーダを用意しましたこの関数が複数パイプラインから呼び出される場合一度にコンパイルして各パイプラインにリンクする方法が考えられます
これらの関数の別の実装を実行時にリンクするか baz()の新しいケースステートメントを処理するためフラグメントシェーダを拡張する必要があるかもしれませんまたフラグメント関数から baz()ではなくbat()というユーザー提供の関数を呼び出したい場合もありますこのようにシェーダオーサリングパイプラインはさまざまな要件があり Metalはさまざまな実装をサポートするためにさまざまなAPIを提供しますそれぞれのアプローチはコンパイル時間とシェーダのパフォーマンスの間のトレードオフが異なりますパフォーマンスと柔軟性のバランスをとるのに役立つコンパイルワークフローについてお話しますレンダーパイプライン用のダイナミックライブラリとレンダーパイプライン用の関数ポインタを新たにサポートすることから始めます binaryArchive APIへの追加機能もお話しますそれからプライベートリンク機能を見ましょう最後にMetalで可視化された機能をスティッチングする全く新しい機能を紹介しますまずMetalのダイナミックライブラリ対応についてダイナミックライブラリは一般的なツールですユーティリティコードを独立したコンパイルユニットに区分けするための共有オブジェクトファイルですコンパイルされたシェーダコードを減らし複数のパイプライン間での再利用に役立ちますさらに GPUのバイナリコードを動的にリンクしたり読み込んだり共有することも可能です
昨年はコンピュートパイプラインのための動的言語を紹介しましたが Metalの動的ライブラリについて詳細は昨年のプレゼンテーション「MetalでGPUバイナリを作成する」をご覧ください今年レンダーパイプラインやタイルパイプラインにダイナミックライブラリを導入し全ワークロードでユーティリティライブラリを共有できるようになりましたダイナミックライブラリとは何かを理解したところで次はユースケースを紹介しましょうヘルパー関数は一般的なコンピュートやバーテックスフラグメントタイルシェーダでよく使用されますダイナミックライブラリを追加することで大量のユーティリティコードを管理し全ワークロードで共有できます実行時に使用されうるライブラリをコンパイル時の減速なしでプリコンパイルできますさらにパイプライン作成時に読み込むライブラリを変更するだけで実行時に関数を切り替えることもできますソースを提供しなくてもユーザーがシェーダコードを作成しパイプラインの一部としてロードすることも可能ですダイナミックライブラリをいつ使うかについて話しましたではどのように構築し扱うかを見ていきましょうフラグメントシェーダの例では関数foo()とbar()を呼び出しますがコンパイル時にはどちらも実装しませんこれらの関数の実装は Metalのライブラリにありレンダリングパイプラインを作成する際にリンクします使用する可能性のある機能ごとに別々のライブラリを用意することも可能ですでは Metalでダイナミックライブラリを構築する際のツールと柔軟性について説明しますまず MetalシェーダのソースをAIRにコンパイルします Metalツールチェーンを使うか newLibraryWithSource APIを使用したソースからのコンパイルかのいずれかで行います AIRにMetalシェーダをコンパイルしたら newDynamicLibrary APIでダイナミックライブラリを作成でき GPUのバイナリ形式で使用できます後から再利用したい場合はどうでしょう？ serializeToURL APIでダイナミックライブラリをディスクにシリアル化し newDynamicLibraryWithURL API を呼び出せば再利用できますダイナミックライブラリとフラグメントシェーダから関数を呼び出す例を見てみましょう関数foo()とbar()をextern キーワードで宣言しますが定義はしていませんフラグメントシェーダからこの関数を呼び出すだけです Metalライブラリを構築する際に extern関数の実装を提供することができますこれらの実装を実行時に別のものに置き換えることも可能だと覚えておいてくださいそのためにはダイナミックライブラリを適切なプリロードライブラリ配列に追加するだけです例ではフラグメントですが同様のプロパティがステージやパイプラインごとに用意されていますこの配列にライブラリが追加されたのと同じ順番でシンボルが解決されていきますこのワークフローは新しい実装を試すのに適していますダイナミックライブラリについては以上です Metalのダイナミックライブラリは macOS Monterey の Apple GPUファミリー７以上に対応しています他のGPUやほとんどのMacファミリー2 デバイスにも対応していますが Metalのデバイスダイナミックライブラリサポートを呼び出す必要があります iOS 15ではこの機能は Apple６以上の全デバイスで使えますレンダーやタイルパイプラインは Apple６をサポートする全デバイスで利用可能です
次に今年加わった関数ポインタの改良について説明します
関数ポインタはこれまで見たことのない関数を呼び出すことができるコードを参照する構成でコードの拡張性が高まりますコンピュートパイプラインの関数ポインタについては昨年のプレゼンテーション「Metal関数ポインタの紹介」を確認してください今年 Apple Siliconのタイルとレンダリングパイプラインに関数ポインタのサポートを拡大しますダイナミックライブラリ同様カスタマイズ可能なパイプラインを作ることができます関数ポインタを使えばパイプラインコンパイル時にはなかったコードをGPUパイプラインで呼び出すことができます関数ポインタテーブルでは異なる関数テーブルをバインドしたときや GPUパイプラインがインデックスを付けるとコードの動作が動的に変化しますまた関数ポインタを使ってコンパイル時と実行時のパフォーマンスのバランスを取ることもできます最速でコンパイルするために関数ポインタをGPUバイナリにプリコンパイルしてパイプラインで素早く対処できます一方実行時のパフォーマンスを向上させるためにはパイプラインがAIR表現の関数を参照するようにしてコンパイラが最大限の最適化を行えるようにしますコードで関数ポインタを設定する方法を見てみましょう３つに大きく分かれていますまず関数をインスタンス化しその関数でパイプラインを構成し最後に関数テーブルを作成します新しいレンダリングループの使用に多くのコードは不要ですではワンステップずつ見ていきましょうまず関数ディスクリプタを宣言し GPUバイナリバージョンをコンパイルするためにインスタンスを作成しますパイプライン作成を短縮できディスクリプタを宣言しバイナリにコンパイルするオプションの設定だけですこれでライブラリから Metal関数fooを作成すると GPUバックエンドコンパイラによってコンパイルされます次にレンダーパイプラインディスクリプタを設定しますまずパイプラインディスクリプタを介し頂点フラグメントタイルなど関数を使用するステージに追加します関数の追加は AIRかバイナリ形式で選択できます AIR関数を追加する際コンパイラが可視化された関数を静的にリンクするためバックエンドのコンパイラがコードを最適化できます一方バイナリ関数を追加すると外部でコンパイルされた関数がパイプラインから呼び出せる形でドライバに通知しますバイナリ関数を使用しパイプラインを作成する際呼び出しているコードが例示されているように複雑な呼び出しチェーンを持つ場合コンパイラが深さを決定する静的解析を行えないため必要な最大呼び出し時間を指定することが重要です実行される最大の深さをデフォルトとします正確でないとスタックオーバーフローが発生します逆に言えば深さを正しく指定すればより良いリソースコンセプションとパフォーマンスになりますディスクリプタの設定が完了したら関数ポインタを使えるパイプラインを作成できます次に可視化された関数テーブルを作成し APIの関数ハンドルを入力しますディスクリプタを使い可視化された関数テーブルを作成しレンダリングステージを指定しますそしてその関数を参照する関数ハンドルを作成します関数ハンドルとテーブルは特定のパイプラインと選択されたステージに固有のものですそして setFunction APIでハンドルを挿入できますではこの関数テーブルをどう使うか見てみましょうコマンドとコーディングの一環として可視化された関数テーブルを BufferIndexにバインドしシェーダ自体ではバッファバインディングとして visible_function_tableが渡され関数を呼び出せます関数ポインタを使うという単純なケースです関数ポインタを使用する場合後で追加関数にアクセスが必要か確認でパイプラインを作成することもあります同じディスクリプタから２つ目のパイプラインを作成して関数を追加し実現できたとしてもパイプラインのコンパイルが必要になりますこの処理を促進するために Metalで元のパイプラインを拡張する予定か指定することができますこれで既存のパイプラインから新しいパイプラインをより速く作成でき最初に作成されたすべての関数ポインタテーブルを使用することができますコードから行うには元のパイプライン作成の際に supportAddingBinary Functionsオプションを拡張したいステージに対し YESに設定しますその後拡張パイプラインを作成する必要があるときは RenderPipelineFunction Descriptorを作成しフラグメント長関数リストにバイナリ関数batを含めます最後にRenderPipeline1で追加のバイナリ関数を持つ新しいRenderPipelineState を呼び出し同一となるが追加の関数ポインタbatを含むRenderPipeline2を作成大体こんなところですここからは関数ポインタの使い方を紹介します Apple GPUファミリー６以上 macOS Big Sur iOS 14でサポートされています Macファミリーの２つのデバイスもサポートします Apple GPUファミリー６以上 Mac OS Monterey iOS 15のレンダーとタイルパイプラインの関数ポインタのサポートも拡張します
次にバイナリ関数のコンパイル時のオーバーヘッドの管理について紹介しますシェーダのコンパイルは時間がかかるためアプリへのオーバーヘッドを制御したい場合がありますそこでバイナリアーカイブを昨年Metalに追加しましたバイナリアーカイブはパイプラインのコンパイルされたバイナリバージョンをディスクに集め保存コンパイル時間と実行を節約メモリコストを削減できます可視化して保存する機能やインターセクション機能を追加しオーバーヘッドを削減できるようにしていますバイナリアーカイブへの格納と読み込み方法を見てみます addFunctionWithDescriptor を呼び引数に関数ディスクリプタとソースライブラリを渡しますバイナリ関数ポインタを読み込むにはbinaryArchivesの配列にBinaryArchiveを配置 Metalライブラリメソッド newFunctionWithDescriptor を呼び出しますアーカイブがコンパイルした関数ポインタを持っていれば再コンパイルすることなくすぐにそれが返されます newFunctionWithDescriptor がbinaryArchivesに対してどのように動作するかを示すルールを紹介しますまずリストからその関数のバイナリバージョンを探し見つかれば返され見つからなければ CompileToBinary オプションをチェックしバイナリコンパイルの要求がない場合 AIR関数を返します要求された場合パイプラインオプションに応じ FailOnBinaryArchiveMissは関数のバイナリを実行時にコンパイルするか nilを返します MTLBinaryArchiveをアプリに組み込むとGPUでコンパイルされたコードを同アーカイブに格納できますレンダリングタイルパイプライン関数ポインタなどアーカイブにパイプラインステートオブジェクトとバイナリ関数を登録後シリアル化できます GPUバイナリを収集保存して次のアプリ実行時にシェーダのコンパイルを高速化できます関数ポインタを使うパイプラインの使用では状態を表すオブジェクトをキャッシュしたい場合がありますですが様々な関数ポインタの組み合わせが可能なパイプラインがあるのになぜキャッシュを？例えばここではユーザ関数ポインタを除き同一の３つのパイプラインディスクリプタがありますそのためAIRの関数ポインタを使用している場合はパイプラインのすべての順列をキャッシュしますがバイナリ関数ポインタを使用する場合関数ポインタが追加されてもパイプラインのバイナリコードは変更なく単一のバリアントをキャッシュするだけですそのアーカイブを使ってパイプラインディスクリプタにどのバイナリ関数ポインタが使われているかに関係なく他のすべてのバリエーションを見つけることができます MetalではbinaryArchives の使用をお勧めしますパイプラインのコンパイルコストを抑えられます binaryArchivesのサポートは全てのデバイスで可能ですが BinaryArchiveに関数ポインタを追加するには関数ポインタの能力に依存しますさて今年の次の追加機能であるプライベートリンク機能について簡単に説明しますダイナミックライブラリと関数ポインタがシェーダ開発パイプラインに柔軟性をもたらすことを説明してきましたがパフォーマンス上の理由から外部関数を静的にリンクする場合もあります昨年 AIRの関数を静的にリンクする機能を持つ linkedFunctions APIを追加しましたしかしこれには関数ポインタのサポートが必要でこれらは関数テーブルで使用できるからです今年はprivateFunctionsを導入します functionsも privateFunctionsも AIRレベルで静的にリンクされていますが privateなので関数ポインタに対し関数処理できずコンパイラはシェーダコードを最適化できますではどこで入手できるのでしょうか？この機能はAIRレベルのコードで動作するため macOS MontereyとiOS 15の全デバイスで利用できますさて最後に関数のスティッチングについてお話しましょうダイナミックコンテンツが必要なアプリもあります例えばユーザーの要望でグラフィック効果をカスタマイズすることなどですまたは入力データに基づきカーネルを複雑に計算などこれを処理するには関数のスティッチングが有効です関数のスティッチング以前は Metalのソース文字列を生成するしか方法がありませんでしたまた Metalから AIRへの変換は実行時に行われこれはコストのかかる作業ですでは関数のスティッチングの仕組みを見てみましょう計算グラフやプリコンパイルされた関数から実行時に関数を生成する仕組みを提供します計算グラフは有向非巡回グラフですまたグラフには生成された関数の引数を表す入力ノードと関数の呼び出しを表す関数ノードの２種類のノードがありますエッジも２種類ありあるノードから別のノードへデータの流れを表すデータエッジと関数呼び出しの実行順序を表すコントロールエッジですここでは関数ステッチが計算グラフを使って関数を生成する様子を見てみましょうまずスティッチングできる関数について説明しますグラフの関数はスティッチング属性が必要でこのような関数は可視化された関数であり functionStitching APIで使用することができアプリのバンドルに同梱の Metalライブラリの一部にしてAIRへの変換コストを回避できます
スティッチング処理では Metalのフロントエンドを完全に飛ばしてAIRで直接機能を生成します生成された関数は通常のスティッチングできる関数でパイプラインにリンクしたり関数ポインタにしたり他の関数生成に使用したりすることができますそこで先ほどのグラフでライブラリから二重関数ＡとＣが出てきたとしますこれらをグラフにバインドするとどうなるか見てみますスティッチャーは各関数ノードに対応する関数タイプを関連付けます N0とN1は FunctionAから型を取得し N2はFunctionCから型を取得しますその後スティッチングは入力ノードを使う関数のパラメータの型を見て入力ノードの型を推定します例えば Input0は N0とN1の第１引数なので pointerで考案された型であると推測されます
そしてスティッチングは Metalで説明した以下のものと同等の関数を生成します functionStitching APIを使えばこのような関数を含むライブラリをAIRから直接生成することができますステッチの仕組みがわかったところで APIでの使い方を紹介しますまずスティッチング関数の入力を定義します全ての引数を考慮し十分な入力ノードを作りますグラフ内で呼び出す関数ごとに関数ノードを作成します明示的な順序付けが必要な場合各関数の呼び出しに対し名前引数および制御の依存関係を定義します最後に関数名グラフ内で使用される関数ノード適用したい関数属性を持つグラフを作成しますまた OutputNodeを割り当てます OutputNodeはスティッチング関数の結果の出力値を返しますグラフができました次は関数です最初にStitchedLibrary Descriptorを作成します stitchableFunctionsと functionGraphを追加しますそしてディスクリプタを使ってライブラリを作成しスティッチング関数を作ることができ他のスティッチングのグラフの関数としてなどスティッチング関数が必要な場所どこでも使用できますスティッチング関数については以上ですこのAPIはmacOS Montereyや iOS 15でも利用可能です今日はお話したのはレンダーパイプラインのダイナミックライブラリと関数ポインタについてとプライベートリンク関数で表示関数を静的にリンクでき動的にシェーダを作成する際スティッチング関数がどうコンパイル時間を短縮できるのかについてでした
どのような場合にどちらを選ぶのでしょうか？ヘルパーやユーティリティ関数をリンクするのにダイナミックライブラリは優れた選択肢でセットが固定で頻繁な変更がない場合に最適です関数ポインタはシェーダがシグネチャ以外知らない関数を呼び出す機能を追加するものです関数の数や名前はもちろん開発者がAIRやバイナリでどんな速度と柔軟性のトレードオフを行ったかまで知る必要はありません関数ポインタもキャッシュできるようになりましたプライベート関数は関数を名前で静的にパイプラインステートオブジェクトにリンクしますこれらはパイプラインの内部にあるため可視化された関数テーブルにエンコードはできませんがコンパイラが最適化しすべてのGPUファミリーでサポートされていますスティッチング関数ではコードスニペットをAIRに直接プリコンパイルし実行時関数のコンパイルを行えます Metalシェーダストリングを合成していて実行時にソースからコンパイルするコストがかかっているならスティッチング関数はワークフローを高速化しますこれらのコンパイラ機能を活用してMetalを使った新しい体験を開発していただきたいと思いますご視聴ありがとうございました WWDC 2021をお楽しみ下さい [音楽]

// Declare external functions

extern float4 foo(FragmentInput input);
extern float4 bar(FragmentInput input);

// Use functions in shader

fragment float4 main(FragmentInput input [[stage_in]])
{
    switch(condition(input)) 
    {
        case 0: 
            return foo(input);
        case 1:
            return bar(input);
    }
}

9:01 - Declare and instantiate visible functions

// Declare a descriptor and set CompileToBinary options

MTLFunctionDescriptor* functionDescriptor = [MTLFunctionDescriptor new];
functionDescriptor.options = MTLFunctionOptionCompileToBinary;

// Backend compile the function

functionDescriptor.name = @"foo";
id<MTLFunction> foo = [library newFunctionWithDescriptor:functionDescriptor

9:30 - Configure pipeline descriptor

// Provide a list of functions that the pipeline stage may call

// AIR functions

renderPipeDesc.fragmentLinkedFunctions.functions = @[foo, bar, baz];

// Binary functions

renderPipeDesc.fragmentLinkedFunctions.binaryFunctions = @[foo, bar, baz];

10:47 - Create and populate visible function table

// Create visible function table

    [renderPipeline newVisibleFunctionTableWithDescriptor:stage:];

// Create function handles

    [renderPipeline functionHandleWithFunction:stage:];

// Insert handles into table

    [visibleFunctionTable setFunction:atIndex:];

11:21 - Encoding and calling function pointers

// Bind visible function table objects to each stage

    [renderCommandEncoder setFragmentVisibleFunctionTable:atBufferIndex:];

// Usage in shader

   fragment float4 shaderFunc(FragmentData vo[[stage_in]],
                              visible_function_table<float4(float3)>materials[[buffer(0)]])
   {
   		 //...
     
       return materials[materialSelector](coord);
   }

12:20 - Incremental pipeline creation

// Enable incrementally adding binary functions per stage

renderPipeDesc.supportAddingFragmentBinaryFunctions = YES;

// Create render pipeline functions descriptor

MTLRenderPipelineFunctionsDescriptor extraDesc;
extraDesc.fragmentAdditionalBinaryFunctions = @[bat];

// Instantiate render pipeline state

id<MTLRenderPipelineState> renderPipeline2 =
  [renderPipeline1 newRenderPipelineStateWithAdditionalBinaryFunctions:extraDesc

20:30 - Stitching process

[[stitchable]] int FunctionA(device int*, int) {…}
[[stitchable]] int FunctionC(int, int) {…}

[[stitchable]]
int ResultFunction(device int* Input0,
                   int Input1, 
                   int Input2)
{
  int N0 = FunctionA(Input0, Input1);
  int N1 = FunctionA(Input0, Input2);
  int N2 = FunctionC(N0, N1);    
  return N2;
}

21:32 - Creating the graph

// Create input nodes

  inputs[0] = [[MTLFunctionStitchingInputNode alloc] initWithArgumentIndex:0];

// Create function nodes

  n0 = [[MTLFunctionStitchingFunctionNode alloc] initWithName:@"FunctionA"
                                                    arguments:@[inputs[0], inputs[1]]
                                          controlDependencies:@[]];
  n1 = [[MTLFunctionStitchingFunctionNode alloc] initWithName:@"FunctionA"
                                                    arguments:@[inputs[0], inputs[2]]
                                          controlDependencies:@[]];
  n2 = [[MTLFunctionStitchingFunctionNode alloc] initWithName:@"FunctionC"
                                                    arguments:@[n0, n1]
                                          controlDependencies:@[]];

// Create graph

  graph = [[MTLFunctionStitchingGraph alloc] initWithFunctionName:@"ResultFunction"
                                                            nodes:@[n0, n1]
                                                       outputNode:n2
                                                       attributes:@[]];

22:18 - Configure stitched library descriptor

// Configure stitched library descriptor
  
  MTLStitchedLibraryDescriptor* descriptor = [MTLStitchedLibraryDescriptor new];

  descriptor.functions      = @[stitchableFunctions];
  descriptor.functionGraphs = @[graph];

// Create stitched function

  id<MTLLibrary> lib = [device newLibraryWithDescriptor:descriptor 
                                                  error:&error];

  id<MTLFunction> stitchedFunction = [lib newFunctionWithName:@"ResultFunction"];

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

WWDC20