Apple Silicon TBDR：アプリ開発者が実際に得られるもの

1分で読めます

Apple silicon GPUは、他のGPUとはレンダリング方式が異なります。AppleのMetalドキュメントは、このアーキテクチャを名指しで説明しています。「Apple siliconのGPUは、パフォーマンスと電力効率を最適化するタイルベース遅延レンダリング（TBDR）と呼ばれるレンダリング技術を実装しています」¹。このTBDRという形こそが、Metal 4のAPI、オンデバイスMLスタック、imageblockとタイルシェーダーのプログラミングモデルが今ある形で存在する理由なのです。

以下のセクションでは、TBDRが可能にするApple公式ドキュメントの4つの機能と、それぞれがアプリにもたらすメリットを順に見ていきます。imageblock、タイルシェーダー、ラスタオーダーグループ、そして強化されたマルチサンプルアンチエイリアシング実装です。先行記事のMetal 4 essentialsではコアとなるAPI表面を扱いましたが、ここではAPIが対象とするGPU基盤に焦点を当てます。

TL;DR

TBDRはレンダーデスティネーションをタイルに分割し、複数のタイルを別々のGPUコアで並列実行し、各タイルのジオメトリ評価がすべて終わるまでシェーディングを遅延させます¹。
タイルメモリは、デバイスメモリと比べて帯域幅が数倍速く、レイテンシが数倍低く、エネルギーコストが大幅に少なくなります¹。
A11以降のApple GPUは、imageblock、タイルシェーディング、ラスタオーダーグループ、imageblockサンプルカバレッジ制御を追加しています。アプリはこれらすべてにMetal経由でアクセスできます¹。
imageblockを使うと、タイルメモリ内にカスタムのピクセル単位データ構造を定義し、描画とディスパッチをまたいでデータを保持し、レンダーとコンピュートを単一パス内で混在させることができます¹。
ラスタオーダーグループは、同一ピクセルを対象とするフラグメントスレッドを同期し、順序依存のブレンディングを壊すread-modify-writeレースを排除します¹。

TBDRとは実際に何か

Appleの説明をそのまま引用しましょう。「GPUはレンダーデスティネーションをタイルと呼ばれる小さな領域のグリッドに分割します。各タイルはGPUコアの1つで処理され、多くの場合複数が同時に実行されます。GPUは各タイルのレンダリングフェーズを、そのタイルのすべてのジオメトリを評価し終えるまで遅延、つまり後回しにします」¹。

イミディエイトモード（IM）GPUとの対比もApple自身の言葉によります。「IM GPUは、レンダリング内で可視であるかどうかに関係なく、線や三角形などのプリミティブを完全に処理します」¹。TBDRは、まずタイルのすべてのジオメトリを集めてから、オクルージョンを生き残ったものだけをシェーディングすることで、その作業を回避します。Appleはその利点を直接的に述べています。「TBDR GPUは、レンダーパスのすべてのジオメトリを同時に処理し、可視のプリミティブのみをシェーディングすることで、不要な作業を回避します」¹。

タイルメモリこそが見返りです。Appleはデバイスメモリに対する優位性を次のように説明しています¹。

「デバイスメモリより数倍速い帯域幅」
「デバイスメモリより数倍低いアクセスレイテンシ」
「デバイスメモリへのアクセスより大幅に少ないエネルギー消費」

2つのレンダーパスはハードウェア上で重ね合わせることもできます。Appleは次のように述べています。「GPUはあるレンダーパスの最終ステージをタイルメモリで実行している間に、次のレンダーパスの頂点ステージを開始できます。両ステージは異なる計算およびメモリコンポーネントを使用する傾向があるため、GPUは両ステージを並列実行することで、より多くのハードウェアブロックを同時に活用できるのです」¹。

これが基盤です。以下はすべてこの基盤を使います。

Imageblock：タイルメモリ内のカスタムピクセル単位データ

Appleによるimageblockの定義はこうです。「Imageblockはローカルメモリに格納された構造化された画像データのタイルで、Apple GPUが効率的に操作できる画像データをタイルメモリ内に記述できるようにします」¹。これらは幅、高さ、ピクセル深度を持つ2Dデータ構造であり、「imageblock内の各ピクセルは複数のコンポーネントから構成でき、各コンポーネントを独自の画像スライスとしてアドレス指定できます」¹。Appleの例では、アルベド、スペキュラ、ノーマルの各コンポーネント用に3つの画像スライスを保持するimageblockが挙げられています。

Appleが文書化している形は次のとおりです¹。

カーネル関数とフラグメント関数の両方で利用可能。
描画とディスパッチをまたいで、タイルの寿命中持続。
既存のレンダーコードは、レンダーアタッチメント形式に一致するimageblockを自動的に作成。
アプリはシェーダー内で、追加チャネル、配列、ネストした構造を持つカスタムimageblockを定義可能。
フラグメントシェーダーはそのフラグメント位置のimageblockデータのみを参照し、コンピュート関数のスレッドはimageblock全体にアクセス可能。

描画とディスパッチをまたいだ持続性こそが、運用上興味深い部分です。Appleの説明はこうです。「imageblockの持続性によって、タイルシェーダーで単一のレンダリングパス内にレンダーとコンピュート操作を混在させることができ、両者は同じローカルメモリにアクセスできます。タイル内に複数の操作を保持することで、ローカルGPUメモリに留まる高度なアルゴリズムを構築できるのです」¹。

マルチステージのレンダリングパイプライン（ディファードシェーディング、スクリーンスペースエフェクト、カスタムブレンディング）を出荷するアプリにとって、中間結果をデバイスメモリに往復させる代わりにタイルメモリに保持することこそが、TBDRが還元してくれるフレームごとの予算なのです。

タイルシェーダー：レンダーとコンピュートを同一パスで

Appleによるタイルシェーダーの説明はこうです。「タイルシェーダーは、レンダーパスの一部として実行されるコンピュート関数またはフラグメント関数です。アプリがタイルメモリにデータを計算して保存することができ、そのデータはレンダーパス間でGPU上に持続します」¹。

タイルシェーダーが回避するのは、従来のGPUモデルです。Appleの言葉によれば、「従来のGPUはレンダリングコマンドとコンピュートコマンドを別々のパスに分離しています。これらのパスは通常、互いに直接通信できません。アプリはこの制限を回避するため、あるパスの結果をデバイスメモリに保存し、次のパスでそのデータを読み戻します。マルチフェーズレンダリングアルゴリズムなどのシナリオでは、アプリが中間データを何度もデバイスメモリにコピーすることもあるのです」¹。

タイルシェーダーはその中間データをタイルメモリに移動させます。Appleが文書化している見返りはこうです。「タイルシェーダーを使用するアプリは、中間結果をデバイスメモリに保存することを回避し、より高速なタイルメモリにデータを保存することで時間を節約できます」¹。

Metal 4アプリでは、タイルシェーダーはMetal 4 essentialsの記事で取り上げた統一型MTL4ComputeCommandEncoder設計と組み合わさります。エンコーダの統一とタイルシェーダーのプログラミングモデルは、同じアーキテクチャ上の決定を2つのレイヤーで読み解いたものです。つまり、Apple GPUハードウェアでは必要のない、従来GPUに存在するレンダー対コンピュートの境界を取り払うという決定です。

ラスタオーダーグループ：並列フラグメントスレッドの順序付け

ラスタオーダーグループが解決する問題について、Appleはこう述べています。「MetalはGPUが描画呼び出し順にブレンドすることを保証し、GPUがシーンを順次レンダリングしているような錯覚を与えます。…各三角形のフラグメントシェーダーは、それぞれ独自のスレッドで並列実行されます。背面にある三角形のフラグメントシェーダーが、前面にある三角形のフラグメントシェーダーより先に実行されないこともあり、これは別の三角形のシェーダー結果をカスタムブレンディング関数に必要とするシェーダーにとって問題となり得ます。並列性のため、このread-modify-writeシーケンスは競合状態を生む可能性があるのです」¹。

そのメカニズムはこうです。「ラスタオーダーグループは、同じピクセル座標とサンプル（サンプルごとのシェーディングを有効にした場合）を対象とするスレッドを同期することで、このアクセス競合を克服します」¹。

実装表面はこうなります。「ラスタオーダーグループを実装するには、メモリへのポインタに属性修飾子で注釈を付けます。それらのポインタを通じてピクセルにアクセスするシェーダーは、ピクセル単位の送信順序で実行されます。ハードウェアは、現在のスレッドと重複する古いフラグメントシェーダースレッドが完了するのを待ってから、現在のスレッドを進めます」¹。

最近のApple GPUはこのメカニズムを拡張しています。Appleは次のように述べています。「最近のApple GPU上のMetalは、ラスタオーダーグループに追加機能を拡張しています。imageblockの個別チャネルやスレッドグループメモリを同期できるようになります。複数のオーダーグループを作成することもでき、より細かな粒度の同期を実現し、スレッドがアクセスを待つ頻度を最小化できるのです」¹。

Appleが取り上げた具体例はディファードシェーディングです。従来の2フェーズアプローチでは、複数のテクスチャからなるg-bufferをデバイスメモリに書き込み、ライティングフェーズでそれらを読み戻します。Appleの説明はこうです。「複数のオーダーグループを使って両方のレンダーフェーズを1つに統合することで、中間テクスチャの必要性を排除できます。そのためには、ジオメトリバッファをタイルサイズのチャンクに保ち、ローカルimageblockメモリに留まるようにします」¹。

Appleが推奨する分割は次のとおりです¹。

第1オーダーグループ：3つのg-bufferフィールド（アルベド、ノーマル、深度）。
第2オーダーグループ：累積されたライティング結果。
「Apple GPUは2つのグループを別々に順序付けできるため、第2グループへの未処理の書き込みが第1グループからの読み取りを妨げません」¹。

ライトを累積するために、2つのスレッドは依然として実行終了時に同期します。勝因は、競合しない読み取りが順次ではなく並列で実行されることにあります。

ピクセルごとのユニークサンプルを追跡するMSAA

A11以降のGPUに関するAppleが文書化したMSAA実装は、教科書的な説明とは異なります。Appleの説明はこうです。「ハードウェアは各ピクセルにプリミティブのエッジが含まれているかを追跡するため、必要な場合にのみサンプルごとのブレンディングを実行します。別のプリミティブがピクセル内のサンプルをカバーする場合、GPUはピクセル全体に対して一度だけブレンドします」¹。

Appleの例はその最適化を順に説明しています。2つの重なる三角形のエッジでカバーされたピクセルは、4つのサンプル位置に3つのユニークな色を持ちます。Appleの言葉では、「A11以前のApple GPUはピクセルのカバーされた3つのサンプルそれぞれをブレンドします。A11以降のApple GPUは、2つのサンプルが同じ色を共有しているため2回だけブレンドするのです」¹。

色削減はさらに進みます。Appleはこう述べています。「Apple GPUはピクセル内のユニークな色の数を削減できます。例えば、GPUが以前の三角形の上に不透明な三角形をレンダリングする場合、ピクセルを単一の色で表現します」¹。

アプリはタイルシェーダーで実装を拡張できます。Appleが文書化したユースケースはこうです。「タイルシェーダーでサンプルカバレッジデータを変更することで、カスタム解決アルゴリズムを実装できます。例えば、不透明ジオメトリと半透明ジオメトリで別々のレンダーフェーズを含む複雑なシーンを考えてみましょう。半透明ジオメトリをブレンドする前に、不透明ジオメトリのサンプルデータを解決するタイルシェーダーを追加できるのです」¹。

タイルシェーダーはローカルメモリ上のデータで実行され、不透明ジオメトリフェーズの一部として組み込めるため、解決処理を別パスに回すのではなくタイルメモリ内に留めることができます。

アプリアーキテクチャにとって何を意味するか

Appleが文書化した表面から導かれる3つのテイクアウェイがあります。

タイルメモリこそ予算である。 上記の4機能（imageblock、タイルシェーダー、ラスタオーダーグループ、サンプルカバレッジ）はすべて、作業をタイルメモリに留めデバイスメモリの外に出すために存在します。Appleの文書化された数値は、デバイスメモリより帯域幅が数倍速く、レイテンシが数倍低く、エネルギーが大幅に少ないというものです¹。この予算を尊重するアプリアーキテクチャは、そうでないものより速く、より涼しく動きます。
レンダーとコンピュートは別世界ではない。 AppleのGPUは、従来GPUのようにレンダーとコンピュートを別パスに分割しません。imageblockの持続性とタイルシェーダーによって、アプリは単一のレンダーパス内でマルチフェーズアルゴリズムを実行できます。Metal 4の統一型コンピュートエンコーダは、同じアーキテクチャ的事実のAPIレベルでの表現なのです。
並列性がデフォルトであり、順序付けはオプトイン。 ラスタオーダーグループは、アプリが「このread-modify-writeシーケンスは順序に依存する」と表明する手段です。デフォルトは順不同の並列性であり、これがGPUの自然な姿です。ブレンディング、透過、g-buffer書き込みのために順序付きアクセスが必要なアプリは、特定のポインタに注釈を付け、ハードウェアにスレッドを順序付けさせます。

Apple Ecosystemクラスター全体としては、このハードウェアを対象とする並列API表面についてはMetal 4 core APIを、同じシリコン上でMLを実行するフレームワークについてはFoundation Models on-device LLMを、より広範なMLスタックについてはCore ML on-device inferenceをご覧ください。ハブはApple Ecosystem Seriesにあります。

FAQ

TBDRはMetal 4固有のものですか？

いいえ。Apple silicon GPUは多くのGPU世代にわたってTBDRを実装してきており、Metal 4はそれらを対象とする新しいコアAPI表面です。ここで文書化したTBDR機能（imageblock、タイルシェーダー、ラスタオーダーグループ、A11以降のサンプルカバレッジ制御）は、Metal経由で従来のMTL接頭辞付きAPIとMetal 4のMTL4接頭辞付き型の両方で動作します¹。

imageblockとスレッドグループメモリの違いは何ですか？

Appleが文書化した区別はこうです。「スレッドグループメモリは非構造化データに適していますが、imageblockは画像データにより適しています」¹。imageblockは幅、高さ、ピクセル深度、名前付きピクセル単位コンポーネントを持つ2D構造を持ちます。スレッドグループメモリはフラットなアロケーションです。アドレス指定可能なスライスを持つ構造化画像データが必要なアプリはimageblockを使い、コンピュートカーネル用のスクラッチバッファが必要なアプリはスレッドグループメモリを使います。

Metalがすでに描画呼び出し順のブレンディングを保証しているのに、なぜラスタオーダーグループが存在するのですか？

Metalは順次ブレンディングの見かけを保証しますが、GPUはフラグメントシェーダーを並列実行します。Appleの説明によれば、別の三角形の結果に対して独自のカスタムブレンディングを行うシェーダーは、2つのスレッドが実際には順次でないため競合状態に陥ります。ラスタオーダーグループは、同じピクセルを対象とするスレッドのみを同期し、それ以外は並列のままにするメカニズムなのです¹。

自前のMSAA解決アルゴリズムを書くべきはいつですか？

Appleは1つの具体的なケースを文書化しています。不透明ジオメトリと半透明ジオメトリのフェーズが分かれたシーンで、解決処理が不透明フェーズの後、半透明ブレンディングの前に実行される場合です¹。ほとんどのアプリでは、ハードウェアの組み込みMSAA実装が処理を担います。カスタム解決は、Appleのドキュメントが述べる特定のエッジケースのためのツールです。

AppleのMSAA最適化はどのように作業を節約しますか？

Appleのハードウェアは、新しいプリミティブをレンダリングする際にピクセルごとのユニークなサンプル数を追跡します。Appleの例では、2つの三角形のエッジでカバーされたピクセルは4つのサンプル位置に3つのユニークな色を持ちますが、A11以降のGPUは2つのサンプルが色を共有するため3回ではなく2回ブレンドし、その後の不透明な三角形がピクセルを単一の色に削減します¹。最適化はハードウェアレベルで実行され、アプリはAPIの変更なしにそれを得られるのです。

Apple GPUアーキテクチャはTBDRページ以外にも文書化されていますか？

Metalドキュメント内のAppleの「Apple silicon」トピックは、この投稿の元となるTBDRページにリンクしています。MetalのWWDCセッションもGPUアーキテクチャの詳細をカバーしており、Metal Shading Language Specificationはシェーダーレベルの表面を扱います。Appleは特定のApple GPU世代について、その下層シリコンレベルの詳細（クラスタ数、ALU幅、ラスタエンジンの詳細）を開発者ドキュメントには公開していません。developer.apple.com外で見つけたそうした数値は未検証として扱ってください。

References

Apple Developer, “Tailor your apps for Apple GPUs and tile-based deferred rendering”. The TBDR architecture, A11+ enhancements (imageblocks, tile shaders, raster order groups, imageblock sample coverage control), tile memory characteristics, deferred shading worked example, MSAA optimization. Retrieved 2026-05-04. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩