Apple Siliconを利用した画像処理Appの作成

Apple Siliconを利用した画像処理Appの作成

画像処理AppをAppleシリコン向けに最適化する方法を紹介します。Metalのレンダリングコマンドエンコーダ、タイルシェーディング、ユニファイド・メモリ・アーキテクチャ、メモリレス・アタッチメントを活用する方法について説明します。Apple独自のタイルベースの遅延レンダラーアーキテクチャを使用して、低メモリフットプリントで電力効率の高いAppを作成する方法や、計算ベースのAppをディスクリートGPUからAppleシリコンに移行する際のベストプラクティスをお伝えします。

リソース
関連ビデオ

WWDC20
- Apple GPUとMetalの併用
- Metal PerformanceをApple Silicon Macに最適化する
ダウンロード

♪ (Apple Siliconを利用した画像処理Appの作成) WWDCへようこそ私はEugene Zhidkovです GPUソフトウェア部門の者です Macシステムアーキテクチャ部門の Harshも参加します二人で画像処理Appの作成方法を紹介します Apple siliconのMetalで稼働するものですまず私がフォーカスするのはベストプラクティスと学習済みのレッスンです M1用の画像処理Appの最適化も昨年得られた開発者の関与に基づきますそしてHarshが段階ごとのガイドを紹介します Apple silicon上での最適パフォーマンスのために画像処理パイプラインを設計変更する方法ですそれでは始めましょうまずAppleシステムを手短に振り返りましょうオン・ザ・チップアーキテクチャとその利点です多くの画像処理と映像編集Appは独立したGPUを念頭に設計されていますですからAppleのGPUで何が大きく違うかを強調することが重要ですまず全Appleチップはユニファイドメモリアーキテクチャ使用ですすべてのブロック CPU GPU ニューラルエンジンメディアエンジンがユニファイドメモリインターフェイスを使用して同じシステムメモリにアクセスします次に弊社のGPUはタイルベースデファードレンダラーつまりTBDRです TBDRには2つの主要フェーズがありまずタイル化ですここでレンダー表面全体がタイルに分割され形状処理は独立して処理されますそしてレンダリングですここですべてのピクセルが各タイルに関して処理され Apple siliconで最も効率的になります皆さんの画像処理Appはユニファイドメモリの活用を開始すべきですパイプラインが実施していたコピーを回避しましょうメモリを利用することでTBDR構造やローカル画像ブロックも活用しましょう Apple TBDRが低レベルで機能する方法を知るため弊社のシェーダーコアをターゲットにする方法を知るために昨年のセッションを視聴してください次に説明するのはまさにApple siliconのために画像処理キャプチャ負荷を最適化するために行うことです昨年画像パイプライン移行のために多くの優れた開発者と緊密に作業してきました弊社には6つの最も役立つヒントがありますまず不必要なメモリコピーを回避する方法を考えましたこれが非常に重要なのは最大8Kの画像で作業しているためですそれからレンダーパイプラインとテクスチャを使用する価値を強調することにしましたバッファ上の計算を使用する代わりですそして皆さん自身の画像処理パイプラインでそうする方法もです我々がレンダーとテクスチャのパスを稼働させたら適切な負荷/ストアのアクションとメモリレスアタッチの重要性を皆さんに紹介したかったのですこれでほとんどのタイルメモリ不足が防止できます次にUberシェーダーの最適化アプローチを紹介しますその動的制御フローを用いてまたより小型のデータタイプを活用する方法も説明しますつまりショート型やハーフ型ですこれは性能と効率性を向上するためですそして最後に重要なアドバイスがあります最適スループットのためのテクスチャ形式についてですいいですねでは最も役立つヒントの1つからはじめましょう Apple siliconで不必要なコピーを回避する方法ですほとんどの画像処理Appは個別のGPUを念頭に設計されています独立したGPUでは個別のシステムメモリとビデオメモリがありますフレーム画像をGPUに表示して常駐させるために明示的なコピーが必要ですさらにこれは通常2回必要ですデータをGPUにアップロードして処理してそれを引き戻すためです 8K映像をデコードして処理してからディスクに保存するでこれはこの場合 CPUスレッドデコーディングですこのためデコードされたフレームを GPUのVRAMにコピーしますそしてこれがGPUタイムラインですここですべての効果とフィルタが適用されますさらに一歩進んで思い出してみましょう結果をディスクに保存する必要がありますねですから処理済みフレームをシステムメモリに戻す事も考えないといけませんそしてフレームの実際のエンコーディングもこれらが「コピー」や「ブリットギャップ」でありそして高度な画像処理Appはこれらの作業のために深いパイプラインなどの高度な作業を実施する必要がありますしかし吉報はApple GPUです常駐のためのコピーはもはや不必要ですメモリが共有されるため CPUとGPUの両方がメモリに直接アクセスできますユニファイドメモリシステムで実行して不必要なコピーを回避しているか簡単なチェックを追加してくださいこれでメモリや時間を節約できこれは実施すべき絶対的な第一歩ですこれがコピーを排除して統一メモリ構造を実施したところですコピーを排除することで完全にコピーギャップを回避でき処理を即座に開始できますこれでCPUとGPUのパイプラインも向上し楽になります必ずユニファイドメモリパスを実装してコピーを排除してくださいブリットコピーを放置した場合はまさに独立GPUの場合と同じになりますシステムメモリの帯域幅を利用し実際の処理ではGPU時間が短くなりスケジューリングオーバーヘッドの可能性があります当然個別のVRAM画像を配置する必要はありません GPUフレームキャプチャにより大型ブリットを特定できます Appのブリットを検査して必要なコピーだけを行うようにしてくださいでは画像処理でAppleGPU TBDR の活用を実際にどのように開始するかを説明しますほとんどの画像処理Appは一連の計算カーネルを利用して画像バッファ上で動作します計算カーネルを利用するときデフォルトのシリアルモードでは Metalがすべてのその後の利用ですべてのメモリ書き込みが見えることを保証しますこの保証は全シェーダコアでのメモリ一貫性を含意するのであらゆるメモリ書き込みが次の利用開始までに他のすべてのコアに可視になりますこれはメモリトラフィックがとても高くなることも意味します画像全体を読み書きする必要があるためです M1のApple GPUはMacOSでのタイルディスパッチを可能します通常の計算と対称的にタイルのみの同期ポイントでこれらはメモリで動作します畳み込みなどの一部のフィルタはタイルのパラダイムにはマップできませんが多くの他のフィルタは可能ですエンコーダの端点までシステムメモリフラッシュを遅延して明確な効率性ゲインが得られますシステムメモリ帯域幅で制限されないときはより有用なGPU作業を実行できますこれをさらに進めて多くのピクセルごとの操作が隣接ピクセルへのアクセスを必要としないのでタイル同期点は必要ありませんこれは断片化機能によくマッピングします断片化機能は明示的なタイル同期なしで実行できます同期が必要なのはエンコーダの境界やタイルカーネルが断片カーネルのあとでシリアルに利用されるときだけです AppleのGPUが断片化機能とタイルカーネルを有効化してより効率的に画像処理することを説明しましたこれの使い方を説明します弊社では通常のテクスチャへのコマンドエンコーダをレンダするバッファ上の計算利用を転換してこれを行いますすでに説明したように経験則は次のとおりですピクセル間の依存性のないピクセルごとの操作は断片化機能を使用して実装するべきですスレッドグループスコープ機能のあるフィルタはシェーディング付きで実装するべきですこれはタイル内の隣接ピクセルアクセスが必要なためですスキャッターギャザーと畳み込みフィルタはタイルパラダイムにマップできませんこれはそこでランダムアクセスが必要なためですこのためこれらは計算利用に依然として留まりますレンダーコマンドエンコーダもユニークなApple GPU機能を有効にしますテクスチャとレンダーターゲットのロスレス帯域幅圧縮ですこれは優秀な帯域幅節約機能であり画像処理パイプラインではなおさらですこれを行う方法を説明しますロスレス圧縮を有効にする方法を説明しますすべきでないことを説明するのは実際にはより簡単ですまず圧縮済みのテクスチャ形式はロスレスの利益が得られません次にこの圧縮で機能しない3つの特定のテクスチャフラッグがあるので誤ってこれらを設定しないでくださいそして3番目に線形テクスチャや MTLBufferへのバックも許可されません非プライベートテクスチャではある種の特殊な処理も必要です optimizeContentsForGPUAccessを必ず呼び出しますこれは最速パスにとどまるためです GPUフレームキャプチャサマリーペインにロスレス圧縮警告が表示されテクスチャがオプトアウトされた理由がハイライトされます PixelFormatViewフラグがこの例で設定されました多くの場合に開発者はこれらのフラグを意図せず設定しています PixelFormatViewを設定すべきでないのはコンポーネントスウィズルや SRGB変換のみが必要な場合ですこれでレンダーパスおよびテクスチャパスを稼働できましたそれではタイルメモリを正しく使用していることを確認しますメモリTBDRの概念はロード/保管動作とメモリレス添付などですがデスクトップの世界ではまったく新しいものですこのためこれらを正しく使用しましょうロード/保管アクションから始めましょうすでに説明したようにレンダーターゲット全体がタイルに分割されますロード/保管はタイルごとのバルク動作でありメモリ階層の中で最適パスを取ることが保証されますこれらはレンダーパスの最初に実行されますつまりタイルメモリを初期化する方法をGPUに伝えるときでありパスの最後にGPUに伝えるのはどの添付を書き戻す必要があるかですここで重要なのは不必要なものをロードしないことです画像全体を上書きする場合またはリソースが一次的な場合は LoadActionDontCareにロード動作を設定しますレンダーエンコーダーで出力や一時データをクリアする必要はもはやありませんこれは以前は専用計算パスや fillBufferコールでやっていたことでしょう LoadActionClearを設定してクリア値を効率的に指定できますそして保管動作も同じようにします後で必要になるデータだけを保管しますそれは主要な添付などであり一時的なものは保管しません明示的なロード動作や保管動作に加えて Apple GPUはメモリフットプリントを節約しますこれはメモリレス添付によります我々は添付をメモリレス保管モードを持つものとして明示的に定義できますこれでタイルのみのメモリ割り当てが可能になりエンコーダ寿命内だけであらゆる各タイルでリソースが永続しますこれでメモリフットプレリントを大幅に削減でき 6K/8K画像ではなおさらですそこでは各フレームが数百メガバイトになるためですこれをコードで実施する方法を説明します textureDescriptorをまず作成し次にoutputTextureを作成します次に一時テクスチャを作成します私はこれをメモリレスとマークしましたここでストレージは必要ないためですそれからレンダーパスを作成します最初に添付が何かを記述し次にロード/保管動作を記述します出力のロードは気にしません完全に上書きされるためですがこれを保管する必要があります一時テクスチャとしてはロードせずクリアしこれを保管する必要もありません最後に記述子からレンダーパスを作成しますこれだけですこうしてユニファイドメモリを使用し画像処理パイプラインを移動してコマンドエンコーダをレンダリングしタイルメモリを適切に利用していますここでウーバーシェーダーについて説明しますウーバーシェーダーやウーバーカーネルは開発者を楽にする人気の手法ですホストコードで制御構造が設定されシェーダーは一連のif/else文を単にループするだけですたとえばトーンマッピングが有効な場合や入力がHDR形式やSDR形式の場合はこのアプローチは「ウーバーシェーダー」とも呼ばれパイプライン状態オブジェクトの合計数を削減するとても良い方法ですしかし欠点もあります主な欠点はレジスタ圧を増加させることですがこれはより複雑な制御フローを扱うためです使用するレジスタが増えるとシェーダーが実行される最大占有率が簡単に制限されます制御構造で通過する単純なカーネルを考えます構造の中のフラグを使用してすべきことを制御しますここに2つの機能があります入力がHDRの場合とトーンマッピングが有効な場合ですすべて良好に見えますねこれがGPUで起こっていることですコンパイル時には何も推論できないため HDRとHDR以外の両方のパスを取ると想定する必要がありフラグに基づいて結合しますトーンマッピングでも同じです我々はこれを評価してから入力フラグに基づいて内外にマスクしますここでの問題はレジスタですあらゆる制御フローパスでライブレジスタが必要ですこれはウーバーシェーダーが苦手な分野ですご存知のようにカーネルで使用するレジスタでシェーダーが実行される最大占有率が定義されますこれはレジスタファイルがシェーダーコアの全simdlaneで共有されるためです必要なものだけを実行できるなら simdgroup占有率とGPU利用率が向上しますこれを修正する方法です Metal APIにはこの作業に適したツールがあり "function_constants"と呼ばれています両方の制御パラメータを function_constantとして定義しふさわしくコードを修正しますここに修正済みカーネルコードがありますホスト側も更新してパイプライン作成時に function_constant 値を提供する必要がありますレジスタ圧を減少する別の優れた方法はシェーダーで16ビット型を使用することです Apple GPUにはネイティブの 16ビットサポートがありますこのためより小型のデータタイプを使用するときはシェーダーが必要なレジスタが少なくなり占有率が増加しますハーフ型やショート型もエネルギー要求が少なくより高いピークレートを達成する可能性がありますこのためハーフ型やショート型を使用して可能ならfloatやIntを避けてくださいこれは型変換が通常自由なためですこの例では一部の計算でスレッドグループで thread_positionの使用を考慮します符号なしintを使用しますが Metalがサポートする最大スレッドグループサイズは符号なしショート型に簡単に適合できますしかしthreadgroup_position_in_gridでより大きなデータ型が必要となることもありますしかし画像処理で使用するグリッドサイズは最大8Kや16Kであり符号なしショート型で十分です代わりに16ビット型を使用するなら結果のコードでは使用するレジスタの数がさらに減り占有率が増加する可能性がありますここでレジスタのすべての詳細がわかるところを説明します Xcode13のGPUフレームデバッガーにレンダータイル P50計算用の先進のパイプライン状態オブジェクトビューが搭載されましたレジスタ使用率とともに詳細パイプライン統計を検査してすべてのシェーダーを微調整できます関係するレジスタをカバーしてテクスチャ形式を説明します最初に多様なピクセル形式が多様なサンプリングレートになりうることを指摘しますハードウェア生成やチャネル数によりより幅広い浮動小数点型でポイントサンプリングレートが減少することがあります特にRGBA32Fなどの浮動小数点形式はサンプリングが値をフィルタしたときに浮動小数点16ビット型よりも遅くなりますより小型の型を使用するとメモリストレージ帯域幅キャッシュフットプリントも削減されますこのため可能な最小の型を使用することを推奨しますしかしテクスチャストレージのこのケースではこれは実際には画像処理の 3D LUTの一般的なケースで我々が作業するほとんどのAppはバイリニアフィルタを有効にした 3D LUT AppフェーズでRGBAを使用します Appで代わりにハーフ型を使用できないか精度が十分かを考察してくださいその場合は FP16にすぐに切り替えてピークサンプルレートを達成しますハーフ型の精度が十分でないなら固定少数点符号なしショートですばらしい均一レンジの値が可能なことが分かりますこのためユニットスケールで LUTをエンコードし LUTレンジをシェーダーに与えることはピークサンプルレートと十分な数値精度の両方を得るためのすばらしい方法でしたこれでApple GPU構造を利用して画像処理パイプラインを可能な限り効率的に実行する方法を説明しましたこれをすぐに適用する方法は Harshが説明します Eugene ありがとうではApple siliconで画像処理パイプラインを設計変更する方法を説明しますこれは学習してきた全ベストプラクティスに基づきますとりわけ Apple GPU用に映像処理パイプラインの画像処理フェーズを改良しますリアルタイム画像処理はまさにGPU計算でありメモリ帯域幅を必要とします最初に通常の設計方法を説明してから Apple silicon用に最適化する方法を説明しますこの節では映像編集ワークフローの詳細には触れないので 2年前の我々のセッションを参照してください我々はパスをレンダーするための画像処理の計算部分への移行だけにフォーカスします開始する前に一般的な映像処理パイプラインで画像処理フェーズがある場所を手短に調べましょう ProResエンコード済みの入力ファイルを例に取ります ProResエンコード済みフレームをまずディスクや外部ストレージから読み出しますそれからCPUでフレームをデコードし画像処理フェーズをこのデコード済みフレームにGPUで実行し最終出力フレームをレンダーします最後にこの出力フレームを表示しますまたさらにこの最終レンダーフレームをデリバリ用にエンコードします次に画像処理パイプラインを構成するものを説明します画像処理はソース画像のRGBとアルファの多様なチャネルをアンパックし別個のバッファに入れることで開始しますこれらのチャネルのそれぞれを画像処理パイプラインで一緒または個別に処理します次に色空間変換を実施して必要な色管理環境で動作させます次に3D LUTを適用し色補正を実行し空間一時ノイズ除去畳込みにじみなどの効果を適用しますそして最後に個別に処理されたチャネルを一緒にパックして最終出力しますこれらの選択した手順に共通なものは何でしょうかすべてポイントフィルターですピクセル間の依存性がなく単一ピクセルのみで機能しますこれらは断片シェーダー実装によくマップします空間スタイルと畳込みスタイルの動作では大半径のピクセルへのアクセスが必要で拡散読み書きアクセスパターンも必要ですこれらが計算カーネルに適していますこの知識は後ほど使います今のところはこれらの操作を実行する方法を説明します Appはフィルタグラフとして画像に適用される一連の効果を表しますあらゆるフィルタはそれ自体のカーネルであり前の段階からの入力を処理し次の段階への出力を作りますここでのあらゆる矢印が 1つの段階出力に書き込まれ次の段階で入力として読み取られるバッファを意味しますメモリが制限されているので Appは通常位相ソートを行ってグラフを線形化しますこれは中間リソースの合計数をできるだけ少なく保つためまた競合状態を回避するために行いますこの例の単純なフィルタグラフは競合状態なしに動作して最終出力を作成するために 2つの中間バッファが必要ですこの線形化グラフはおおむね GPUコマンドバッファエンコーディングも示していますこのフィルタグラフが非常に多くのデバイスメモリ帯域幅を必要とする理由を説明しますあらゆるフィルタ動作はデバイスメモリからレジスタに画像全体をロードして結果をメモリデバイスに書き戻す必要がありますそしてこれはかなりのメモリトラフィックです 4Kフレーム画像処理のメモリフットプリントを画像処理グラフの例に基づいて考えましょう 4Kデコード済みフレーム自体は浮動小数点16ビット精度で 68Mバイトのメモリを消費します浮動小数点32ビット精度では 135Mバイトのメモリですまたプロフェッショナルワークフローは絶対に浮動小数点32ビット精度が必要ですこの画像処理グラフで浮動小数点 32ビット精度で1つの 4Kフレームを処理するには 2ギガバイトを超えるデバイスメモリへの読み書きトラフィックが必要ですまた中間出力を持つバッファへの書き込みはキャッシュ階層を進みチップの他のブロックにも影響します通常の計算カーネルはオンチップタイルメモリから暗黙的に利益を得ませんカーネルはスレッドグループスコープメモリを明示的に割り当てこれはオンチップタイルメモリに支えられますしかしそのタイルメモリは計算エンコーダ内のディスパッチ間で永続的ではありません対称的にタイルメモリは実際に1つのレンダーコマンドエンコーダ内のドローパス間で永続します我々がこの代表的な画像処理パイプラインを設計変更してタイルメモリを利用する方法を説明します我々は以下の3段階でこれに対処していますまずレンダーパスへの計算パスおよびテクスチャへのすべての中間出力バッファを変更していますそれから1つのレンダーコマンドエンコーダー内の断片シェーダー呼び出しとしてピクセル間依存性のないピクセル操作をエンコードしますすべての中間結果を配慮し適切なロード/保管動作の設定を確認しますそして最後に単なるポイントフィルタよりもより複雑な状況で作業することを説明します最初の段階は別個の TLRenderCommandEncoderで対象のシェーダーをエンコードすることですこのフィルタグラフでアンパック色空間変換 LUT および色補正フィルタはすべてポイントのピクセルごとのフィルタですこれを断片シェーダーに変換して 1つのレンダコマンドエンコーダを使用してエンコードします同様にミキサーおよびパックシェーダーもこの画像処理パイプラインの終了に向かって断片シェーダーに変換でき他のMTLRenderCommandEncoderを使用してエンコードできますそれからそれぞれのレンダーパスの中でこれらのシェーダを呼び出すことができますレンダーパスを作成するときはそのレンダーパス内の色添付に添付されたすべてのリソースは明示的にタイルされます断片シェーダーはそのタイルの断片の位置に関連付けられた画像ブロックデータのみを更新できます同じレンダーパスの次のシェーダーはメモリから直接以前のシェーダーの出力を取ることができます次の節ではこれらのフィルタにマップする断片シェーダーを構築する方法を説明しますまたこれらの断片シェーダーの中から規定のタイルメモリにアクセスできるように定義して使用する必要がある構造も説明しますそして最後に同じレンダーコマンドエンコーダーの中の次の断片シェーダーによりタイルメモリから直接消費できる 1つの断片シェーダーによりタイルメモリ内に出力が生成される方法も説明しますこれがコードですべきことですここで私はレンダーパス記述子の色添付0に添付されるテクスチャとして出力画像を添付しました私はレンダーパス記述子の色添付1への中間結果を保持するテクスチャを添付しましたこれらの両方が暗黙的にタイルされますセッションで説明したように適切なロード/保管プロパティを設定してくださいそして断片シェーダーの中のこれらのテクスチャにアクセスする構造を設定します次の例では断片シェーダー内でこの構造を使用する方法を説明しますすでに定義した構造を使用して強調されているように断片シェーダー内の出力および中間テクスチャにアクセスするだけですこれらのテクスチャへの書き込みは断片に対応する適切なメモリ位置に行われますアンパックシェーダーにより生産される出力はすでに定義した同じ構造を使用する色空間変換シェーダーにより入力として消費されますこの断片シェーダーはそれ自体の処理を実施でき出力と中間テクスチャを更新しますこれは今一度対応するタイルメモリ位置を更新しますあなたはすべての他の断片シェーダーのために同じレンダーエンコーダーパスの中で同じ手順を続行します次にこの動作シーケンスがこれらの変更でどのように見えるかを示しますお分かりの通りアンパックし色空間変換 3D LUTの適用および色補正手順を行いすべて1つのレンダーパスを使用しますが間にデバイスメモリパスはありませんレンダーパスの終わりにメモリレスでないレンダーターゲットはデバイスメモリにフラッシュされますそれからフィルタの次のクラスを実行できます散乱収束アクセスパターンのあるフィルタについて少し説明しますこうしたフィルタを表すカーネルはデバイスメモリで直接データに作用できます畳み込みフィルタは計算カーネルのタイルベースの動作に非常に適していますここでスレッドグループスコープメモリを宣言することでタイルメモリを使用する意図を表明できます今ピクセルのブロックを必要な全ハロピクセルとともにタイルメモリに移動しますフィルタ半径に従いタイルメモリで直接畳み込み動作を実行しますただしメモリは計算エンコーダ内の計算ディスパッチを通して永続しませんこのためFilter1 を実行したあとはタイルメモリの内容をデバイスメモリに明示的にフラッシュする必要がありますこの方法でFilter2はFilter1の出力を消費しますではこれらの変更をすべて実施したらどこに行くべきでしょうか 1つの4Kフレームを浮動小数点32ビット精度でこの例の再構成された画像処理グラフで処理するためにこれが今得られているものです帯域幅は2.16ギガバイトから 810メガバイトをロードして保管できる規模に下がりデバイスメモリへのメモリトラフィックは 62%の削減です 2つの中間デバイスバッファーは不要になりフレームごとに270Mバイトの節約ですそして最後にキャッシュスラッシュを削減していますがこれはそのレンダーパス内のすべての断片シェーダーが直接メモリ上で動作しているためです Apple siliconの主要機能の1つはユニファイドメモリアーキテクチャです Apple silicon上の別々のブロック間でのやり取りのためにこのユニファイドメモリアーキテクチャを使用する例を説明しますケーススタディとしてGPUでレンダーされた最終映像フレームのHEVCエンコードを使いますこのエンコードは Apple siliconの専用ハードウェアメディアエンジンを使用して実施されました GPUによりレンダーされた最終出力フレームは追加のメモリコピーなしでメディアエンジンにより直接消費できます次の節では最も効率的な方法でGPUにより生産された最終出力フレームのHEVC エンコードのためにパイプラインをセットアップする例を説明しますそのためにまず IOSurfacesで支援されたピクセルバッファのプールを作成するために CoreVideo APIを利用しますそれからMetal APIを使用して作成したばかりのプールから IOSurfaceで支援される Metalテクスチャへと最終フレームをレンダーしますそして最後に GPUが生産した出力フレームの追加コピーなしにエンコード用にメディアエンジンに直接これらのピクセルバッファをディスパッチしユニファイドメモリアーキテクチャを活用しますこれを実行する方法をステップごとに説明しこのフローを有効化するために必要なすべての構成をカバーします最初に必要なピクセル形式で IOSurfaceに支援される CVPixelBufferPoolを作成しますここでHEVCエンコード用のバイプレーナークロマサブサンプル済みのピクセル形式を使用しますここでCVPixelBufferPoolから CVPixelBufferを得ますこのCVPixelBufferを正しいライトプレーンインデックスとともに MetalTextureCacheに渡し CVMetalTextureReferenceを得ますバイプレーナーピクセル形式を使用しているのでバイプレーナーピクセルバッファーの両面でこの手順を実行する必要があります次にCVMetalTextureReference オブジェクトから基底のMetalテクスチャを取得しますこの手順をルマ面とクロマ面の両方で実施しますこれらのMetalテクスチャは CVPixelBuffer 面も支援する同じIOSurfacesにより支援されます Metal APIを使用しルマ面およびクロマ面に対応するテクスチャにレンダーしますこれでこれらのMetalテクスチャも支援するIOSurfaceが更新されます画像処理パイプライン内のシェーダーパスとして GPU自体のクロマサブサンプリング手順を実施することを強く推奨します注意すべき点はレンダー直後のCVPixelBufferと Metalテクスチャの両方がシステムメモリの同じ基底 IOSurfaceコピーで支援されることですこれでCVPixelBufferをエンコードのために直接メディアエンジンに送信できますご覧のようにユニファイドメモリアーキテクチャのためにメモリコピーなしにシームレスにデータをGPUとメディアエンジンブロックの間で移動できますそして最後にあらゆるフレームのあとCVPixelBufferと CVMetalTexture 参照を解放します CVPixelBufferを解放すると次のフレームのためにこのバッファをリサイクルできますつまり再び以下のことをお勧めします該当する場合は計算の代わりに MTLRenderCommandEncoderを使用すること 1つのレンダーコマンドエンコーダー内にすべての該当するレンダーパスをマージすること適切なロード/保管アクションを設定すること一時リソースのためにメモリレスを使用すること該当する場合はタイルシェーディングを利用することまたゼロコピーで他のAPIでバッファプールを使用すること今日はセッションに来ていただきありがとうございました WWDC 2021の他のセッションもお楽しみください
♪

let textureDescriptor = MTLTextureDescriptor.texture2DDescriptor(…)
let outputTexture = device.makeTexture(descriptor: textureDescriptor)

textureDescriptor.storageMode = .memoryless
let tempTexture = device.makeTexture(descriptor: textureDescriptor) 

let renderPassDesc = MTLRenderPassDescriptor()
renderPassDesc.colorAttachments[0].texture      = outputTexture
renderPassDesc.colorAttachments[0].loadAction   = .dontCare
renderPassDesc.colorAttachments[0].storeAction  = .store
renderPassDesc.colorAttachments[1].texture      = tempTexture
renderPassDesc.colorAttachments[1].loadAction   = .clear
renderPassDesc.colorAttachments[1].storeAction  = .dontCare

let renderPass = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDesc)

12:25 - Uber-shaders impact on registers

fragment float4 processPixel(const constant ParamsStr* cs [[ buffer(0) ]])
{
  if (cs->inputIsHDR) {
    // do HDR stuff
  } else {
    // do non-HDR stuff
  }
  if (cs->tonemapEnabled) {
    // tone map
  }
}

13:32 - Function constants for Uber-shaders

constant bool featureAEnabled[[function_constant(0)]];
constant bool featureBEnabled[[function_constant(1)]];

fragment float4 processPixel(...)
{
  if (featureAEnabled) {
    // do A stuff
  } else {
    // do not-A stuff
  }
  if (featureBEnabled) {
    // do B stuff
  }
}

23:02 - Image processing filter graph

typedef struct
{
    float4 OPTexture        [[ color(0) ]];
    float4 IntermediateTex  [[ color(1) ]];
} FragmentIO;

fragment FragmentIO Unpack(RasterizerData in [[ stage_in ]],
                           texture2d<float, access::sample> srcImageTexture [[texture(0)]])
{
    FragmentIO out;
    
    //...
                         
    // Run necessary per-pixel operations
    out.OPTexture       = // assign computed value;
    out.IntermediateTex = // assign computed value;
    return out;
}

fragment FragmentIO CSC(RasterizerData in [[ stage_in ]], FragmentIO Input)
{
    FragmentIO out;

    //...    
    
    out.IntermediateTex = // assign computed value;
    return out;
}

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

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

リソース

関連ビデオ

WWDC20