Metal 4の概要

こんにちは Aaronです 本日は Metal APIの大幅なアップデートについて 詳しくお話します MetalはAppleの低レベルの グラフィックスと演算のAPIです 複数世代にわたる 複雑なアプリをサポートしてきました たとえば 最新ゲーム「Cyberpunk 2077」や 強力なプロ向けアプリなどです デベロッパはMetalを中核にして Appleプラットフォームでの レンダリングや演算を考えます 10年以上の経験を積み重ねて Metal 4はAPIを次のレベルに引き上げ デベロッパは高負荷のゲームや プロ向けアプリの提供が可能になりました Metal 4は次世代の ゲーム、グラフィックス、演算アプリを 念頭に置いて構築されています Appleシリコンのパフォーマンスを 最大限に引き出すと同時に DirectXなど 他のグラフィックスAPIや演算APIから 移行した場合も わかりやすく扱いやすい APIになっています Metal 4はアプリに すでに含まれている可能性のある Metalフレームワークの一部であり Apple M1以降のチップや A14 Bionic以降のチップを搭載した デバイスでサポートされています Metal 4は明示的なメモリ管理を備えた 新しいコマンド構造から始まります これでリソースの管理方法が変わり リッチで複雑なビジュアルが実現します シェーダコンパイルは 多くのオプションで高速化され アプリでは冗長なコンパイルを 減らすことができます 機械学習をMetalアプリの他の部分と シームレスに統合することもできます 新しい組み込みソリューションを MetalFXを通じて利用し アプリのパフォーマンスを 向上させることもできます Metal 4の導入を始める方法も紹介します 最初に アプリでのコマンドの エンコード方法と送信方法を説明します Metalはシステムで Metalデバイスとして表され OSによってアプリに提供されます Metalデバイスを取得した後で コマンドキューを作成して ハードウェアに処理を送信できます そしてコマンドバッファを作成し 送信する処理を格納します コマンドエンコーダではコマンドバッファに コマンドをエンコードできます 現在アプリで使用しているものと同じ MTLDeviceを使って Metal 4を活用できます Metal 4では コマンドのエンコード用に 新規かつ使いやすいモデルが提供されます 他のオブジェクトにも 新しいバージョンが導入されます こうした変更は 新しいMTL4CommandQueueから始まり アプリでMTLDeviceを使用して 取得できます コマンドバッファを使用するキューから コマンドバッファが切り離されます そのためアプリはデバイスから MTL4CommandBufferも要求します コマンドバッファは それぞれ独立しているため アプリではコマンドバッファを 簡単に並列でエンコードできます アプリはさまざまな種類のコマンドに対して エンコーダを活用します 描画、ディスパッチ、ブリット、 アクセラレーション構造の構築などです Metal 4は既存の コマンドエンコーダを統合します 統合された新しい演算エンコーダにより アプリでは ブリットや アクセラレーション構造の コマンドエンコーディングも管理します これで必要なエンコーダの 総数が削減されます 新しいMTL4RenderCommandEncoderも 用意されています アタッチメントマップを備えており アプリで使うと物理的な色アタッチメントに 論理的なシェーダ出力をマップできます 必要なすべての色アタッチメントを使って 1つのレンダリングエンコーダの アタッチメントマップを構成することで アタッチメントの即時切り替えが可能です 追加のレンダリングエンコーダを 割り当てる必要がなくなり アプリのメモリを節約し 不要なコードを削減できます アプリでは利用可能なエンコーダタイプを 任意に組み合わせて コマンドバッファに コマンドをエンコードできます コマンドバッファは メモリでサポートされます アプリがコマンドをエンコードすると データがメモリに書き込まれます Metal 4ではMetal 4コマンドアロケータで このメモリが管理されます デバイスでコマンドアロケータを作成し アプリのコマンドバッファの メモリ使用量を直接制御します 利用可能なシステムリソース内で 最新のアプリの性能を最大限に発揮するには メモリ管理が不可欠です こうしたアプリはこれまで以上に 多くのリソースを使用します Metal 4では アプリは異なる方法で リソースを管理します Metalでは2つの基本的な タイプのリソースを使用します バッファにはアプリにフォーマットされた 汎用データが格納され テクスチャには 画像フォーマットデータが格納されます 以前のアプリでは リソースはより少なく 1つのオブジェクトで単一のバッファと テクスチャのみを使う場合もありました その後表面のディテールを向上させるために 多くのテクスチャが追加されました また レンダリングの多様性を高めるために 多くのジオメトリが追加されました 最新のアプリではこの傾向が続いており 複雑で新しいユースケースに対応するために 多くのリソースを取り込むようになりました リソースの数は増加しましたが APIで公開されるのは リソースバインドポイントの 固定されたセットのみで 各描画やディスパッチに対して リソースを設定していました 従来 描画にはわずかなリソースしか 使われていませんでした たとえば ウサギのジオメトリにあるのは 1つのテクスチャとバッファのみです 描画ごとに 各オブジェクトはジオメトリや テクスチャ用のバッファを変更して 表面の外観を変えることができます ただし 描画関数の数が増え シェーダがより複雑になると 各描画のバインドポイントの管理の影響が CPU時間の増加につながりました そこで アプリはバインドレス方式になり バインドされたリソースを移動して 別のバッファにバインディングを格納します この方法では単一の引数バッファを オブジェクトごとかシーン全体で バインドするだけで済みます これで必要なバインドポイントの数を 大幅に減らすことができます 余分なバインドポイントにかかるコストを 回避するために Metal 4には新しいタイプの Metal 4引数テーブルが用意され アプリが必要とする バインドポイントを格納できます 引数テーブルはエンコーダの 各ステージに対して指定されますが ステージ間で共有できます アプリで必要なバインドポイントに基づく サイズでテーブルを作成します たとえば バインドレスの場合 引数テーブルで必要な バッファバインディングは1つです GPUがこれらすべてのリソースに アクセスできるようにする必要もあります ここで登場するのが常駐です Appleシリコンは大規模な 統合メモリ空間を提供します これを使用してアプリの すべてのリソースを格納できますが Metalは常駐させるリソースを 認識する必要があります Metal 4では アプリは 常駐セットを使用してリソースを指定し Metalで常駐させます これで リソースはハードウェアに アクセス可能になります 常駐セットはフレームごとに コマンドバッファのエンコーディングと コミットに簡単に統合できます 常駐セットには コマンドバッファのコミットに必要な リソースが揃っていることを 確認してください ただし常駐セットの内容は ほとんど変わらないため 常駐セットへの入力は アプリの起動時に実行できます 作成された常駐セットは Metal 4のコマンドキューに追加できます そのキューにコミットされたすべての コマンドバッファにリソースが格納されます 更新が必要な場合 実行時のコストは大幅に削減されます リソースのストリーミングの入出力を 別のスレッドで行うアプリでは 常駐セットの更新のコストを そのスレッドに移し エンコードと並行して 常駐セットを更新できます 常駐セットのメリットを活かした ゲームの代表例として「Control Ultimate Edition」があります Remedy Entertainmentの Technical Publishing Directorである Tuukka Taipalvesi氏はこう言っています Control Ultimate Editionでは 常駐セットを簡単に統合できました 使用状況に基づいて リソースを異なる常駐セットに分割し バックグラウンドスレッドで リソース常駐を管理することで 常駐管理のオーバーヘッドが大幅に削減され レイトレーシングが無効になっている際に メモリ使用量も低下しました

「Control」のような優れたゲームには より多くのリソースが必要です 特に幅広いデバイスを対象とする場合 利用可能なメモリでは 足りなくなることがあります 利用可能なメモリを 最大限に活用するために アプリはリソースによるメモリの使用を 動的に制御できます それにはリソースへのメモリの割り当てを 細かく制御する必要があります すべてのリソースが同時に 必要になるわけではないからです アプリは常駐の詳細レベルを 制御することで品質を調整し 様々なデバイスで 同じコンテンツをサポートできます これを実行するにはアプリで 配置スパースリソースを使います

Metal 4は配置スパースリソースとして バッファとテクスチャをサポートします これらのリソースはデータを格納するための ページを使わずに割り当てられます 配置スパースリソースでは ページは配置ヒープから取得されます アプリは配置ヒープからページを割り当て リソースの内容の格納に必要な ストレージを提供します Metal 4ではデフォルトで 並行処理に重点を置いているため リソースの更新が同期されていることを 確認する必要があります 同期を簡略化するために Metal 4ではバリアAPIが導入され 低オーバーヘッドの ステージ間同期により 他のAPIのバリアに適切にマップされます バリアの動作を確認するには Metal 4のサンプル 「演算関数でテクスチャを処理する」を ご参照ください アプリはカラー画像から始まり 演算シェーダを適用して グレースケールに変換し 変換されたテクスチャを 画面にレンダリングします これらのステップが依存しているのは 共有リソースの テクスチャ処理の出力です サンプルではリソースの 書き込みと読み取りが Metal 4バリアを使って 正しい順序で行われます 同期を行わないと 任意の順序で実行される可能性があり 間違ったテクスチャの内容が使われる場合や さらに悪いことに 2つのステップが同時に行われると 出力が破損する場合があります 正しい順序で実行するために アプリではバリアを使います バリアはステージ間で機能します そのためエンコーダのステージに基づいて 各操作がどのステージで実行されるかを 考慮する必要があります

テクスチャの処理は ディスパッチステージの操作として 演算コマンドエンコーダで実行されます レンダリングはレンダリングコマンド エンコーダとして機能し フラグメント操作で テクスチャを読み取ります つまり必要なのはディスパッチから フラグメントへのバリアであり ディスパッチステージの処理が完了してから フラグメントの処理を開始します バリアを効果的に使うことで アプリのパフォーマンスを最大化できます 多数のリソースを利用する場合は 特にそうです

最新のアプリではリソースに加えて 膨大な数のシェーダも管理します これらのシェーダーをコンパイルしてから ハードウェアに送信し レンダリングや演算を行う必要があります シェーダはMetal シェーディング言語で記述され Metal IRに変換されます IRはGPUバイナリにコンパイルされ ハードウェアによってネイティブに 実行されます デベロッパはシェーダーコンパイルの 発生タイミングを制御できます Metalデバイスのインターフェイスから シェーダを送信し OS側でCPUによってコンパイルできます Metal 4は専用のコンパイルコンテキストで コンパイルを管理します MTL4Compilerの新インターフェイス はデバイスから分離されました アプリはデバイスを使用して コンパイラインターフェイスを割り当てます このインターフェイスによって CPUでコンパイルするタイミングを 明確かつ明示的に制御できます またMTL4Compilerを活用して シェーダコンパイルスタックで スケジューリングを改善することもできます MTL4Compilerはコンパイルを 要求するスレッドに割り当てられた サービス品質クラスを継承します 複数のスレッドが同時に コンパイルされると OSは優先度の高いスレッドからの 要求を先に処理し アプリの最も重要なシェーダを 最初に処理して 他のコンパイルに進みます シェーダコンパイルの 明示的な制御は重要です 最新のアプリはこれまで以上に 多くのシェーダを使うためです パイプライン状態を生成しているとき アプリはまず 各シェーダーをコンパイルしてから GPU処理を実行する必要があります パイプラインは共通のMetal IRを 共有する場合があります たとえばアプリで様々な色の状態を 適用して異なる透明度で レンダリングする場合があります 同じ状況が他のパイプラインのセットにも 該当する場合があります Metal 4では状況に合わせて 最適化できるため シェーダコンパイルにかかる時間を 短縮できます レンダリングパイプラインでは柔軟な レンダリングパイプライン状態を使って 共通のMetal IRを1回で構築できます 特殊化されていない パイプラインが作成されます その後アプリはパイプラインを 目的の色の状態で特殊化します Metalはコンパイルされた Metal IRを再利用して 実行用の特殊化された パイプラインを効率的に作成します 柔軟なレンダリングパイプライン状態により Metal IRをシェーダパイプラインで使う際 コンパイル時間が節約されます アプリは特殊化されていない パイプラインを一度作成してから 必要な各色の状態に合わせて パイプラインを特殊化します Metal IRを共有する他のパイプラインに このプロセスを繰り返し それぞれのコンパイル結果を共有することで アプリがシェーダのコンパイルに 費やす時間を短縮できます デバイス上でのコンパイルは 依然としてCPU時間を消費します 最もパフォーマンスの高い方法は デバイス上で一切コンパイルしないことです Metal 4はパイプライン構成の 収集を効率化します Metal 4のコンパイルワークフローを 活用する方法の詳細や コマンドエンコーディングの詳細については Metal 4対応のゲームでご確認ください Metal 4を使用すると機械学習の統合が これまで以上に簡単になり アプリに対して まったく新しい可能性が広がります レンダリング技法としてアップスケール、 アセット圧縮、アニメーションブレンド、 ニューラルシェーディングなどでは 適切な機械学習によりメリットを得られます これらの技法を効率的に適用するには アプリで複雑なデータセットや データ構造を操作する必要があります バッファは柔軟性がありますが 多くの重い処理をアプリが負担するため テクスチャにはあまり適していません Metal 4にはテンソルの サポートが追加されました 基本的な機械学習リソースタイプで すべてのコンテキストに対応します Metalテンソルは多次元データコンテナです 2次元を超えて拡張可能であり 実用的な機械学習の用途に合わせて データレイアウトを柔軟に表現できます Metal 4はテンソルをAPIに 直接統合するだけでなく Metalシェーディング言語にも統合します テンソルは複雑なインデックス作成を 多次元データにオフロードするため Metal 4アプリではテンソルを使用して 新しい方法で機械学習を適用できます これを簡単にするためにMetal 4は対応する コマンドエンコーダのセットを拡張します 新しい機械学習コマンドエンコーダにより 大規模なネットワークをMetalアプリ内で 直接実行できます 機械学習エンコーダは 既存のMetalエンコーダタイプと 同様に機能します テンソルは引数テーブルにマップされた リソースとして利用されます エンコードは同じコマンドバッファに行われ バリアをサポートし 他のMetal 4エンコーダと同期します Metal 4の機械学習エンコーダは 既存のCore MLパッケージ形式で表された ネットワークと互換性があります Metalツールチェーンを使用して Metalパッケージに変換し ネットワークをエンコーダに直接送ります 新しい機械学習エンコーダは Metalアプリの他の部分との コマンドレベルでのインターリーブを 必要とする大規模ネットワークに最適です 小規模なネットワークの場合でも Metal 4は柔軟性に優れているため 既存のシェーダパイプラインに 直接統合できます たとえばニューラルマテリアル評価では 従来のマテリアルテクスチャが 潜在的なテクスチャデータになります 潜在的なテクスチャをサンプリングして 入力テンソルを作成し サンプリングした値で推論を実行し 最終出力からシェーディングを実行します 各ステップを独自のパイプラインに 分割するのは非効率的です 各ステップではデバイスメモリから テンソルを同期し 操作後は後続の操作のために 出力を同期し直す必要があるからです パフォーマンスを最大化するには これらのステップを 1つのシェーダディスパッチに統合し 各操作が共通のスレッドメモリを 共有できるようにする必要があります 推論の実装は複雑な作業ですが Metal 4ではMetalパフォーマンス プリミティブによって対応できます Metalパフォーマンスプリミティブは 複雑な計算を実行できる シェーダプリミティブであり テンソルに対してネイティブに操作できます 各プリミティブはAppleシリコン上で 高速に動作するように最適化されています テンソル操作は小規模ネットワークを シェーダに埋め込む際に最適です アプリはこれらの操作をMetal シェーディング言語の一部として活用します その場合 使用中のデバイスに 最適化されたシェーダコードを OSシェーダコンパイラが 直接シェーダにインライン化します Metalの新しい機械学習機能の 使用方法について詳しくは 「Combine Metal 4 machine