Metal 4ゲームの詳細

Metal 4ゲームの詳細

Metal 4の最新の機能強化を導入してゲームエンジンを最適化する方法を学びましょう。コマンドのエンコーディングを統一してCPUオーバーヘッドを最小限に抑える方法、大規模なシーンをサポートするためにグラフィックスリソース管理を拡張する方法、割り当てられたメモリ使用量を最大限に活用する方法、パイプライン状態の大規模なライブラリを迅速にロードする方法などを紹介します。このセッションの内容を十分理解できるよう、まず「Discover Metal 4」を視聴することをおすすめします。

関連する章
- 0:00 - イントロダクション
- 1:33 - エンコードの効率化
- 8:42 - リソース管理のアップスケール
- 17:24 - パイプラインの迅速なローディング
- 31:25 - 次のステップ
リソース
関連ビデオ

WWDC25
Tech Talks
- Appleシリコンゲーム向けのCPUジョブスケジューリングの調整
こんにちは Jasonです Yangです私たちはGPUドライバエンジニアですこのビデオでは Metal 4でゲームエンジンを高速化する方法を紹介しますこれは4部構成のシリーズの第2部で Metal APIの次のメジャーバージョンについて紹介します Metal 4ゲームの詳細の前に「Discover Metal 4」をご覧ください Metal 4の概要を説明していますこのビデオの次は「Go Further with Metal 4 Games」で新しいMetal FXとMetal Raytracingの APIについて説明します「Metal 4 Machine Learning」では MLの組み込みについて説明しますでは Metal 4の説明に入ります
Metal 4は最新のゲームエンジン向けに設計されています Ubisoftのゲーム「アサシンクリード：シャドウズ」では驚くほど精細にキャラクターや風景が描画されファンタジーの世界に引き込まれますギガバイト単位の詳細なジオメトリやテクスチャをストリーミングしレンダリングに膨大な数のシェーダを使い Appleシリコンの演算能力を最大限に活用していますこれからのゲームは求められる水準がさらに高くなりタスクに応じた拡張性の高いグラフィックスAPIが必要になりますそれに応えるのがMetal 4です
Metal 4にはゲームに役立つ Metalの重要な最新機能がいくつも含まれています効率的なコマンドのエンコーディングや拡張型のリソース管理によるホットパスの高速化読み込み中画面なしでのプレイを実現するパイプライン読み込みの高速化などですここでは同僚とともにこれらの機能の最適な使い方についてお話しますゲームのすべてのフレームで描画呼び出しやカーネルディスパッチブリットおよびレイトレーシング処理がエンコーディングのホットパスになります Metal 4のエンコーディングは効率化と並行処理によりこの課題に対応するよう設計されています
Metal 4では使用頻度の高い処理を 2つのエンコーダクラスにまとめ各エンコーダの機能を高めていますコマンドアロケータではエンコーディングに伴うメモリ割り当てを明示的に管理できますコマンドバッファにより複数のスレッドで処理をエンコードできます
「Discover Metal 4」では Renderと Computeの2つのエンコーダクラスによるコマンドエンコーディングの処理について説明しましたこれらを効率的に使うには演算処理間のデータの依存関係を同期しアタッチメントマップを使ってフラグメントシェーダの出力の再マッピングを行う必要がありますすべての演算処理やカーネルディスパッチブリット、アクセラレーション構造の構築を 1つの演算エンコーダでエンコードできるようになります特に同期の必要なくこれらのコマンドを同時に実行できますこれにより依存関係のないワークロードで GPUリソースを効果的に使用できますデータの依存関係によりパスのコマンドをシリアルに実行する必要がある場合はパスバリアを使って明示できますこのバリアにより GPUが待機状態になりこのエンコーダのそれまでのブリットがすべて完了してからその後の演算ディスパッチが開始されますこちらはブリットからディスパッチへのアクセスを同期する方法の一例ですまず copyFromBufferのブリットでbuffer1を更新してパスバリアをエンコードしますこれで buffer1のデータを使用するディスパッチをエンコードできますこれが統合演算エンコーディングですすべての演算処理を1つのエンコーダで実行しバリアでデータの依存関係を表現すると Metal 4によりレンダリングのエンコーディングも更新されますカラーアタッチメントマッピングによりレンダリングパイプラインの色出力とレンダリングエンコーダのアタッチメントの対応関係を制御できるようになります固定のレンダターゲットレイアウトにパイプラインをバインドするのではなくカラーアタッチメントマップを指定できますエンコーダを切り替えるのではなく新しいパイプラインの設定時にマップを変更できます 3つのアタッチメントに描画する fragment関数を持つ Metalパイプラインがあるとしますカラーアタッチメントマッピングがない場合 3つのカラーアタッチメントを持つレンダリングエンコーダを作成します fragment関数が3つの色出力を返しエンコーダがそれらの出力をタイルメモリの対応するアタッチメントに送ります次の描画呼び出しでは別の出力の書き込みを行うパイプラインが必要になる場合がありますアタッチメントが異なるため色出力に応じた新しいレンダリングエンコーダを作成する必要が生じますカラーアタッチメントマッピングがあれば 2つ目のエンコーダは必要ありませんレンダリングエンコーダに両方のパイプラインで必要なカラーアタッチメントがありますカラーアタッチメントマップでシェーディング出力が特定のアタッチメントに変換されますカラーアタッチメントマップを実装するにはカラーアタッチメントマップをサポートする RenderPassDescriptorを用意します次にエンコーダで使用されるアタッチメントのスーパーセットを作成しますエンコーダが描画するアタッチメントを設定するにはカラーアタッチメントマップを作成し再マッピングエントリを設定しますエントリごとにシェーダ出力を指定する論理インデックスとアタッチメントのインデックスを指定する物理インデックスを設定しますエンコーディング前にマッピングオブジェクトを構築し各フレームで再利用しますレンダリングパイプラインの設定時にカラーアタッチメントマップもバインドしますパイプラインで別のアタッチメントの描画を行う場合は別のカラーアタッチメントマップに切り替えますカラーアタッチメントマッピングによりゲーム内のレンダリングエンコーダの数を大幅に削減できますレンダリングパスが減ることでエンコーディングのオーバーヘッドが減り GPUの効率性が向上します
Metal 4ではメモリ割り当ての制御も強化されています
コマンドアロケータによりコマンドバッファメモリを再利用できエンコーディング時の動的割り当てが避けられますコマンドをエンコードするほどアロケータのメモリ消費量が増えます関連付けられたGPUコマンドの実行が完了したらアロケータをリセットしますそれにより以降のコマンドエンコーディングでコマンドのメモリを再利用できます複数のアロケータを使うことで GPUの処理完了までエンコーディングがブロックされるのを回避できます新しいコマンドアロケータでエンコードするとエンコードするコマンド用のメモリが割り当てられますこのコマンドのメモリは GPUで実行される処理であるためコミットされた処理が完了するまで待機してからリセットします GPIの処理が完了したらコマンドアロケータをリセットしますこれにより即座にメモリに再利用可能のマーキングがされます GPUの処理の実行中にエンコーディングを続けるには 2つ目のコマンドアロケータを使用します GPU処理の完了までエンコーディングがブロックされるのを回避できます GPUの処理が完了したらコマンドアロケータをリセットすることが重要ですリセットしないとエンコーディング対応でアロケータのメモリ消費量が増加しますコマンドアロケータでエンコードする処理がそれ以上ない場合は解放することでメモリ消費量を削減できますコマンドアロケータはスレッドセーフではないためスレッドごとに別のアロケータを使用しますこれはシーンのエンコーディングを並列処理する際に重要です Metal 4のコマンドバッファでは複数のスレッドにエンコーディングを分割できますシングルスレッドのエンコーディングでは一連のコマンドを1つ以上のコマンドバッファに順次エンコードします AppleシリコンのパワフルなマルチコアCPUを利用すればコマンドアロケータの異なる複数のスレッドで複数のコマンドバッファを使用できます柔軟性が向上したMetal 4の演算エンコーダを使用してブリットやディスパッチアクセラレーション構造の処理のエンコーディングを均等に分散させることができますコマンドバッファのエンコードが完了したら 1回のコミット呼び出しですべてを送信できます Metal 4では複数のレンダリングエンコーダを1つのパスとして GPUにコミットすることもできますエンコードに時間がかかるレンダリングパスがあるとしますデフォルトではエンコーディングを別々のレンダリングエンコーダに分割すると GPUはそれらを個別のレンダリングパスとして実行しますパスごとに中間結果の保存と読み込みのオーバーヘッドが発生します
Metal 4のSuspendとResumeのオプションでは複数のレンダリングエンコーダをマージできます 1つのコマンドバッファのレンダリングエンコーダを一時停止して別のコマンドバッファで再開しますコマンドバッファのエンコードが完了したら 1回のコミット呼び出しで順次送信します 1回のコミットで複数のレンダリングエンコーダを送信すると複数のレンダリングパスがマージされますこの実装には suspendingオプションを使って最初のエンコーダを作成します Metalによりこのエンコーダが後続のエンコーダとマージされますエンコーダごとに異なるコマンドバッファを使用します真ん中のエンコーダには resumingと suspendingの両方のオプションがあります最後のエンコーダは resumingオプションのみで作成しますエンコーディングした3つのコマンドバッファをすべて一緒にコミットします
これでレンダリングパスをマージできました Metal 4ではエンコーディングの効率を上げるためにエンコーダの数を減らしコマンドメモリを再利用し複数のスレッドでエンコーディングすることができます Metal 4のコマンドエンコーディングの詳細については Apple Developerの記事をご覧ください効率的なエンコーディングについて説明したので効率的なリソース管理に進みましょう Metal 4のいくつかの新機能は大規模なリソース管理に役立ちます引数テーブルと常駐セットを使うとリソースバインディングをリソース数千規模まで拡大できます Metal 4ではデベロッパがドローアブルリソースを管理する必要があり依存関係を制御できますキューバリアにより大規模なリソースの依存関係を表現できますテクスチャビュープールと配置スパースヒープは大規模なリソースに必要なメモリの管理に役立ちますシェーダが複雑化すると通常は大量のリソースに対応するためにバインドレスモデルが適します 1つの引数バッファでシェーダからバッファテクスチャ、サンプラパイプライン状態などを含む数千のリソースにアクセスできますただしルートレベルのリソースのバインドにはインデックス付きバインドポイントを使います
インデックスでリソースをバインドするには引数テーブルを使用しますエンコードでは次の描画またはディスパッチで使用する引数テーブルを設定しますこれらのリソースをインデックス付き関数引数としてシェーダで使用できます Metalは描画時とディスパッチ時に引数を収集しますそのため描画呼び出しと描画呼び出しの間に安全に新しいリソースを設定してインデックスをバインドできます 1つの引数テーブルを複数のエンコーダステージに設定できます
エンコーディング前に引数テーブルを作成するとリソースバインディングをクリティカルパスから除外できます 1つの引数テーブルを複数のエンコーダにアタッチできます引数テーブルを引数バッファと併用するとリソースバインディングのニーズに応じたスケーリングができますシェーダでこれらのリソースにアクセスするための次のステップは GPUの可視化です GPUでリソースが必要な場合はそのリソースを常駐セットに追加しますリソースにはパイプラインやバッファテクスチャ、ドローアブルが含まれます常駐セットにより複数のリソースをグループ化して一度に可視化できますコミットするコマンドバッファにまたはコマンドキューに直接アタッチします常駐セットに時間の経過に伴う変化が少ない場合はコマンドキューにアタッチするのがよいでしょう常駐セットに頻繁に変更がある場合は適切なコマンドバッファにアタッチします GPU用に大規模なリソースを準備するには時間がかかる場合があります Metalにセットのリソースをあらかじめ常駐させることができます望ましいのは少数の常駐セットに多くのリソースを持たせることですこれにより Metalでリソースを一括処理できパフォーマンスが向上します常駐セットの詳細については Apple Developerの記事と昨年の「Port advanced games to Apple Platforms」をご覧ください Metal 4ではリソース常駐の制御がゲームのドローアブルサーフェスにも適用されますゲームのレンダリングされたコンテンツをディスプレイに送信するには CAMetalLayerのドローアブルサーフェスにレンダリングします Metalの各レイヤーは動的な常駐セットを保持しますこれをコマンドキューに追加するとレイヤーの全テクスチャを常駐させられます常駐セットの追加は一度だけ行います必要があれば CAMetalLayerによって更新されます Metal 4ではレンダリングをドローアブルと同期させる必要もあります各フレームでは次のドローアブルの取得後ドローアブルへのレンダリング前のコマンドキューでの待機をエンコードします次にレンダリング処理をコミットした後キューのドローアブルへのシグナルをエンコードします
presentを呼び出してレンダリング完了後のフレームの内容をディスプレイに送信しますトラッキングのオーバーヘッドを減らすため Metal 4ではデベロッパがリソースを同期させる必要があります先ほどエンコーダでパスバリアを使用する方法について説明しましたキューバリアでは同じキューのエンコーダ間のデータの依存関係を表現します
バリアでは Metalのステージごとにフィルタリングされますエンコーダ内の各コマンドは 1つ以上の実行ステージに関連付けられます例えばレンダリングエンコーダの描画呼び出しでは頂点とフラグメントのシェーディングステージが生成されます AppleシリコンのGPUは頂点の処理をすべて一括で処理してからフラグメントシェーディングの処理を行います Metal 4の演算コマンドはディスパッチ、ブリットアクセラレーション構造のステージに対応しています過剰な同期を避けるため適切なステージを選択することが重要ですこの例では演算パスでカーネルディスパッチの大気シミュレーションを実行します結果をメモリ内のテクスチャに書き込みますレンダリングパスでシーンを描画しますフラグメントシェーディングではシミュレーション結果と照明のブレンドが必要ですが頂点の処理は演算処理とオーバーラップできる必要がありますシミュレーション結果へのアクセスを同期させるにはキューのディスパッチステージからレンダリングエンコーダのフラグメントステージへのバリアをエンコードしますこの例を実装するにはまず演算エンコーダのディスパッチをエンコードします次にレンダリングコマンドエンコーダでバリアをキューステージのディスパッチの後フラグメントステージの前に追加しますバリアの後描画呼び出しをエンコードできます Metalではこれまでのエンコーダのディスパッチステージの処理が完了するまで現在および今後のレンダリングエンコーダのフラグメントステージの処理は実行されません
バリアに最適な位置を見つけられるように Metalデバッガではバリアの位置とそのバリアが適用されるエンコーダおよびステージが表示されますこれを利用してデータの依存関係を維持しながら最大限に並行処理を行います
Metalのバリアを使ってリソースを同期させる方法の詳細については Apple Developerサイトの記事をご覧ください
テクスチャとバッファのストリーミングでは多数のリソースのメモリ使用量を管理できます Metal 4ではバッファとテクスチャを効率的にストリーミングできます軽量なテクスチャビューを作成しメモリリソース使用量を管理するには配置スパースを使用します最新のゲームではフレームごとに数百単位のテクスチャやテクスチャバッファビューが作られることがありますテクスチャビュープールではすべてのテクスチャビューを格納するのに必要なメモリの事前割り当てができますその後プールの任意のインデックスで軽量なテクスチャビューを作成できます動的な割り当ては行われないためエンコーディングの際に作成できますテクスチャビューのリソースIDを使って引数バッファまたは引数テーブルにバインドします実装方法を説明しますエンコーディングの前にテクスチャビュープールを作成しますこの場合テクスチャビュープールに500のテクスチャビュー用のメモリが割り当てられますエンコーディングではテクスチャビュープールの対象のインデックスにテクスチャビューを設定します返されたMTLResourceIDを使ってテクスチャビューを引数テーブルにバインドしますバインドが必要なリソースのメモリ使用量が大きい場合があります一度にすべてをメモリに収めきれないような高精細のリソースにはスパースリソースが適していますリソースの作成とメモリのバッキングが分離されます配置スパースではヒープのページに対するリソースのマッピングをデベロッパが管理しますリソースのメモリマッピングを更新する際 Metal 4のコマンドキューに対するAPIでその更新とほかのGPU処理を同期できます配置ヒープ内のメモリは一連のタイルとして扱われますスパースバッファとスパーステクスチャへのタイルの割り当てはデベロッパが管理しますスパースリソースのメモリを確保するにはバイト範囲またはピクセル領域をスパースタイルにマッピングします
配置ヒープを作成する際にはリソースに必要なスパースページサイズを考慮しますページサイズが大きいとマッピングとマッピング解除の処理でパフォーマンス上のメリットがありますがパディングとアラインメントに使用するメモリ量が増えますヒープでは指定した最大値までのスパースページサイズがサポートされますこの例では最大ページサイズとして 64 KBを指定しています配置ヒープを作成したらスパースリソースを作成できます配置スパースバッファとテクスチャの作成は Metalデバイスから行いますスパースリソース以外の場合と同様ですバッファの場合は要求するバッファサイズをスパースタイルのサイズの倍数に合わせますデバイスにはこの変換を実行するためのクエリが用意されています長さを指定して新規バッファを呼び出すときまたはテクスチャ記述子で placementSparsePageSizeを設定しますこのプロパティにより配置ヒープがメモリバッキングを提供することが Metalデバイスに伝わります配置スパースバッファを初めて作成する場合メモリバッキングはありませんタイルをバッファ範囲に割り当てるにはマッピング更新処理を使用します配置ヒープからバッファにタイルを割り当てるにはまずマッピングの更新操作を指定します開始オフセットと長さおよびヒープのタイルオフセットを指定してこのバッファ範囲に割り当てます Metal 4のコマンドキューでマッピング処理を送信します
スパースリソースの操作の詳細については Apple Developer Webサイトの記事をご覧ください最新のゲームにおけるもう1つの課題はパイプライン状態の大規模なライブラリの管理ですその説明はYangにお願いしますありがとうございます最新のゲームでは複雑で動的なビジュアルを生み出すために多数のパイプラインを作成する必要がありますシェーダコンパイルの遅延をなくしゲームの読み込み時間を短縮するために多数のパイプラインを迅速に読み込むことが重要です Metal 4でパイプラインを迅速に読み込むにはレンダリングパイプラインのコンパイルを再利用します進化した並列処理を活かしてデバイス上のパイプラインをコンパイルすることもできますさらに一歩進んで事前にパイプラインをコンパイルすることでパイプラインの読み込み時間をほぼゼロに短縮できます柔軟なレンダリングパイプライン状態を持つレンダリングパイプラインのコンパイルを再利用する方法の説明から始めます都市建設ゲームを制作しているとしますプレイヤーはマップ上に家を配置できますプレイヤーが家をどこに置くかを決める際家をホログラムスタイルでレンダリングする必要があり追加のブレンド状態を持つパイプラインが必要になりますプレイヤーが家を配置すると家の建築が始まります建築の進捗を示すために透明度を持たせて家をレンダリングするには透明のブレンド状態を持つ別のパイプラインが必要です最後に家の建築が完了したら不透明のブレンド状態を持つ 3つ目のパイプラインで家をレンダリングします作成時にすべてのパイプライン設定を指定しこれら3つをすべての状態を持つパイプラインとしてコンパイルすることもできます vertex関数とfragment関数不透明、透明、ホログラムの家用のカラーアタッチメントの設定から始めますここでのカラーアタッチメントの設定は記述子の一部を指しカラーアタッチメントへのフラグメントシェーダ出力の書き込みに影響しますこれにはアタッチメントのピクセル形式書き込みマスク、ブレンド状態が含まれます vertex関数とfragment関数、不透明の設定を参照するレンダリングパイプライン記述子を作成しますこの記述子を使って不透明のパイプラインを作成し頂点のバイナリとフラグメントのバイナリボディフラグメント出力部を含めます記述子のカラーアタッチメントの設定を入れ替えることで透明とホログラムのパイプラインも同様に作成できますこれら3つのパイプラインのバイナリはほぼ同じでフラグメント出力部のみが異なります CPUのタイムラインの観点では完全な不透明のパイプライン透明のパイプライン、ホログラムのパイプラインの順にコンパイルします CPUはフラグメント出力部を除いてほぼ同じパイプラインの再コンパイルに多くの時間を費やします Metal 4ではパイプラインのコンパイルの大部分を再利用できそれには最初に汎用型パイプラインを作成しますそのうえで異なるカラーアタッチメントの設定を使用して最終的に必要な特化型パイプラインを実現しますこれによりレンダリングパイプラインのコンパイル時間を大幅に短縮できますこれを実現するにはまず汎用型パイプラインを作成します同じ記述子で始めますが実際のカラーアタッチメントの設定を指定せずに各フィールドをunspecializedに設定しますそれにはすべてのカラーアタッチメント記述子をループして pixelFormat、riteMask、blendingStateに適切なunspecialized値を設定するだけです unspecializedのパイプラインには頂点バイナリとフラグメントバイナリボディデフォルトのフラグメント出力部が含まれますデフォルトのフラグメント出力でうまくいく場合もありますが多くの場合は特化型のパイプラインに置き換える必要があります特化型パイプラインを作成するには汎用型パイプラインと新しいレンダリングパイプライン記述子から始めますここでは記述子のカラーアタッチメントの設定に実際に必要な値を設定します特化型パイプラインにはデフォルトフラグメント出力の代わりに対応するフラグメント出力を含めますこの新しいフラグメント出力は非常に高速に生成できシェーダのコンパイル処理をすべてやり直す必要はありませんパイプラインを透明専用の特化型にする例に戻りますまず記述子の中の汎用型のプロパティの設定から始めますブレンディング状態を有効にしブレンディングのサブ状態を設定しますこのコードでは乗算済みアルファブレンドを行うようパイプラインを設定します次に特化型パイプラインをインスタンス化するために新しい記述子を使用し unspecializedPipelineを指定しますゲーム内で膨大なステートフルレンダリングパイプラインを作成する場合もあります読み込み時間を最大限に短縮するにはすべてのレンダリングパイプラインを unspecializedで作成し必要に応じて後で特化型にしますそのうえで小さなGPUパフォーマンスのオーバーヘッドがある場合がありますオーバーヘッドの多くは共有フラグメントボディの不要な処理によるものです例えばフラグメントシェーダが 4つのカラーチャネルに書き込みカラーアタッチメントにはチャネルが1つしかない場合コンパイラでは未使用チャネルを最適化できませんフラグメントバイナリボディからフラグメント出力部へのジャンプによっても小さなオーバーヘッドが生じます通常は小さなオーバーヘッドですがフラグメントシェーダによっては大きくなります重要なシェーダを特定しバックグラウンドですべての状態を持たせてコンパイルすることにより読み込み時間の短縮と優れたフレームレートを両立できます InstrumentsのMetalシステムトレースでは特化型フラグメントシェーダの負荷の高さの順位がわかりますまとめると柔軟性の高いレンダリングパイプライン状態をゲームに取り入れる最適な方法はこうですレンダリングパイプラインはすべて汎用型でコンパイルし必要に応じて特化型にします著しいパフォーマンスの低下がある場合は InstrumentsのMetalシステムトレースでゲームのプロファイリングを行い重要なパイプラインを特定します重要なパイプラインはバックグラウンドでステートフルバージョンをコンパイルし準備ができたら特化型バージョンと置き換えて使用します柔軟なレンダリングパイプライン状態の詳細については Apple Developer Webサイトのこちらの記事をご覧ください
柔軟なレンダリングパイプライン状態によりパイプラインのコンパイルを再利用したらパイプラインの読み込み時間短縮のためデバイスのコンパイルを並列処理しますゲームプレイ中にシングルスレッドでパイプラインを読み込むゲームもあります 1つのコンパイル用スレッドでゲームで使うパイプラインをビルドしますこちらはレンダリングのスレッドでエンコーディングなどの反復的なフレームレンダリング処理を実行します必要なパイプラインの準備が間に合わないとゲームがもたつくことがあります別のコンパイルスレッドを追加することでパイプラインの読み込みを高速化できますパイプラインのコンパイルが短時間で完了しますただしスレッドの優先度に注意しないと表示間隔に合わなくなるおそれがありますバックグラウンドでコンパイルされるスレッドの優先度をレンダリングスレッドよりも低い値に設定すると問題は解消されますゲームをスムーズに楽しめるようになりますこちらがゲームにマルチスレッドでのコンパイルを追加する方法です Metal 4 compilation APIを使用します Metal 4ではさらに広くコンパイラを使用できますゲームのアーキテクチャへの適合性に応じて Grand Central Dispatchを使用するか独自のスレッドプールを作成できますどちらを選択しても適切な優先度を設定する必要があります Metalではコンパイルタスクの優先度が考慮されます Grand Central Dispatchはマルチスレッドでコンパイルを実行する最も簡単な方法ですコンパイルで呼び出し元スレッドの優先度を継承するにはコンパイラで用意された非同期メソッドを指定してディスパッチグループを使用します非同期メソッドには完了ハンドラがあります Metalではこれらのメソッドが自動的に並行実行されますコンパイルの優先度をカスタマイズするには並行ディスパッチキューを作成しカスタムのQoSクラスを使用しますパイプラインのプレウォーミングとストリーミングにはデフォルト設定が推奨ですディスパッチキューにコンパイルタスクを送信するにはブロック内で同期メソッドを呼び出し dispatch_asyncでキューに送信します同期メソッドには完了ハンドラがありません
ゲームのアーキテクチャに適している場合独自のスレッドプールを作成することもできます Metalデバイスの maximumConcurrentCompletionTestCount プロパティをスレッドプールのスレッド数として使用しますデフォルトのスレッド数を2に設定しますこれがこのプロパティをサポートしていない OSの並行処理の最大数ですゲーム内の他の重要スレッドのリソースが枯渇しないようにコンパイル用スレッドに適切な QoSクラスを設定することも重要ですパイプラインのプレウォーミングとストリーミングでは QoSクラスをデフォルトに設定します以上ですこれでスレッドプールへのコンパイルタスクの送信を開始できますパイプラインのコンパイルの並列処理と優先順位付けの最適な方法については Apple Developer Webサイトのこちらの記事をご覧くださいデバイスでのマルチスレッドコンパイルによりコンパイル時間を大幅に短縮できますさらにゼロに近づけるには開発時にパイプラインを事前コンパイルするのが最善の方法ですパイプラインを事前にコンパイルするには通常ゲームでエンドツーエンドのワークフローを使用しますワークフローではまずインストゥルメンテーションを使用してゲームを実行しゲーム内で使用するパイプラインの設定を取得します取得した結果は GPUバイナリをビルドするためにGPUツールチェーンに渡されます最後に実行時に事前コンパイルされたGPUバイナリが検索されパイプラインが迅速にビルドされます Metal 4ではこれまでになく簡単にパイプライン設定をオンラインで収集しゲーム内の事前コンパイルされたバイナリを検索できます Metal 4でパイプラインの設定を収集する最も簡単な方法はパイプラインスクリプトのシリアル化ですパイプラインスクリプトは JSON形式のファイルですデバイスで作成するパイプライン記述子のテキスト表現が含まれますパイプラインスクリプトのシリアル化は簡単で Metal 4のパイプラインデータセットシリアライザを使用しますこのオブジェクトをコンパイラにバインドすると作成されたパイプラインの記述子が自動的に記録されます次にこれらの記述子をシリアル化してパイプラインスクリプトに書き込みますパイプラインデータセットシリアライザを作成するには記述子から始めます configurationに CaptureDescriptorsを設定しますこれによりパイプライン記述子の追跡のみを行うようシリアライザに伝わりメモリ使用量が減りますパイプラインデータセットシリアライザの作成にはシリアライザ記述子を使います次にシリアライザをコンパイラの作成に使用するコンパイラ記述子にアタッチしますコンパイラを作成したらそれを使用して通常通りパイプラインを作成できます使用するパイプライン記述子がシリアライザによって自動的に記録されます収集が完了したら serializeAsPipelinesScriptWithErrorを呼び出し記録されたパイプラインをシリアル化してパイプラインスクリプトに書き込みます戻り値はNSDataです任意の方法でこれを開発システムに送り返すことができますこの例ではディスク上のファイルに書き込みますファイルのサフィックスを mtl4-jsonに設定しますこれは GPUツールチェーンで求められるサフィックスですパイプラインの設定を取得できたら次のステップはバイナリのビルドですパイプライン設定スクリプトとMetal IR ライブラリの内容をmetal-ttに入力します GPUバイナリがMetalアーカイブに格納されて出力されます取得したパイプラインスクリプトの内容を metal-ttに入力する前にスクリプトを開いて Metal IRライブラリへのパスを編集し開発システム上のパスと一致させますパイプライン設定スクリプトの形式の詳細についてはこのコマンドでマニュアルページを開いてください画面上でmetal-ttコマンドを実行すると iOS用のアーカイブをビルドできますバイナリは事前コンパイルしているのでゲームの実行時にそれを見つける必要があります Metal 4ではこれまでより簡単にアーカイブ内のGPUバイナリからパイプラインを作成できますデバイス上でのコンパイルに使用するのと同じ記述子を使用してパイプライン状態を取得します例えば MTL4Archiveオブジェクトを作成するにはアーカイブのURLを指定します次にパイプライン記述子を指定してアーカイブオブジェクトから直接パイプライン状態を照会します
アーカイブの検索は様々な理由で失敗することがあります一致するパイプラインがない OSに互換性がない GPUアーキテクチャに互換性がないなどです Metal 4ではデベロッパがこれらの失敗に対処する必要がありますこの例では単にオンデバイスコンパイルにフォールバックしておりゲームで必要なパイプライン状態が使用できるようにしています
こちらは先ほどのサンプルゲームの CPUタイムラインでマルチスレッドのオンデバイスコンパイルを使用しています事前コンパイルを採用することでパイプラインの読み込み時間をほぼゼロに短縮できます事前コンパイルの詳細については Apple Developer Webサイトのこちらの記事をご覧くださいここからはまとめです Metal 4ではこれまで以上に高速にパイプライン状態を読み込む方法がありますパイプラインを特化型にすることでコンパイル結果を再利用できますマルチスレッド化によりコンパイルをさらに高速化できますパイプラインの読み込み時間を最短にするには事前コンパイルとともに効率的な収集と検索のワークフローを採用します Metal 4 APIを使って次世代のパフォーマンスに優れたゲームを開発するさまざまな方法をお伝えできて嬉しく思います新しいXcodeをダウンロードしてゲームのエンコーディング、リソース管理パイプラインの読み込みの最適化を始めましょう皆さんにお役立ていただけるようサンプルプロジェクトや詳細な記事を用意しています Metal 4についてさらに詳しく知りたい場合はこのシリーズの他のビデオもご覧くださいご視聴ありがとうございました

0:01 - Synchronize access to a buffer within an encoder

// Synchronize access to a buffer within an encoder

id<MTL4ComputeCommandEncoder> encoder = [commandBuffer computeCommandEncoder];

[encoder copyFromBuffer:src sourceOffset:0 toBuffer:buffer1 destinationOffset:0 size:64];

[encoder barrierAfterEncoderStages:MTLStageBlit 
               beforeEncoderStages:MTLStageDispatch
                 visibilityOptions:MTL4VisibilityOptionDevice];

[encoder setComputePipelineState:pso];

[argTable setAddress:buffer1.gpuAddress atIndex:0];
[encoder setArgumentTable:argTable];
[encoder dispatchThreads:threadsPerGrid threadsPerThreadgroup:threadsPerThreadgroup];

[encoder endEncoding];code snippet.

4:29 - Configure superset of color attachments

// Configure superset of color attachments

MTL4RenderPassDescriptor *desc = [MTLRenderPassDescriptor renderPassDescriptor];

desc.supportColorAttachmentMapping = YES;

desc.colorAttachments[0].texture = colortex0;
desc.colorAttachments[1].texture = colortex1;
desc.colorAttachments[2].texture = colortex2;
desc.colorAttachments[3].texture = colortex3;
desc.colorAttachments[4].texture = colortex4;

4:38 - Set color attachment map entries

// Set color attachment map entries

MTLLogicalToPhysicalColorAttachmentMap* myAttachmentRemap = [MTLLogicalToPhysicalColorAttachmentMap new];

[myAttachmentRemap setPhysicalIndex:0 forLogicalIndex:0];
[myAttachmentRemap setPhysicalIndex:3 forLogicalIndex:1];
[myAttachmentRemap setPhysicalIndex:4 forLogicalIndex:2];

4:57 - Set a color attachment map per pipeline

// Set a color attachment map per pipeline

[renderEncoder setRenderPipelineState:myPipeline];
[renderEncoder setColorAttachmentMap:myAttachmentRemap];
// Draw with myPipeline

[renderEncoder setRenderPipelineState:myPipeline2];
[renderEncoder setColorAttachmentMap:myAttachmentRemap2];
// Draw with myPipeline2

8:03 - Encode a single render pass with 3 render encoders

// Encode a single render pass with 3 render encoders with suspend/resume options


id<MTL4RenderCommandEncoder> enc0 = [cmdbuf0 renderCommandEncoderWithDescriptor:desc options:MTL4RenderEncoderOptionSuspending];

id<MTL4RenderCommandEncoder> enc1 = [cmdbuf1 renderCommandEncoderWithDescriptor:desc options:MTL4RenderEncoderOptionResuming | MTL4RenderEncoderOptionSuspending];

id<MTL4RenderCommandEncoder> enc2 = [cmdbuf2 renderCommandEncoderWithDescriptor:desc options:MTL4RenderEncoderOptionResuming];


id<MTL4CommandBuffer> cmdbufs[] = { cmdbuf0, cmdbuf1, cmdbuf2 };
[commandQueue commit:cmdbufs count:3]

11:48 - Synchronize drawable contents

// Synchronize drawable contents

id<MTLDrawable> drawable = [metalLayer nextDrawable];
[queue waitForDrawable:drawable];

// ... encode render commands to commandBuffer ...
[queue commit:&commandBuffer count:1];

[queue signalDrawable:drawable];

[drawable present];

13:25 - Encode a queue barrier to synchronize data

// Encode a queue barrier to synchronize data

id<MTL4ComputeCommandEncoder> compute = [commandBuffer computeCommandEncoder];

[compute dispatchThreadgroups:threadGrid threadsPerThreadgroup:threadsPerThreadgroup];

[compute endEncoding];


id<MTL4RenderCommandEncoder> render = [commandBuffer renderCommandEncoderWithDescriptor:des];

[render barrierAfterQueueStages:MTLStageDispatch
                   beforeStages:MTLStageFragment
              visibilityOptions:MTL4VisibilityOptionDevice];

[renderCommandEncoder drawPrimitives:MTLPrimitiveTypeTriangle
                         vertexStart:vertexStart
                         vertexCount:vertexCount];

[render endEncoding];

14:57 - Create a texture view pool

// Create a texture view pool

MTLResourceViewPoolDescriptor *desc = [[MTLResourceViewPoolDescriptor alloc] init]; 
desc.resourceCount = 500;
 
id <MTLTextureViewPool> myTextureViewPool =  
    [myDevice newTextureViewPoolWithDescriptor:myTextureViewPoolDescriptor 
                                         error:nullptr];

15:07 - Set a texture view

// Set a texture view

MTLResourceID myTextureView = [myTextureViewPool setTextureView:myTexture  
                                                     descriptor:myTextureViewDescriptor  
                                                        atIndex:5];

[myArgumentTable setTexture:myTextureView 
                    atIndex:0];

16:01 - Choose appropriate sparse page size

MTLHeapDescriptor *desc = [MTLHeapDescriptor new];    
desc.type = MTLHeapTypePlacement;
desc.storageMode = MTLStorageModePrivate;
desc.maxCompatiblePlacementSparsePageSize = MTLSparsePageSize64;
desc.size = alignedHeapSize;

id<MTLHeap> heap = [device newHeapWithDescriptor:desc];

17:05 - Update buffer mappings

// Update buffer mappings

MTL4UpdateSparseBufferMappingOperation bufferOperation;

bufferOperation.mode = MTLSparseTextureMappingModeMap;  
bufferOperation.bufferRange.location = bufferOffsetInTiles;
bufferOperation.bufferRange.length = length;
bufferOperation.heapOffset = heapOffsetInTiles;

[cmdQueue updateBufferMappings:myBuf heap:myHeap operations:&bufferOperation count:1];

20:41 - Set unspecialized configuration

// In MTL4RenderPipelineColorAttachmentDescriptor
// Set unspecialized configuration

pipelineDescriptor.colorAttachments[i].pixelFormat   = MTLPixelFormatUnspecialized;
pipelineDescriptor.colorAttachments[i].writeMask     = MTLColorWriteMaskUnspecialized;
pipelineDescriptor.colorAttachments[i].blendingState = MTL4BlendStateUnspecialized;

21:40 - Create a specialized transparent pipeline

// Create a specialized transparent pipeline

// Set the previously unspecialized properties
pipelineDescriptor.colorAttachments[0].pixelFormat = MTLPixelFormatBGRA8Unorm;
pipelineDescriptor.colorAttachments[0].writeMask =
    MTLColorWriteMaskRed | MTLColorWriteMaskGreen | MTLColorWriteMaskBlue;
pipelineDescriptor.colorAttachments[0].blendingState = MTL4BlendStateEnabled;

pipelineDescriptor.colorAttachments[0].sourceRGBBlendFactor = MTLBlendFactorOne;
pipelineDescriptor.colorAttachments[0].destinationRGBBlendFactor = 
    MTLBlendFactorOneMinusSourceAlpha;
pipelineDescriptor.colorAttachments[0].rgbBlendOperation = MTLBlendOperationAdd;

id<MTLRenderPipelineState> transparentPipeline = 
    [compiler newRenderPipelineStateBySpecializationWithDescriptor:pipelineDescriptor
                                                          pipeline:unspecializedPipeline
                                                             error:&error];

// Similarly, create the specialized opaque and hologram pipelines

26:22 - Determine thread count

// Determine thread count
NSInteger numThreads = 2;
if (@available(macOS 13.3, iOS 19, visionOS 3, tvOS 19, *))
{
    numThreads = [device maximumConcurrentCompilationTaskCount];
}

26:30 - Set a proper QoS class for your compilation threads

// Create thread pool
for (NSInteger i = 0; i < numThreads; ++i)
{
    // Creating a thread with a QoS class DEFAULT
    pthread_attr_set_qos_class_np(&attr, QOS_CLASS_DEFAULT, 0) ;
    pthread_create(&threadIds[i], &attr, entryPoint, NULL);
    pthread_attr_destroy(&attr);
}

28:24 - Harvest pipeline configuration scripts

// Harvest pipeline configuration scripts with the pipeline data set serializer

// Create a pipeline data set serializer that only captures descriptors
MTL4PipelineDataSetSerializerDescriptor *desc = [MTL4PipelineDataSetSerializerDescriptor new];
desc.configuration = MTL4PipelineDataSetSerializerConfigurationCaptureDescriptors;
id<MTL4PipelineDataSetSerializer> serializer =
    [device newPipelineDataSetSerializerWithDescriptor:desc];

// Set the pipeline data set serializer when creating the compiler
MTL4CompilerDescriptor *compilerDesc = [MTL4CompilerDescriptor new];
[compilerDesc setPipelineDataSetSerializer:serializer];
id<MTL4Compiler> compiler = [device newCompilerWithDescriptor:compilerDesc error:nil];

// Create pipelines using the compiler as usual

// Serialize the descriptors as a pipeline script
NSData *data = [serializer serializeAsPipelinesScriptWithError:&err];

// Write the pipeline script data to disk
NSString *path = [NSString pathWithComponents:@[folder, @"pipelines.mtl4-json"]];
BOOL success = [data writeToFile:path options:NSDataWritingAtomic error:&err];

30:28 - Query pipeline state from MTLArchive

// Query pipeline state from MTLArchive

id<MTL4Archive> archive = [device newArchiveWithURL:archiveURL error:&error];

id<MTLRenderPipelineState> pipeline = 
    [archive newRenderPipelineStateWithDescriptor:descriptor error:&error];

if (pipeline == nil)
{
    // handle lookup miss
		pipeline = [compiler newRenderPipelineStateWithDescriptor:descriptor 
                                          compilerTaskOptions:nil 
}

関連する章

リソース

関連ビデオ

WWDC25

Tech Talks