Metalのデバッグ、プロファイリング、アセット作成ツール

Metalのデバッグ、プロファイリング、アセット作成ツール

Xcodeを使用して、Metalのデバッグ、プロファイリング、アセット作成のワークフローを次のレベルに引き上げる方法を紹介します。レイトレーシングとGPUプロファイリングのための最新ツールを確認し、Metalデバッガのワークフローについて確認します。また、最新のGPUテクスチャフォーマットをすべてサポートし、マルチプラットフォームのアセット作成パイプラインに簡単に統合できるテクスチャコンバータツールの使用方法も紹介します。

リソース
関連ビデオ

WWDC23
- Macへのゲーム展開 Part 3：Metalでのレンダリング
- RealityKit Traceについて
WWDC22
- ゲームのメモリをプロファイリングして最適化する
- Metalレイトレーシングのパフォーマンスを最大限に高める
WWDC21
WWDC20
ダウンロード

こんにちは EGorです本日はMetal Debuggerのすべての改善点と新機能についてお話しさせていただきます今年はレイトレーシングや関数ポインタなどの Metal機能のさらなるサポートを提供します
Appleプラッフォーム全体で GPUを活用できるよう GPU Timelineや一貫したGPUパフォーマンスなど最新のプロファイリングワークフローを追加しました
我々はシェーダー検証のより広範なサポートや精密なキャプチャコントロールを含むその他のデバッギングワークフローを改善しました
またテクスチャ圧縮の進展についても後ほど同僚のアマンダがお話ししますまずはレイトレーシングから始めましょう去年新しいMetal レイトレーシングAPIをご紹介し現在 Xcode 13ではシェーダーに柔軟性をもたらす関数ポインタと関数表そして高度に抽象化され再使用可能なシェーダーライブラリコードを構築する方法を提供するダイナミックライブラリを Metal Debuggerでサポートしていますまたレイトレーシング向けに Acceleration Structure Viewerという真新しいツールを発表します Metal Debuggerのレイトレーシングをご覧ください ModernRendererサンプルAppの GPUトレースを開きました Metalレイトレーシングを使用しシャドウや環境遮蔽などの効果を得るために変更されています美しいシャドウマップが作成されていますバインドリソースで加速構造が確認できるようディスパッチコールを選択しましたここから加速構造を開き新しい加速構造ビューアーに移動します右側にはよくあるビストロの光景の幾何学左にはその概要が表示されていますインスタンスをクリックするとそれがビューアーとシーン概要で選択されますそれを拡大すると変革行列やその他のインスタンスプロパティを確認できますオプションキーを押しながらシーンビューアーをクリックすると個々の幾何学の選択もできますシーン概要で選択できその逆も可能です
またビューワーにある加速構造で使用された関連の交差関数の確認も行えますしかし加速構造ビューアーは幾何学を表示するためだけのものではありません右下にはシーンのプロパティを視覚化するのに役立ついくつかのモードがありますたとえばバウンディングボリュームトラバースモードは幾何学の複雑性を視覚化するのに役立ちます色の濃い部分はバウンディングボリューム階層のトラバースが他の部分と比べて比較的計算的に高価になることを示していますシーンの異なる部分にポインタを移動させるとすべてのモード向けに関連の情報を表示する小さなビューがありますここにはバウンディングボックストラバースの数とプリミティブ交差が表示されています
さらなる柔軟性を提供するためにトラバース設定も含みましたこれを使用すればシェーダー内の交差オブジェクトにある同じプロパティを使用して加速構造ビューアーを構成できます
レイトレーシングに関してはお話することがたくさんありますこの詳細については「Metalレイトレーシングによるハイブリッドレンダリング」一般的なAPIの詳細については去年の「Metalを使用したレイトレーシング入門」をご覧ください次はプロファイリングについてです Appのプロファイリングは重要なステップですでにたくさんのすばらしいツールが利用可能ですたとえば Instrumentの Metalシステムトレースを使用すると異なるレンダリングステージ GPUカウンターシェーダータイムラインの CPUとGPUの時間を示すタイムラインビューを探ることができます Metal Debuggerでは GPUカウンターはエンコーダーかドローごとで GPUから直接豊富な一連の測定を表示しますどちらのツールもAppのパフォーマンスの補完的なビューを提供するすばらしいツールですしかしビューの調整には追加の努力が必要ですそこでご紹介したいのが Metalシステムトレースと GPUカウンターが組み合わさった新しいGPUプロファイリングツールです Metal DebuggerのGPU Timelineは Apple GPUs専用に設計された新しいツールでパフォーマンスデータに対し新しい観点を与えてくれ Appの最適化のポテンシャルポイントの発見に役立ちますでは当社一連のプロファイリングツールの最新製品を見てみましょう
GPU Timelineはパフォーマンスパネルからアクセスできます Appからフレームをキャプチャした後デバッグナビゲータで見つかりますパフォーマンスパネルを開くと一連の異なるトラックが平行に表示されます続ける前にエンコーダートラックが平行である理由をご説明します Apple GPUでは異なるレンダーパスの頂点とフラグメントステージ計算ディスパッチは同時に実行できますこれはApple GPUアーキテクチャにより有効化され “tile-based deffered rendering”と呼ばれるレンダリング技術を使用します Appのコンテキストで Apple GPUの平行な性質をご確認いただくのが重要だと思いましたここでGPU Timelineが役立ちます上部にあるのは頂点フラグメント計算エンコーダータイムラインで各エンコーダが使用するリソースを一覧できますエンコーダーの下には稼働率帯域幅リミッタカウンタがありますエンコーダータイムラインを見てみましょう
各エンコーダートラックを拡大して集約されたシェーダータイムラインを確認できます
タイムラインをさらに拡大すると個別のシェーダーが滝のような形で表示されます
エンコーダーの移動は簡単ですエンコーダートラックを選択して右のすべてのエンコーダーを表示しますここでは平均時間でソートできます個々のエンコーダーをクリックするとサイドバーに詳細が表示されますたとえばここではこのレンダーコマンドエンコーダーの添付ファイルを確認できます
エンコーダーを選択するとアクティブな時間範囲がトラック全体で強調されますこれで異なるステージのオーバーラップの検証やエンコーダーのカウンター値の関係付けが簡単に行えます
タイムラインビューから離れカウンタータブに切り替えて GPUカウンターにアクセスするかエンコーダーのコンテキストメニューを開きそこからカウンターで開くこともできます
これはGPU Timelineのプレビューです Metal Debuggerで Appのパフォーマンスを把握する方法については「Apple GPU向けのハイエンドゲームの最適化」をご覧ください
新しいプロファイリング方法をお見せしたところでそのパフォーマンスがいくつかの要因に依存することを理解することが重要です
Metalについてお話しする時 GPUパフォーマンスの状態は非常に重要な要因ですオペレーティングシステムにより管理されデバイスの熱システム設定 GPUの活用その他のパラメータにより下がったり上がったりします
状態の変化は確認するプロファイリングの結果に影響を与えます
今年我々はより一貫した結果でAppをプロファイリングする新しい方法をご紹介します Metalツール全体で GPU Performance Stateを確認し変更できる方法を追加しましたまずライブパフォーマンスの録音に Instruments および Metalシステムトレース Metal Debuggerは GPUトレースのプロファイリングに最後に Xcodeの Device conditionsは一般的なユースケース用ですではInstrumentsから始めましょう今年我々はGPU performance stateのトラックを Metalシステムトレースに追加しました他のトラックと連結して使用し Appのパフォーマンスとデバイスのパフォーマンス状態を関連付けましょうでもお忘れなくパフォーマンス状態を確認できるということは一部の要素にすぎません一貫した再生産可能なプロファイリングを成功させるにはデバイスに GPU Performance Stateを設定する必要があります今年新しくご紹介するのは Instrumentsでトレースを録音中に特定のGPU Performance Stateを誘導する機能です録音オプションにアクセスし録音が始まる前に Peformance Stateを選択しその後通常通りトレースを録音します Instrumentsはデバイスが持続できる場合トレース中に選択する状態を誘導します時々既存のInstrumentsトレースに録音中に誘導された GPU Performance Stateがあるかを確認する必要がありますこの情報は情報ポップオーバーの録音設定セクションで確認できます
では Instrumentsから GPU Performance Stateを確認し誘導する方法についてです一貫したGPU Performance Stateを活用する２つ目の方法は Metal Debuggerを使用する方法です AppのGPUトレースをキャプチャする際デフォルトではXcodeがプロファイリングを行いますこれはキャプチャ時のデバイスのパフォーマンス状態と同じ状態で行われますこの状態は先述の要因により変動する場合があります代わりに自分で特定のパフォーマンス状態を選択したい場合はデバッグバーのストップウォッチボタンを使用します選択後 Metal Debuggerが再プロファイリングされ完了後ボタンがハイライトされて一貫したパフォーマンス状態の達成を表示しますまたサマリーページの“パフォーマンス”に新しいパフォーマンスデータと選択したパフォーマンス状態が表示されますこの２つの方法は一連の Metalツールと関係しますがプロファイリングワークフローとは別に一貫したパフォーマンス状態を誘導したい場合もあります GPU performance stateを設定する３つ目の方法は Device conditionsを介した方法です
Appが異なる GPU Performance Stateでどう機能するかを確認したい場合はこの方法が最適です Xcode 13では GPU Performance State Device conditionが追加されています持続可能で Xcodeに接続されている限りオペレーティングシステムに特定の状態を使用することを強制します Xcodeからこの条件を追加できます WindowでDevices and Simulatorsに行きデバイスを選択します “Device Conditions”にスクロールし希望するレベルの “GPU パフォーマンス状態”を追加しますをクリックして GPU performance stateの変更を適用します完了したらをクリックします
我々のツールから直接 GPU Performance Stateを確認しこれらの方法は変更可能なので Appのプロファイリングとテストに役立つでしょうプロファイリングワークフローの最新製品と改善を気に入っていただけると思います皆さんのAppがさらに向上することを願いますでは今年のMetal Debuggerのその他の改善をご紹介しましょうまずはシェーダー検証の改善についてです次に精密なキャプチャコントロールその後に新しいパイプラインステートワークフローをご紹介します最後はシェーダーデバッギングとプロファイリングの新しい２つの機能について分離デバッグ情報と選択的シェーダーデバッギングです去年 Xcode 1で境界を超えたアクセスなど GPUのランタイムエラーの診断に役立つシェーダー検証を発表しました
シェーダー検証が有効になりエンコーダーに検証エラーが発生すると問題ナビゲーターにランタイムエラーが発生し呼び出しに失敗したCPUとGPUのバックトレースが表示されます
これは別のセッションで詳細に説明されていますシェーダー検証の詳細を学びたい場合は「MetalでGPUのエラーをデバッグする」という去年のトークをご覧ください
今年はシェーダー検証を拡張してより多くのユースケースをサポートし関節コマンドバッファダイナミックライブラリ関数ポインタと表を使用する際に利用可能にしましたこれでAppの開発中にシェーダー検証をより広範囲に使用できるはずです次は新しい精密キャプチャコントロールをご紹介しますまずはキャプチャボタンを見て下さい Metalのロゴのようになっています Xcodeウィンドウの下部のデバッグバーにありますこれをクリックすると新しいメニューが表示されここでキャプチャのスコープを選択しますデフォルトでは１フレームのキャプチャですですがキャプチャしたい数を最大５まで選択できます親デバイスまたはコマンドキューが同じのコマンドバッファのキャプチャ特定のMetalレイヤを表すものや MTLCaptureScope APIを使用して Appのコードを定義できるカスタムスコープも選択することができますこれらの新しいコントロールでいつどのようにMetal コールがキャプチャされるかすぐに決断できるようになります
次はMetalライブラリとパイプラインステートです Metal Appに欠かせない要素です Xcode 13では Appが使用するパイプラインステートとライブラリの検査がこれまで以上に簡単になりました実際に見てみましょうここではModernRenderer サンプルAppから GPUトレースをキャプチャしました GBufferパイプラインステートの仕組みを知りたくこのドローコールを選択しましたバインドリソースを見ると使用されたパイプラインステートが確認できますそれを開くとパイプラインステートビューアーが開きここで関数を調査し他のプロパティを確認しますさらにビューアーでステートに関連するパフォーマンスデータを確認するかメモリビューアーからステートを確認します Xcode 13ではメモリビューアーにパイプラインステートがAppで消費するメモリ量が表示されますこれらはAppのGPUトレースを確認する際 Metal Debugger全体でパイプラインステートの検査を容易にするいくつかの追加機能です次はMetal Debuggerのシェーダーデバッギングとプロファイリングについてです現在これらの機能を使用するには選択肢が２つあります１つ目は Appの実行中にソースコードからライブラリをコンパイルする方法２つ目はより最適な方法で Metallibファイルをオフラインで組み込まれたソースで構築しこれらをランタイムで読み込む方法ですしかしApp Storeのルールは AppをデバッグのMetallibで公開することを許可していませんつまりライブラリをオフラインでコンパイルしシェーダーをデバッグしたい場合二度コンパイルする必要がありました一度目は開発中に組み込まれたソースを使い配信向けにはソースなしでコンパイルします今年はこれを変更します Metallibのコンパイル中にソースのある別のファイルと他のデバッギング情報を生成できるようになりましたこれらのファイルには Metallibsym拡張子がありライブラリに追加情報を組み込むことなくシェーダーのデバッグとプロファイリングが行えるようになります別々に持つことの最大のメリットは２つのバージョンの同じMetallibを持つ必要がなくなったという点ですもう１つのメリットは Metallibsymファイルでシェーダーソースを妥協することなく Appのリリースバージョンのシェーダーのデバッグが可能になる点です
シェーダーソースファイルを Metallibsymファイルと共に Metallibにコンパイルする方法の例をお見せしましょう Metallibをコンパイルする xcrunターミナルコマンドで始めます Metallibsymファイルを生成するには “record-sources”のフラグと “flat”のオプションを追加しコンパイラを実行するだけです別のデバッグ情報ファイルにコンパイルされたシェーダーをデバッグしようとするとインポートするようプロンプトされますソースをインポートをクリックするとすべてのライブラリを表示するダイアログが開きソースファイルがインポートされたかを確認できます
ここでMetallibsym ファイルをインポートしインポートが完了したらライブラリとソースが自動的に一致されます
インポートを完了したらダイアログを閉じシェーダーのソースを確認しデバッグします
あともう１つデバッギングの改善をご紹介しますそれは“選択的シェーダーデバッギング”です Appが大型のシェーダーを使用する場合シェーダーのデバッギングの開始に時間がかかることにお気づきでしょうこれを改善するために選択的シェーダーデバッギングを提供しますデバッグスコープを限定しシェーダーをより迅速にデバッグするのに便利ですではこれを実際に見てみましょう
GPU ASTCDecoderをデバッグしたいとしますでもこのカーネル全体をデバッグしようとするとシェーダーデバッグ開始に時間がかかりますそれほど長く待ちたくありませんなので代わりにデバッグスコープをこの decodeIntegerSequence 関数だけに限定しますそれを行うには右クリックして関数のデバッグを選択すると “デバッグする関数”メニューが開きます関数スコープはすでに選択されていますデバッガーがほぼすぐに開始します
選択的シェーダーデバッギングは巨大なシェーダーのバグをすばやく突き止めるのに役立ちます Metalツールの改善についての報告は以上です次はアマンダがテクスチャ圧縮の進展についてお話ししますアマンダ？ EGor ありがとうテクスチャ圧縮ツールの最新情報についてお話ししますツールの話をする前に Appleプラッフォームのテクスチャ圧縮の基本について手短にご説明しますこの場合のテクスチャ圧縮は定率でロッシー圧縮されたテクスチャデータですこれはデカールやノーマルマッピングなど静的テクスチャデータのオフライン圧縮を主に意図としたものですランタイムで動的テクスチャデータを圧縮できますが本日はそのことについては触れませんほとんどのテクスチャ圧縮はテクスチャをブロックに分割し各ブロックを色のペアとして圧縮することで作用しますこのペアはこれらのエンドポイントから挿入された他の色を含むローカライズされたパレットとパレットから選択する毎ピクセルのインデックスを定義します各フォーマットは強度が異なり異なるテクスチャデータに適合しますまた Apple GPUは A12以降で無損失のフレームバッファをサポートし帯域幅の最適化に非常に便利です去年の「GPUカウンタを使った Metal Appとゲームの最適化」をご覧ください AppのGPUが使用するメモリ帯域の測定方法の詳細が学べますもう１つのオプションはこのプレゼンでお話しする GPUテクスチャ圧縮の上のテクスチャファイルの無損失圧縮の実行ですこれによりAppのダウンロードのサイズをさらに削減できますテクスチャ圧縮についてご説明したところでテクスチャ圧縮がAppに提供するメリットについてお話ししますテクスチャ圧縮はAppの開発に関して重要なステップです一般的にほとんどのゲームのメモリフットプリントにはテクスチャが含まれていますテクスチャ圧縮を使用すればより多くのテクスチャをメモリに読み込め詳細なテクスチャを使用することで視覚的により感動的なゲームを制作できますまた圧縮は Appのサイズとメモリフットプリントを削減します基本について説明したところで Appleプラッフォームの圧縮ツールの現状況をお知らせします iOS SDKの既存のTextureToolのパイプラインは比較的シンプルです TextureToolは入力画像を読み込み必要に応じてミップマップを生成しブロックごとにテクスチャを圧縮し新しい出力ファイルに結果を書き込みますしかしグラフィックスのアルゴリズムが複雑になるとより高度なテクスチャの処理が必要となりますこれらの処理は正確な色空間で演算を実行しながら数値精度の間の変換の四捨五入を最小限に抑えますこれを把握するために TextureConverterという高度なテクスチャ処理の必要性に対処し多くの新しいオプションへのアクセスを提供する新しい圧縮ツールを設計しました我々がAppleプラッフォームのテクスチャ処理パイプラインをどのように改良したかをご覧くださいテクスチャ処理パイプラインは一から再構築され TextureConverterで完全機能のテクスチャ処理パイプラインにアクセス可能になりました TextureConverterは業界で高く認識されている一連の圧縮機を活用し広範囲の圧縮形式をサポートし圧縮速度と画像品質の間でトレードオフを提供します圧縮機を指定するか TextureConverterが圧縮形式品質レベルやその他のオプションを基に選択することもできますそれぞれのステージは皆さんが完全に設定できガンマを意識したテクスチャ処理を行いますすべての統合をサポートするために TextureConverterはmacOSと Windowsの両方で利用可能で Apple Siliconの使用に最適化されています拡大されたパイプラインの各ステップを見てみましょうガンマから始めますガンマ補正は非線型演算で画像の輝度のエンコードとデコードを行いますテクスチャは多くのガンマ空間でエンコードできます最適な選択はテクスチャが表すデータの種類によりますデカールやライトマップなどほとんどの視覚データは RGBなどの非線型空間でエンコードされるのが最適ですノーマルマッピングなど非視覚データは線型空間でエンコードされるべきですこの選択は必要な場合暗い領域で精密性を提供しますノーマルマッピングなどの非視覚データは線型空間でエンコードされるべきです圧縮は目標の色空間で“gamma_in” “gamma_out”と指定して実行されるべきです線型空間にフロート値を入力するか “sRGB”ストリングを使用し色空間を指定します異なる目標空間の変換にもこれらのオプションを使用する柔軟性がありますミップマップ生成などのその他の演算は線型空間で実行されるべきですでは線型空間の処理ステージをご説明します
入力が線型ガンマ空間に変換されたところで線型空間演算は入力テクスチャが指定の目標ガンマ空間に変換される前に実行されます３つのステージは物理的変換ミップマップ生成アルファ処理でサブステージがあるものもあります物理的変換から始めましょう最大サイズを軸に定義することで必要に応じて高水準のミップマップ向けに画像を縮小できますこのステージではリサイズフィルタとリサイズ丸めモードの調整が可能ですリサイズフィルタは異なるアルゴリズムを使用し寸法を縮小する際のミップマップの不鮮明さの削減をサポートしますリサイズ丸めモードは画像のサイズを変更する際に max_extentと共に使用されます max_extentを超えた場合ソース画像は元の画像サイズを維持しサイズが変更されます丸め指定モードは目標の次元を見つける場合に使用されますどの機能を使用すればいいかわからない場合はほとんどのケースに適合するデフォルトモードがありますそしてこのステージのflipオプションならＸＹＧ軸の線型変換を完全に操作できます変換完了後はミップマップ生成ですこれは一般的なテキスチャ処理に使用されますミップマップは事前計算された画像配列でその配列で解像度を下げレンダリングの高速化とエイリアシングの削減に使用します各レベルの高さと幅は前レベルよりも２の累乗小さくなります
ミップマップ生成をカスタマイズする場合希望の最大数と使用するミップフィルタを指定します TextureConverterはカイザーを使用し “box”と“triangle”のオプションがあります
線型処理の最後のステージはアルファ処理です
alpha to coverageが有効になると指定したアルファレファレンス値を使用しこれが最初に適用されます Alpha to coverageはカバレッジマスクでアルファブレンドを置換えアンチエイリアシングか半透明テキスチャが使用された場合 order-independent transparencyを使用できゲームで密度の高い緑地をレンダリングする際に便利ですこの後アルファチャンネルの放棄保存プリマルチプライオプションが表示されますプリマルチプライアルファでは画像の部分的に透明なピクセルはマットカラーでプリマルチプライされます
線型空間ステージの終了時に目標のガンマ空間に戻り処理されたミップレベルを圧縮する準備ができます
テキスチャ圧縮の最後のステップは圧縮です圧縮ステージはチャネルマッピングとエンコーディングの２つのサブステージに分割できますチャネルマッピングは一般的な目的のテキスチャ圧縮アルゴリズムを特定のデータ種類に最適化する技術です
TextureConverterでの指定はオプションです TextureConverterを使用したい場合は現在 RGBMとノーマルマッピングエンコーディングの２つのモードをサポートしています両方のフォーマットを詳細に説明しましょうまずはRGBMエンコーディングから RGBMエンコーディングはアルファチャネルでマルチプライヤを保管してこのマルチプライヤでRGBチャネルをスケーリングしHDRデータを圧縮する技術ですこちらは教室のHDR画像の例ですこちらは同じ教室の画像ですがアルファチャネルにマルチプライヤが保管されグレースケールで表示されています RGBMをエンコードするためにマルチプライヤを計算する方法をコードで説明します EncodeRGBMは簡素化された擬似コードの関数です RGBMエンコーディングの仕組みを理解できるよう詳細にご説明しますこのスニペットはRGBMの範囲をデフォルトの6.0に設定する真新しいパラメーター RGBM_Rangeを含んでいます RGBMアルファ値マルチプライヤを計算するためにまず入力テキスチャの赤緑青のチャネルの最大を判断しますこれはMetalのmax3関数で行います次にこの最大が RGBM_Rangeで除算されますエンコードされたRGBMの赤緑青チャネルの値を計算するにはまず以前に計算されたマルチプライヤがアルファチャンネルのストレージの値をスケーリングするのに使用された RGBM_Rangeで乗算され直します次に入力テキスチャが最終マルチプライヤ値で除算されますシェーダーのRGBMをデコードするにはエンコーディング関数でお見せしたようにサンプルのRGBをアルファと固定係数で乗算します DecodeRGBMコードスニペットでこのやり方をお見せします基準化因子はRGBM_Rangeによりマルチプライヤが保管されている RGBMアルファチャネルを乗算して再計算されます元のテキスチャのRGBは計算されたマルチプライヤで RGBMサンプルを乗算して計算されます RGBMエンコーディングをご紹介したところでノーマルマッピングエンコーディングに移りますノーマルマッピングについて言及する場合ほとんどは object-space normal mapsを意味しています object-spaceでノーマルをエンコーディングする場合各ノーマルは単位ベクトルでこれには２つの軸を表しランタイムで３つ目の軸を自明に誘導できるというメリットがありますこれによりテクスチャ圧縮アルゴリズムを最大限に活用するためのこの２つのチャネルのリマッピングが可能になり XYZをRGBとして圧縮するよりもはるかにすばらしい圧縮を実現できますチャネルのリマッピングの方法は圧縮形式により異なりますこのチャートをガイドとしてASTCでノーマルをエンコーディングする例をお見せしましょう ASTCでエンコーディングする場合赤緑青のチャネルはＸ成分に設定されアルファチャネルはＹ成分に設定されます色はエンコードされたノーマルをサンプルする際にＸとＹ成分が再割り当てするチャネルに対応します TextureConverterはノーマルマップのパラメータをパスした場合選択した形式に自動的にエンコーディングをリマッピングしてくれますシェーダーでノーマルをサンプリングする場合チャネルマッピングを知っておくのは重要ですＸ成分は赤かアルファチャネルから読み込まれＹ成分は圧縮形式によってアルファか緑のチャンネルから読み込まれます ASTCの例から戻りテクスチャをサンプルする場合ノーマルのエンコード方法とは逆にＸ成分は赤のチャネルからＹ成分はアルファチャネルからサンプリングされますすべてのデバイスで可能な限り最高の品質を達成するために複数の形式にエンコーディングする場合ランタイムでこのマッピングに対処する必要がありますではランタイムノーマルサンプリングの例を Metal texture swizzlesを使ってお見せします複数の形式へのエンコーディングは異なる形式が異なるチャネルマッピングを使用する場合複数のシェーダー変数につながる場合がありますこれを回避するためにテクスチャにカスタム Swizzlesを適用できます Swizzlesを使えばＸとＹ成分を赤と緑のチャネルにリマッピングできるのでシェーダーはニュートラルな圧縮形式になれますこれは先ほど図形でお見せした ASTCで圧縮されたノーマルマップの赤と緑へのチャネルのリマッピングの例ですテキスチャ記述が起動した後赤のチャネルは MTLTextureSwizzleRedに緑はMTLTextureSwizzle Alphaに設定されます
これはノーマルマップなのでサンプリングに必要なチャネルは２つのみです赤と緑のチャネルは元々赤とアルファチャンネルにエンコードされたＸとＹ成分に割り当てられたため青とアルファチャネルは０に設定されていますこれが完了したら最後の行は MTLTexture SwizzleChannelsMakeを使いリマップされたチャネルで最後のSwizzleをアセンブルするものですＸとＹチャネルがシェーダーにサンプルされたらＺ成分を再構築できます ReconstructNormal関数の方法をお見せしましょう
まずコードはＸとＹ成分を正確な範囲に再バイアスします通常これは -１～１です次のステップは１からＸとＹ成分のドット積を減算しドット積の結果が正確なサインであるかを確認します次に０～１の範囲のこの結果を固定するために飽和度関数が使用されます最後のステップのＺ成分の計算は飽和度関数の出力の平方根を取ることです
ではチャネルマッピングで利用可能なRGBMとノーマルマップエンコーディングを説明したところで最後にテキスチャ圧縮パイプラインと最終圧縮サブステートエンコーディングについてお話ししますすべてのTextureConverter コマンド行には目標圧縮形式の指定と compression_formatの引数が必要になります仕様する圧縮機を指定するか選択した圧縮形式とその他のオプションの基づき TextureConverterに選択させることも可能ですまた４つのオプションから圧縮の質を選択することもできます圧縮速度と画像品質のトレードオフが生じることにご注意くださいまたゲームでイテレーションを行う場合は低品質の圧縮を選んでも構いませんがリリース用には最高品質を選ぶことをおすすめしますでは選択可能な圧縮形式をご紹介しましょう
こちらが Appleプラッフォームでサポートされている圧縮形式の一覧です iOSとApple Silicon platformは ASTCとPVRTC系をサポートし macOSプラッフォームは BCn系をサポートします各形式系の詳細を説明しニーズに適った製品を選択するためのガイドラインをご提供しますまずはBCn形式から BCnは７つの形式からなりすべて4x4ピクセルブロックと各ピクセルに４または８ビット使用して演算します各形式は異なるデータ形式に適合します BCとBC3は一般的に RGBとRGBA圧縮に使用され BC6はHDR画像向け個別のデュアルチャネルが付いたBC5は通常のマップエンコーディングに最適です次は ASTCです LDR sRGBHDR色空間系の RGBA形式ですこの形式はあらゆるサイズに対し最高品質を提供するので PVRTCよりも一般的に推奨されています各形式の品質に対しピクセルごとのビット範囲があります
ASTCなら各ブロックのバイトサイズは形式に関係なくすべて同じですが表示するテキスト数は異なりますこれは最高品質の圧縮の間で連続体を提供してくれますが４X４のブロックサイズで最低圧縮率を提供し最低圧縮品質に対し 12X12ブロックサイズで最高圧縮率を提供します LDR sRGB HDR変数は圧縮されたASTCテキスチャの色の範囲を説明します LDRとsRGBは共に０～１の範囲で線型またはsRGB空間です一方でHDR変数は０～１範囲外のデータ用です
最後に PVRTC形式は２または４ビットモードの RGBとRGBAで利用可能ですこの形式のデータブロックは常に８バイト占有するので２ビットモードの場合各8X4ピクセルに対し１ブロックとなり４ビットモードでは各4X4ピクセルに対し１ブロックとなります
対応の形式系をご紹介したところで推奨の形式をご紹介します iOSデバイスにはデフォルトで ASTC圧縮をご使用ください A7 GPU以前をサポートする場合のみ PVRTC圧縮とデバイスごとの細線化を追加します HDRテクスチャがある場合は A13とそれ以降のGPUで ASTC HDRを活用できます macOSでは全体的に BCnをご利用いただけます Apple Silicon Macでは ASTCを使用するオプションもあります iOSデバイスをターゲットにする場合はこのオプションを考慮するべきでしょう PVRTCはApple Siliconでもご利用いただけますがこのオプションは推奨しませんこれは iOSレガシーサポート向けです各圧縮形式系にはさまざまな形式があり Appに最も効果的なテクスチャ圧縮形式を選択するためのガイドラインは per-textureとper-targetで選択することですテクスチャがすべて RGBかRGBAデータでない限りノーマルデータ向けに２つの個別のチャネルの圧縮を可能にするなど圧縮するデータの種類に基づき圧縮形式を選択するべきです ASTC形式に圧縮する場合形式のサブセットを選択しましょう高度の圧縮率ではなく最高品質のテクスチャを必要とするものにはバケットテクスチャを考慮しますではおさらいです我々はTextureToolからテクスチャ処理パイプラインを再構築し新しいTextureConverter ツールでパイプラインのすべてステージを完全に制御できるようにしましたこの新しいパイプラインの各ステージを説明し各ステージで使用できるオプションと Appleプラッフォームでサポートされているテクスチャ圧縮形式系統とチャネルマッピングをご紹介しました TextureToolから TextureConverterへとワークフローの更新をできるだけ簡単にするためコマンド行の切り替えに役立つ互換モードを追加しました TextureTool互換モードを使用しても TextureConverterをネイティブとしても xcrun Texture Converterを呼び出せますこちらはTextureToolで呼び出された TextureConverterのコマンド行の例です TextureConverterはオプションをネイティブの TextureConverterに変換し圧縮してから新しいネイティブオプションを伝えるのでビルドスクリプトを簡単に更新できます
TextureConverterのご紹介でしたご購入方法は以下の通りです TextureConverterは Xcode 13の一部として Seed 1で利用可能になります Windowsでは TextureConverterは Windows 2.0パッケージの Metal Developerの一部となり developer.apple.comからご購入いただけます Seed 1は現在販売中です WindowsではPVRTC形式はの圧縮はサポートされていないことにご留意ください PVRTCはmacOSの旧式のiOSプラッフォームのサポート用だからです Windows用 Metal Developerのもう１つ重要なのは Windows用 Metal Compilerですこの製品は Metal Shading Language version 2.3と共に去年発売され Xcodeで販売されたMetalコンパイラの更新に合わせて１年を通じ更新されます最新バージョンは1.2で Apple Silicon Macsの Metal Shading Language サポートが含まれています version 2.0のSeed 1が現在利用可能で Metal Shading Language 2.4のすべての新機能のサポートを提供しています
では本日のトークの要約です EGorはレイトレーシング関数ポインタなど Metal機能のサポートさらにすべてのAppleプラッフォームで GPUを最大限に活用するための新しいプロファイリングワークフローをご紹介しましたシェーダー検証と精密なキャプチャ制御に対しより優れたサポートを提供するためのデバッギングワークフローの改善のデモも行いました私はテクスチャ処理パイプラインを活用するのに役立つ TextureConverterと Appleプラッフォームで利用可能なすべてのテクスチャ圧縮形式をご紹介しましたありがとうございます WWDC 2021をお楽しみ下さい [音楽]

float4 EncodeRGBM(float3 in)
{ 
    float4 rgbm; 
    rgbm.a = max3(in.r, in.g, in.b) / RGBM_Range;
    rgbm.rgb = in / (rgbm.a * RGBM_Range);
    return rgbm;
}

28:41 - RGBM Decoding Pseudocode

float3 DecodeRGBM(float4 sample)
{ 
    const float RGBM_Range = 6.0f;
    float scale = sample.a * RGBM_Range;
    return sample.rgb * scale;
}

30:55 - MetalTextureSwizzles

// Remap the X and Y channels to red and green channels for normal maps 
compressed with ASTC.
 
MTLTextureDescriptor* descriptor = [[MTLTextureDescriptor alloc] init];

MTLTextureSwizzle r = MTLTextureSwizzleRed;
MTLTextureSwizzle g = MTLTextureSwizzleAlpha;
MTLTextureSwizzle b = MTLTextureSwizzleZero;
MTLTextureSwizzle a = MTLTextureSwizzleZero;

descriptor.swizzle = MTLTextureSwizzleChannelsMake( r, g, b, a );

31:55 - ReconstructNormal

// Reconstruct z-axis from normal sample in shader code.

float3 ReconstructNormal(float2 sample)
{
    float3 normal;

    normal.xy = sample.xy * 2.0f - 1.0f;
    normal.z  = sqrt( saturate( 1.0f - dot( normal.xy, normal.xy ) ) );

    return normal;
}

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

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

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

WWDC20