Metal 3でバインドレスにする

Metal 3でバインドレスにする

Metal 3でバインドレスにする際に、レイトレーシングなどの強力なレンダリング技術をどう活用できるのかご覧ください。引数バッファーの単純化、ヒープからの加速構造の割り当て、Metalの検証レイヤーやDebugger Toolの改善による利点を活かして、Appのバインドレス化を実現する方法を紹介します。また、長期的なリソース構造で、CPUやGPUのパフォーマンスを制御する方法についても解説します。

リソース
関連ビデオ

WWDC23
- Macへのゲーム展開 Part 2：シェーダーをコンパイルする
WWDC22
WWDC21
ダウンロード

こんにちはようこそ AppleのGPU Software Teamの Alè Segovia Azapianです同じくGPU-ソフトウェアチームのMayurですバインドレスレンダリングについてお話しますシェーダーにリソース提供する最新の方法ですレイトレーシングなどのレンダリング技術に対応今日はその仕組みについて簡単におさらいして Metal 3でゲームやAppに採用する方法を説明します
データを集約するためCPU GPUの性能を向上させる新たな可能性が広がります私からCPUとGPU高速化のコツを2つお伝えし Mayurに引き継ぎます彼はこのツールがどう役立つかを説明しますバインドレスモデルではリソースは集約され- Argument Buffersで連結していますコンセプトとしてはこんな感じですこの例では全メッシュを配列で集約していますあるスロットに各リソースを独立してバインドする従来のモデルとは異なりバインドレスモデルではリソースはまずメモリ上で互いにリンクされますこれでシェーダーが精巧なサーフェスやライティングを計算するためリソースに自由にアクセスし単一のバッファーをバインドすることができますバインドレスになった後レイトレーシングのシェーダーは反射を美しくシェーディングするために必要なデータにアクセスすることができます Appは床やトラックその素材空までを含む 3Dモデルやテクスチャをそのすべてのデータを引数バッファに配置しシェーダーが利用できるようにしますさらにバインドレスレンダリングとHeapsなど Metalの他の機能を組み合わせると CPU負荷が軽減パフォーマンスが向上します Metal 3の拡張機能のうちバインドレスレンダリングに役立つ4つの機能について説明します引数バッファはMetal の基本構成要素でリソースを一緒にリンクさせることができますテクスチャやその他のバッファなどを参照します Metal 3ではArgument encoderオブジェクトが不要になったためバッファの作成が容易に結合されていない配列の場合も同様です Metal HeapからAccelerationNstructuresを割り当てることができ Shader Validation LayerがGPUメモリにリソースが常駐していないと警告を発します 4つの機能でバインドレス化をより簡単に実現します
特にargument buffersを書くのが楽しいですねシーンを引数バッファにエンコードするにはインスタンスメッシュマテリアルテクスチャなどシーンデータを引数バッファに書き込みます Metal 2では引数エンコーダで実行されましたそこではじめにこれらオブジェクトがどう機能するかをおさらいし次にMetal 3がどのように簡素化に役立つか紹介する関数のリフレクション構造体のメンバーを Metalに記述することで行いますエンコーダーインスタンスでその記録先とオフセットをターゲット引数バッファに設定しますそのメソッドを使ってバッファにデータを書き込む引数バッファと引数エンコーダについては昨年のbindlessセッションで詳しく確認してくださいさてこの仕組みは素晴らしいのですがエンコーダオブジェクトの管理が難しい場合があります Metalは引数エンコーダ作成に 2つのメカニズムを提供しますどちらがAppに適するか明確でない場合があります複数スレッドからエンコーダ使用する場合は要注意です開発者はC言語の構造体を直感的に理解していますが Metal3で引数バッファに対しまさにそれを実現できます他のCPU側構造体と同様直接バッファに書き込み可能引数バッファの書き込みが Metal 3では簡素化されますこれでリソースの仮想GPU アドレスとリソース ID にアクセスできるようになりましたこれらを直接引数バッファに書き込むとどのリソースを参照しているか Metalが理解しますエンコーダが不要になった以外は引数エンコーダを使って参照するのと機能的には同じでです Tier2をサポートする全デバイスで対応しています 2016年以降のMacとA13バイオニックチップまたはそれ以降のiOSデバイスが対象です
tier2をサポートしているかどうか不明な場合は MTLDevice objectにクエリがあるのでご利用ください Metal 3ではこのような流れになっています CPUから見える構造体を定義バッファアドレスには 64ビット型テクスチャには MTLResourceIDを使用そして引数バッファを確保 MTLDeviceから直接またはMTLHeapから割当可能バッファ内容を取得後引数バッファ構造体型にキャスト構造体メンバーにアドレスとリソースIDを書き込むレンダリングデモでその様子をご覧くださいコードですいかにシンプルであるかにご注目構造体は法線バッファのGPUアドレスを直接保存 64ビット符号なし整数なので uint64_tを使用しましたエンコーダオブジェクトがないので構造体のサイズを引数バッファに使うだけです MetalはClangとシェーダコンパイラの間でGPUと- CPUの構造体のサイズとアライメントの一致を保証
次に通常通りバッファを確保しますバッファストレージモードが ManagedかSharedの場合ダイレクトポインタを取得構造体タイプにキャスト normalsメンバーをgpuAddressに設定 GPUメモリへmustNalignするオフセットを設定
One thing I want to highlight is how the structure declaration changes 注目点はMetal Shading言語とC言語での変化この例ではこれらを分離していますが必要であれば共有ヘッダで構造体宣言を1つにして条件付きコンパイルでシェーダコンパイラの型と Cの型を区別可能です以下はC言語による統一の宣言ですマクロはシェーダーコードのコンパイル時にのみ定義ヘッダ宣言でGPUとCPU コード分離の為使用します AppターゲットがC++の場合この機能を追加可能テンプレートを使って宣言をさらに統一します
引数バッファのサンプルで最適な方法を確認ください 1つの構造体の書き方でした未束縛の配列を使って多くの構造を書くことも可能 Metalでは引数エンコーダで非束縛の配列を実装しました Metal3はさらに処理を簡略化します構造体のoutNan配列をほとんど埋めるだけ
1つの構造体を書く場合と比較し違いを説明します格納する全ての構造体に対しストレージ割当てが必要です配列に対し繰返し処理各構造体のデータを書き込む
コードサンプルに戻りバッファのサイズを拡張シーン内の構造体メッシュの数だけ保存します CPUバッファと全く同じであることに注意ください構造体サイズにメッシュ数を掛けたものですその力強さをこの場を強調しますこの変数ひとつで配列の大きさをコントロール可能シェーダはサイズを宣言する必要はありません Metalシェーダーコンパイラーに渡すとどの位置にも自由にインデックス付けが可能ですバインドレスモデルが柔軟である理由の一部で無制約で配列にアクセスするシェーダを書けるからですそれだけでいいんです！
次にバッファを確保その内容へのポインタを正しいメッシュ構造体の型にキャストします
バッファが十分に大きくなりメッシュ構造体のサイズを- またいで単純なループ処理でバッファを走査します最後に配列の各構造体のGPUAddressと必要ならアライメントされたオフセットを直接設定します
シェーダーでGPU 側から未束縛の配列を表現する1つの方法ですここではメッシュポインターパラメーターとして宣言
これによりC言語の配列と同じように自由に中身にアクセスできます
もう一つは未束縛の配列を構造体に引き込むことですこれでシェーダーは綺麗にデータは一箇所に集約しますこの例ではすべてのメッシュとマテリアルがシーン構造体にまとめられています
シーン構造体を使用するとすべての非束縛配列を個別に渡す代わりに単一のバッファをバインドしシーンをシェーダーに直接渡すことができます
アクセスも以前と同じですがメッシュ配列はシーン構造体を通して到達しています Metal3での引数バッファと非束縛配列の書き方でした APIが一新されCPUの構造体や配列に合わせた直感的な操作が可能になりました今年のアップデートではレイトレーシングのアクセラレーション構造をバッファやテクスチャと一緒にMetal Heapから割当て可能になりました
つまりリソース同士や他のリソースと一緒に集約できるのです全ての加速度構造体をヒープに集約すると useHeap1回の呼び出しで全フラグを常駐可能 Appのレンダースレッドにおいて CPUを大幅に節約する大きなチャンスです
ここでヒープで加速度構造を扱う際のヒントを紹介しますまずヒープから割当てた場合アクセラレーション構造にはデバイス毎にアライメントとサイズ要件がありますヒープ割り当てのための加速度構造体のサイズとアライメントをチェックする新しいクエリーがあります構造体記述子のSizeAndAlignmentは MTLDeviceのheap- AccelerationStructureSizeと AlignWithDescriptorメソッドを用いて決定します MTLDeviceの accelerationStructure- Sizes WithDescriptor- メソッドとは異なることに注意ください
加速度構造体がMTLHeap- オブジェクトになったので useHeapを用い一回の呼び出しで常駐させます個々に対しuseResourceを呼び出すよりも高速ですまたヒープをハザード- トラッキングに選ばない限り Metalは割当てられたリソースの競合状態を防げませんよってacceleration structureのビルドを同期させレイトレーシングの作業と同期させる必要がありますでもご心配なく後で説明いします
Metal 3におけるレイトレーシングの性能向上の詳細については「Metalレイトレーシングのパフォーマンスを最大限に高める」をご覧くださいヒープに割当てられたacceleration structureを用い大事な時AppのCPU使用率を減らせます最後に今年のお気に入りの機能をご紹介しますシェーダー検証の強化です
useResourceとuseHeapについては間接的にアクセスされるすべてのリソースに対して NappsがMetalに残留するフラグを立てることが重要忘れるとレンダリング時にこれらをバックアップするメモリページが存在しない可能性がありますバッファ不具合 GPU再起動画像破損などの危険ですバインドレスではリソースの大半は間接的にアクセスされシェーダは実行時にポインタナビゲーションを決定する残念ながらバインドレスではこうした問題に遭遇する可能性が高い今年のMetal3はシェーダー検証レイヤーに新機能が導入されバッファ実行時にリソースのレジデント不足を突き止めることができるようになりました具体例をお見せしましょう Hybrid RenderingAppのアップデート作業中に反射がおかしくなる問題が実際に発生しましたこれにvalidation layerがどう役立ったかを紹介します
Metalにフラグを立てるため Appロード時にヒープに個々のリソースを可変セットに格納しますこのAppはバッファ追加しテクスチャを追加しますレンダリング時に Appのカーネルをディスパッチ前全リソースに使用するとMetalに指示します Appが集合を繰り返し各要素に対して useResourceを呼出す単純な処理です Metalは全リソースを常駐させてからレイトレーシング作業を開始する Here’s part of the code where the app collects the resources into this set. Appがリソースを集めているコードの一部です App読込み機能は各サブメッシュを繰り返し処理する引数バッファに書き込む必要のあるデータ素材用インデックスデータとテクスチャデータを取得しバッファのアドレスを引数バッファに格納します素材の場合はテクスチャの配列をループして GPUリソースIDを引数バッファに書き込みます最後にサブメッシュのマテリアルからテクスチャをすべてsceneResourcesセットに追加しディスパッチ時に常駐フラグを立てます
残念ながら微妙なバグが存在します Appがコマンドバッファを実行し場合によっては反映が欠けることがありましたこれまでこれを突き止めるのは大変でした Metal3ではシェーダー検証レイヤーが解決してくれますコマンドバッファの実行中に発生したエラーの何が問題なのかがわかるようになりましたエラーメッセージは次のように表示されます問題を引き起こしたシェーダー関数名パス名アクセスを検出したメタルファイルとコード行さらにはバッファのラベルとサイズ常駐していないことまでが表示されます Metalオブジェクトにはラベル付けをお勧めしますツールはラベルを使用する為Appのデバッグ中にそれぞれのオブジェクトを特定できますこのように詳細な情報があればシェーダーコードに不足しているリソースを簡単に発見可能ですさらにデバッグブレークポイントが有効なとき Xcodeはシェーダーコードの中でシェーダー検証が問題を検出した正確な行を都合よく表示しますこの場合欠けているのはインデックスバッファです単純な修正ですねコードの話に戻ると Appが常駐リソースセットに不足しているインデックスバッファを格納するようになりましたこれでレイトレーシング時にインデックスバッファを GPUから利用できこの問題が解決されました必要不可欠なツールかつバインドレスジャーニーによるデバッグ時間を短縮するゲームチェンジャーです Metal3ではバインドレスリソースの整理と参照に役立つ機能が強化されましたさてここからは話題を変えバインドレス化でパフォーマンスを最大化する方法についてお話しますここでは非保持リソースと非追跡リソースの2つのトピックを取り上げますこれ長寿命で集約的なリソースを使用する場合に CPUとGPUから高いパフォーマンスを引出します長寿命リソースでCPU性能を向上させる方法についてまずリソースのライフ- サイクルをおさらいします Objective-CとSwiftでライフサイクルを参照カウント Metalリソースはこのモデルを採用していますリソースはretainCountが1で始まりランタイムは強い参照がなくなり次第リソースを解放 CPUとGPU は並列に動作しているため GPUが資源を使用時にCPUのretainCount が 0になってリソースが解放される問題があります
これを防ぐためMetalのコマンドバッファは使用するすべてのリソースに対して強い参照を作成し retainCountが常に1以上であることを保証しています MetalはsetVertexBufferや setFragmentTextureなどの関数でパイプラインに直接バインドしたリソースに対して強い参照を作成しこれにuseHeap APIを介し常駐フラグを立てたレンダーアタッチメント- Metalヒープオブジェクトも含まれます useResource APIを介し常駐させた間接的リソースはヒープの一部であっても使用できます Metalオブジェクトのライフサイクルの詳細については Program Metal in C++- with metal-cppを参照ください Metalがこれらの参照を作成すると非常に便利ですプログラマーはGPUがまだ使用中のオブジェクトを解放するのではないかと心配する必要がなくなります Metalが提供するこの安全保証は実行速度が速いのですが若干のCPUコストがかかります現在バインドレスモデルでは Appはリソースをヒープに集約ドメインにマッチした長寿命なものになる傾向です例えばゲームではリソースは全レベルの間生きていますこの場合Metalはリソースのライフサイクルについて追加の保証を提供する必要がなくなりますこのCPUコスト回収の為 Metal command buffersNotが参照するリソースを保持するよう依頼することができます
Metalの自動リソース保持をオフにするには非保持参照を持つコマンドバッファを作成するだけです通常のコマンドバッファを作成するのと同じように MTLCommandQueueから直接行えますすでにリソースのライフサイクルを保証している限り Appに他の多くの変更を加える必要はありませんこの設定の最小粒度はコマンドバッファ全体であることに注意ください参照した全リソースを保持又はまったくしないかです
小さなマイクロベンチマークでは参照を保持しないコマンドバッファに切り替えるだけでライフサイクルで2%のCPU使用率減少が可能です小さな勝利ですがこの時間はすべて不必要な強い参照作りと破棄の繰返しに費やされました
要約するとリソースの非保持化でライフサイクルを保証している場合CPUを節約可能と言う事です非保持リソースと同様に非追跡リソースはより高い性能を得るために安全機能を無効化する機会を提供する多くの視覚技術は中間テクスチャへレンダリングとバッファへ書込み後のパスでそれを消費する構成ですシャドウマッピングスキニングなどがその例ですしかしリソースを生成してすぐに消費するとリード・アフター・ライトの危険性が発生しますさらに複数のパスが同じリソースに書き込む場合例えば2つのレンダーパスが同じ添付ファイルに次々と描画したりブリットエンコーダーが2つ同じリソースに書き込んだりする場合です GPUのMetalスケジュールの動作に起因する write-after-writeハザードが発生するからですトラッキングされたリソースを使用する場合Metalは自動で同期プリミティブを使用しハザードを回避します例えばMetalはスキニング計算パスがバッファへの書込みを終了するのをGPUに待たせてから同バッファから読込むシーンレンダリングパスを開始する
素晴らしいですね MetalがgraphicsAPIである理由の大部分を占めますがリソースをヒープに集約する Appのパフォーマンスに- ついてはいくつか考慮すべき点があります
この例で考えてみましょうここではGPUがビジー状態になっていますスキニングレンダリングトーンマッピングを行う2つのフレームを順番に描画します AppがGPUを使用し続けることでMetalは従属性からレンダリングと計算作業が重なる機会を特定従属性なく条件が整えばメタルスケジュールは重なり合い並行で動くようになりますこれでGPUは飽和状態へ同じ壁面クロック時間でより多くの仕事をこなせるようになります
これでAppがリソースをヒープに集約するとサブリソースがMetalに1つとして表示されますこれがヒープの作業効率の良さですしかしMetalが同リソースの読み書きの作業を担当する事意味実際に危険が無くてもレースコンディションを避け保守的に作業をする必要があります
この状況は偽共有と呼ばれ予想通り GPU作業の処理時間を増加させますそこでパフォーマンスのヒントを紹介しますヒープ内のリソース間に従属性がない場合この操作を回避することができます
誤共有を避けリソースをハザード・トラッキングから外し細かい従属性を直接Metalに伝達しますリソース記述子のhazardTracking プロパティをUntracked に設定リソース追跡をオプトアウトできますこれは非常に重要なことなのでヒープのデフォルト動作としゲートからすぐGPUで作業を並列実行する機会を増やせます未追跡のリソースを使用するようになるとプリミティブを使用して従属性を表現します状況に応じFences Event Shared Events Memory Barrierを使用 Metal Fencesは1つのコマンドキュー内で異なるレンダーパスやコンピュートパス間で 1つ以上のリソースへのアクセスを同期させますスプリットバリア方式のプリミティブでプロデューサがフェンスのシグナルを出すまで待ちます
Fencesを使用する際に注意する点は producerコマンドバッファを consumerコマンドバッファより先にcommitまたはenqueueすることですこの順序を保証できない場合あるいは同一機器上の複数のキューを同期させる必要がある場合は MTL Eventsを使用します Eventを使用するとconsumerコマンドバッファは producerコマンドバッファが与えられた値での通知を待つ値を通知した後リソースを読み出しても問題ないですコマンドが通知するまで一時停止するようGPUに指示 MTLSharedEventsは通常の Eventとよく似た動作をするが単一のGPUより大きなスコープで動作しますこれを使い異なるMetalデバイス間さらには CPUとの間でリソースへのアクセスを同期させる例えばGPUの計算結果をCPUから処理する場合は Shared Eventsを使用します以下はその一例です GPUはコンピュートパスでメッシュをスキニングし CPUはディスクにポーズを保存します 2つは独立したデバイスなので GPUがShared Eventを使ってリソース生成するまで CPUが待機するように設定 CPUは無条件にGPUからの Shared Eventシグナルを待ち始めます GPUがリソースを生成してユニファイドメモリに配置 Shared Eventを通知しますここでCPU上で待機するスレッドが立ち上がり安全にリソースを消費する
最後のプリミティブタイプはメモリバリアですこれは1つのレンダリングまたはコンピュートパス内の後続コマンドを前コマンドが終了するまで待機させますバリアのコストは大抵フェンスのコストと同様ですしかし一つ例外があります
レンダーパスのフラグメントステージ後のバリアですこれらのバリアはレンダーパスを分割するのと同じような非常に高いコストを持っています MetalはAppleGPUのフラグメントステージ以降のバリアを無効化 Appを最速ドライバパスに留めますアフターフラグメント-バリアを追加すると Metalのデバッグ層は検証エラーを発生させるほどフラグメントステージ以降のリソースの同期にはフェンスを使用することが推奨されます
ここで同期プリミティブについてどのような場合に使うかを簡単にまとめます Producer Consumerの順で一つのコマンドキューにコミットかエンキューする際オーバーヘッドを最小限に- するために Fencesを使用をお勧めしますフェンスは一般的なケースの大半に最適です送信順序が保証できない場合複数のコマンドキューがある場合はMetal Eventsを使用します Shared Eventsは複数のGPU間およびCPUとの同期を可能にします特定のマルチデバイスの場合にのみ使用くださいパス内で同期を取る場合はメモリバリアを使用します同時計算パスやドロー- コール間の頂点ステージなどほとんどの場合において高速に動作しますただしフラグメントステージ後の同期にはバリアではなくパス間のフェンスを使用することをお勧めしますバリアはコストが高くApple GPUは許容できません
非追跡のリソースと手動での細かなトラッキングにより GPUの並列性を最大限に活用しながらデータ集約のあらゆる利点を享受出来る様になりました以上がバインドレス化の際にCPUとGPUの性能を最大限に引き出すためのコツですこれまでMetal3がいかにシンプルで効率的なワークフローを実現するか何度もお話ししてきましたしかしコードは方程式の半分に過ぎないのですもう半分は利用可能なツールを使って GPUが何を見て仕事を実行するか検証することですここからはMayurにバインドレス用 Metal3ツールの新情報を説明してもらいますありがとう Alè 今日はMetal Debuggerの新機能のうちバインドレス- Appのデバッグと最適化に役立つ話をします先ほどAlèが示したHybridRenderingAppのフレームキャプチャを撮影してみました Metal Debuggerでフレームキャプチャすると Summaryページが表示されフレームの概要とAppのパフォーマンスを向上させる方法に関する有益な情報が提供されますでも今日は新しい\従属性ビューアーを紹介します左側のDependenciesをクリックください新しい従属性ビューアーは強力な新機能を満載した全く新しいデザインを採用しています従属性ビューアーではワークロードをグラフで表示することができますグラフの各ノードはコマンドエンコーダで符号化されたパスとその出力リソースを表すエッジはパス間のリソース従属性を表す今年から新たに2種類の従属性に着目してワークロードを分析できる-ようになりましたデータフローと同期です実線はデータの流れを表しAppの中でデータがどのように流れているかを示しています点線は同期を表しパス間でGPUの同期を導入する従属性を示します詳細は任意のエンコーダーリソースエッジをクリックデバッガーがサイドバーに詳細情報を表示します例えばこのエッジは同期を追加しまたこれらのパス間のデータフローを持つデフォルトでは従属性ビューアにはデータフローと同期両方の従属性が表示されますしかしこの下にあるメニューを使えば従属性のタイプを1つに絞ることができますここでは同期だけに絞って説明します Alèが述べたようにtracked heapから異なるリソースを読書きする場合 false sharingが問題です従属性ビューアーを使えば問題を簡単に発見できますキャプチャしたこのデモはこの問題がある開発初期のバージョンですこのヒープをクリックすると従属ビューアーにこのヒープが追跡されていることが表示されるのでこれらの2つのパスの間に同期が追加されます従属性ビューアはエンコーダーが保存するターゲットテクスチャーやエンコーダーが読書きするバッファなど割当てられたリソースも強調表示します問題はエンコーダが以前のエンコーダからのリソースを未使用で2つのパス間同期が不必要な事ですこの従属性を消すにはAppを修正し非追跡ヒープを使用し同期が必要な場所にFencesを挿入この変更により2つのパスが並列に動作します Xcode14ではバインドレスAppのデバッグに役立つ他の改良点は新しいリソース・リストですデバッグするドローコールに移動し開くことができますバインドレスを使用する場合GPUは常に数百数千のリソースを利用できます今年のMetalデバッガでは上部のAccessedモードをクリックするだけでドローコールがこれらのリソースのどれにアクセスしたか確認できますデバッガにはドローコールがアクセスするリソースと各アクセスのタイプのみ表示されるようになりましたこれはシェーダーが引数バッファからどのリソースにアクセスしたかを理解するのに便利ですドローコールが使用するリソースの把握は重要ですが予期しないリソースが表示された場合シェーダーデバッガーの状況を把握できますシェーダーデバッガーを起動するにはボトムバーのデバッグ-ボタンをクリックしデバッグしたいピクセルを選択してデバッグボタンをクリックするだけですそして今シェーダー-デバッガーにいますシェーダーデバッガーはコードがどう実行されたかをどのリソースにアクセス- したかを含めて一行ずつ表示このシェーダは引数バッファからテクスチャを読込む右サイドバーの詳細ビューを展開するとどのリソースが読まれたかを確認することができますこれはシェーダが間違った引数バッファ要素にアクセスする問題を特定するのに役立ちますこのデモでは新しい従属性ビューアーを使ってリソースの従属性を分析・検証する方法新しいリソースリストを使って描画コールがアクセスしたリソースを理解する方法そしてシェーダー-デバッガを使ってシェーダーの実行方法を1行ずつ分析する方法を紹介しましたこれらの新機能を使って皆さんが素晴らしいメタルバインドレス- Appを作るのか楽しみです再びAlèに託しますありがとうMayur素晴らしいデモでしたね Metal3はバインドレス実現に役立ちます引数バッファの簡略化ヒープからの加速度構造検証層Nandツールの改善など Metal 3はゲームやAppに効果的でハイパフォーマンスのバインドレスを実現します今年の機能強化でHybrid- Rendering Appが改善されましたこの最新版のAppは Metal sample code galleryで完全なソースコード付きで公開されていますこれをダウンロードして勉強し修正しさらに練習として鏡面に再帰的な反射を加えることに挑戦してみてください皆さんの活用が楽しみです Metal3でバインドレスを実現する絶好の機会ですご視聴ありがとうございます

5:38 - Write argument buffers in Metal 3

// Write argument buffers in Metal 3

struct Mesh
{
   uint64_t normals; // 64-bit uint for constant packed_float3*
};

NSUInteger meshArgumentSize = sizeof(struct Mesh);

id<MTLBuffer> meshArgumentBuffer = [device newBufferWithLength:meshArgumentSize
                                                       options:storageMode];

struct Mesh* meshes = (struct Mesh *)(meshArgumentBuffer.contents); 
 
meshes->normals = normalBuffer.gpuAddress + normalBufferOffset;

6:31 - // Shader struct:

// Shader struct:

struct Mesh
{
   constant packed_float3* normals;
};

// Host-side struct:

struct Mesh
{
    uint64_t normals;
};

6:53 - Shared struct:

// Shared struct:

#if __METAL_VERSION__
#define CONSTANT_PTR(x) constant x*
#else
#define CONSTANT_PTR(x) uint64_t
#endif

struct Mesh
{
    CONSTANT_PTR(packed_float3) normals;
};

7:53 - Write unbounded arrays of resources in Metal 3

// Write unbounded arrays of resources in Metal 3

struct Mesh
{
   uint64_t normals; // 64-bit uint for constant packed_float3*
};

NSUInteger meshArgumentSize = sizeof(struct Mesh) * meshes.count;

id<MTLBuffer> meshArgumentBuffer = [device newBufferWithLength:meshArgumentSize
                                                        options:storageMode];

struct Mesh* meshes = (struct Mesh *)(meshArgumentBuffer.contents); 

for ( NSUInteger i = 0; i < meshes.count; ++i )
{
   meshes[i].normals = normalBuffers[i].gpuAddress + normalBufferOffsets[i];
}

9:03 - Metal shading language: unbounded arrays option 1

// Metal shading language:

struct Mesh
{
   constant packed_float3* normals;
};


fragment half4 fragmentShader(ColorInOut v          [[stage_in]],
                              constant Mesh* meshes [[buffer(0)]] )
{
    /* determine mesh to read, e.g. geometry_id */

    packed_float3 n0 = meshes[ geometry_id ].normals[0];
    packed_float3 n1 = meshes[ geometry_id ].normals[1];
    packed_float3 n2 = meshes[ geometry_id ].normals[2];

    /* interpolate normals and calculate shading */
}

9:25 - Metal shading language: unbounded arrays option 2

// Metal shading language:
struct Mesh
{
   constant packed_float3* normals;
};

struct Scene
{
   constant Mesh*     meshes;     // mesh array
   constant Material* materials;  // material array
};

fragment half4 fragmentShader(ColorInOut v          [[stage_in]],
                              constant Scene& scene [[buffer(0)]] )
{
    /* determine mesh to read, e.g. geometry_id */
    packed_float3 n0 = scene.meshes[ geometry_id ].normals[0];
    packed_float3 n1 = scene.meshes[ geometry_id ].normals[1];
    packed_float3 n2 = scene.meshes[ geometry_id ].normals[2];
    /* interpolate normals and calculate shading */
}

11:00 - Size and alignment for MTLAccelerationStructure in a MTLHeap
```
heapAccelerationStructureSizeAndAlignWithDescriptor:
```

13:49 - Store individual indirect resources in NSMutableSet

// Argument buffer loading
for (NSUInteger i = 0; i < mesh.submeshes.count; ++i) {

    Submesh*      submesh     = mesh.submeshes[i];
    id<MTLBuffer> indexBuffer = submesh.indexBuffer;
    NSArray*      textures    = submesh.textures;

    // Copy index buffer into argument buffer
   submeshAB[i].indices = indexBuffer.gpuAddress;

    // Copy material textures into argument buffer
   for (NSUInteger m = 0; m < textures.count; ++m) {
        submeshAB[i].textures[m] = textures[m].gpuResourceID;
    }

    // Remember indirect resources
    [sceneResources addObject:indexBuffer];
    [sceneResources addObjectsFromArray:textures];
}

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

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

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21