ドローコールからセットパスへ ― 描画コスト管理の10年間の変遷

「ドローコールを減らせ」――Unity開発者なら一度は聞いたことがあるアドバイスだ。検索すれば、Dynamic Batching、Static Batching、アトラス化、メッシュ結合…… 無数の「ドローコール削減テクニック」がヒットする。

しかし、その記事はいつ書かれたものだろうか。

Unity 6（URP / HDRP）の時代、最も重要な描画コスト指標はドローコール数ではなく、セットパスコール数に変わっている。SRP Batcherが標準搭載され、同じシェーダーを使うオブジェクトであれば、マテリアルのパラメータが異なっていても自動的に描画コストが最適化される。にもかかわらず、「ドローコールを減らそう」という古い情報が大量に残っているため、初学者は何を指標にすべきか分からない。

本記事では、描画コスト管理の歴史的変遷を辿り、「今、何を見て、何をすべきか」を明確にする。

本記事は「ゲームエンジンのレンダリング技術」シリーズの第1.5回です。シリーズ全体の構成は記事末尾をご覧ください。

描画の裏側: CPUとGPUの会話

ドローコールとは何か

ゲーム画面の1フレームを描くために、CPUは「このメッシュを、このマテリアルで、この位置に描け」という命令をGPUに送る。この命令1回分がドローコールだ。

問題は、ドローコールそのものではなく、その前後に発生する状態変更にある。GPUに新しいメッシュを描かせるたびに、CPUは以下を準備する必要がある。

準備作業	内容	コスト
テクスチャ設定	使用テクスチャをVRAMに配置	高い
シェーダー切り替え	GPUプログラムの変更	非常に高い
マテリアルパラメータ	色・光沢度などの値を送信	低い
トランスフォーム	位置・回転・スケール	低い

ここで注目すべきはコストの差だ。シェーダーやテクスチャの切り替えは重いが、マテリアルパラメータやトランスフォームの送信は軽い。この差が、後述するSRP Batcherの設計思想の根拠となる。

状態変更が本当のボトルネック

2000年代後半の計測データでは、状態変更なしなら1フレームで約6,000回のドローコールが可能だった。しかし、テクスチャを毎回変えると処理能力は1/3に落ち、シェーダーまで変えると1,000〜2,000回が上限になった。

状態変更なし:           ~6,000 ドローコール/フレーム
テクスチャ変更あり:      ~2,000 ドローコール/フレーム（3倍遅い）
シェーダー変更あり:      ~1,000 ドローコール/フレーム（6倍遅い）

つまり、ドローコールの「数」が問題なのではなく、ドローコール間の「状態変更の重さ」が問題だった。この事実が見落とされたまま「ドローコール数を減らせ」という簡略化されたアドバイスが広まった。

Unity 5時代: バッチングの全盛期

Dynamic Batching ― ランタイムでメッシュを結合

Unity 5以前の最適化の主役は Dynamic Batching だった。同じマテリアルを使う小さなメッシュを、ランタイムで1つのメッシュに結合して描画する。

結合前: 岩A(ドローコール) + 岩B(ドローコール) + 岩C(ドローコール) = 3ドローコール
結合後: [岩A+B+C](ドローコール) = 1ドローコール

しかし、制約が極めて多い。

制約	条件
頂点属性の合計	900以下（シンプルシェーダーで300頂点、複雑シェーダーで180頂点）
メッシュ数/バッチ	最大300
インデックス数	最大32,000
マテリアル	全オブジェクトが完全に同一のマテリアル参照
スケール	均一 or 非均一で統一（混在不可）
シャドウ	リアルタイムシャドウ受け不可

さらに、バッチ結合の処理自体がCPU負荷を生む。バッチあたり数個しかメッシュがない場合、結合のオーバーヘッドが削減効果を上回るという本末転倒な状況も起きた。

Static Batching ― ビルド時にメッシュを結合

Static Batchingは、ビルド時に動かないオブジェクトのメッシュを結合する。Dynamic Batchingの頂点数制限を回避できるが、別の問題がある。

メモリの爆発: 同じ木のメッシュを1,000本配置すると、1,000個分のメッシュデータがメモリに複製される。元メッシュが1MBなら、1GBのメモリを消費する。

オクルージョンカリングとの相性: バッチ内の1オブジェクトでも可視なら、バッチ全体が描画される。壁の向こうの見えないオブジェクトも含めて描画してしまう。

この時代の指標: Statsウィンドウの「Batches」

Unity 5時代、開発者が見ていたのはGame ビューの Stats ウィンドウに表示される「Batches」の数だった。この数を減らすことが最適化の目標とされていた。

転換点: SRP Batcherの登場

セットパスコールという新しい指標

2018年、Unity が Scriptable Render Pipeline（SRP）と共に導入した SRP Batcher は、描画コスト管理のパラダイムを根本から変えた。

SRP Batcherが変えたのは、「何を削減対象とするか」 だ。

時代	削減対象	手段
Unity 5以前	ドローコール数	メッシュ結合（バッチング）
SRP Batcher以降	セットパスコール数	シェーダーバリアント単位の状態キャッシュ

セットパスコール（SetPass Call） とは、GPUのシェーダープログラムを切り替える操作のことだ。前述の「状態変更のコスト」のうち、最も重い「シェーダー切り替え」に対応する。

SRP Batcherの仕組み: CBufferによるキャッシュ

SRP Batcherの核心は、マテリアルのプロパティをGPU側のConstant Buffer（CBuffer） にキャッシュする仕組みだ。

従来のパイプライン:

オブジェクトA描画:
  → シェーダー設定 → マテリアルパラメータ送信 → トランスフォーム送信 → 描画

オブジェクトB描画（同シェーダー、別マテリアル）:
  → シェーダー設定 → マテリアルパラメータ送信 → トランスフォーム送信 → 描画
  ↑ シェーダーが同じでも毎回再設定していた

SRP Batcher:

オブジェクトA描画:
  → シェーダー設定（1回だけ）
  → CBuffer[A]のマテリアルパラメータ参照 → CBuffer[A]のトランスフォーム参照 → 描画

オブジェクトB描画（同シェーダー、別マテリアル）:
  → シェーダーはそのまま（セットパス不要）
  → CBuffer[B]のマテリアルパラメータ参照 → CBuffer[B]のトランスフォーム参照 → 描画

各マテリアルのプロパティはGPUメモリに常駐し、描画時はバッファのポインタを切り替えるだけで済む。シェーダーを再設定する必要がないため、セットパスコールが発生しない。

何がセットパスコールを発生させるのか

ここが初学者が最も混乱するポイントだ。整理しよう。

状況	セットパス発生?	理由
同シェーダー、同マテリアル	No	何も変わらない
同シェーダー、色が違うマテリアル	No	パラメータはCBufferで管理。シェーダーは同じ
同シェーダー、テクスチャが違うマテリアル	No	テクスチャもCBufferのリソース参照で管理
違うシェーダーのマテリアル	Yes	GPUプログラムの切り替えが必要
同シェーダーだがバリアント違い（キーワード差分）	Yes	内部的に別シェーダープログラム
Shader Graphの同グラフでSurface Optionsが異なる	Yes	Transparent / Opaque で別バリアント

核心: SRP Batcherが気にするのは「シェーダーバリアント」が同じかどうかだけだ。マテリアルのパラメータ（色、テクスチャ、数値）がいくら違っても、同じシェーダーバリアントなら追加コストは発生しない。

今、何を見て、何をすべきか

指標: Frame Debuggerを使う

Stats ウィンドウの「Batches」はもう最重要指標ではない。代わりにFrame Debugger（Window → Analysis → Frame Debugger）を開き、以下を確認する。

確認項目	見るべき場所	目標
セットパスコール数	Frame Debugger左パネルの階層	シェーダー切り替え回数を最小化
SRP Batcherの効果	各ドローコールの「SRP Batcher」表示	「SRP Batch: X draw calls」が大きいほど良い
バッチ破壊の原因	ドローコール間の変更理由	「Different shader」が多い場合は改善余地あり

やるべきこと: 5つの実践ルール

1. SRP対応シェーダーを使う

SRP Batcherの恩恵を受けるには、シェーダーが SRP Batcher互換である必要がある。

Shader Graph: 自動的にSRP互換。何もしなくてよい
URP Lit / Unlit: SRP互換
カスタムHLSL: UnityPerMaterial CBuffer にプロパティを正しく配置する必要がある

// SRP Batcher互換のカスタムシェーダー例
CBUFFER_START(UnityPerMaterial)
    float4 _BaseColor;
    float _Smoothness;
    float4 _BaseMap_ST;
CBUFFER_END

UnityPerMaterial CBuffer の外にプロパティを置くと、SRP Batcherが無効になる。

2. シェーダーバリアントを減らす

同じShader Graphでも、#pragma multi_compile や #pragma shader_feature で大量のバリアントが生成される。Shader Graphの Surface Options が異なるマテリアルは別バリアントになる。

悪い例: オブジェクトごとに Opaque / Transparent を混在
良い例: 不透明オブジェクトは全て同じ Lit シェーダー（Opaque）で統一

3. マテリアルの違いは気にしない

SRP Batcher時代において、「マテリアルを共有してメモリを節約する」旧来の最適化は優先度が下がった。色やテクスチャが異なる100個のマテリアルがあっても、同じシェーダーなら描画コストは変わらない。

旧時代: 赤い壁と青い壁 → 同じマテリアルに統合（テクスチャアトラス化）
現代:   赤い壁と青い壁 → 別マテリアルでOK（SRP Batcherが処理）

4. GPU Instancingは「同一メッシュ大量描画」に限定

GPU Instancingは、同一メッシュ + 同一マテリアルを大量に描画する場合にのみ有効だ（草、パーティクル、群衆など）。SRP Batcherと併用はできない（どちらか一方が適用される）。

ケース	推奨
異なるメッシュ、同じシェーダー	SRP Batcher
同一メッシュを数千個配置	GPU Instancing
大量の草・木	GPU Instancing + Indirect描画

5. Dynamic / Static Batchingの位置づけ

SRP Batcher有効時、Dynamic BatchingとStatic Batchingは基本的に不要だ。

Dynamic Batching: URP設定でデフォルトOFF。ONにするとSRP Batcherと競合し、かえって遅くなる場合がある
Static Batching: メモリ消費が大きいため、SRP Batcherで十分な場合は無効にすることを検討する

歴史の対比: 同じシーンで何が変わったか

100個のオブジェクト（10種類のシェーダー × 各10色のマテリアル）を描画する場合:

手法	ドローコール	セットパスコール	状態変更
バッチングなし（Unity 4）	100	100	毎回フル
Dynamic Batching（Unity 5）	~30	~30	バッチ単位
SRP Batcher（Unity 6）	100	10	シェーダー単位

SRP Batcherではドローコール数は減らない（100のまま）。しかし、セットパスコールが10（シェーダー数）に激減する。ドローコール間の状態変更コストが消えるため、100回のドローコールが高速に連続実行される。

SRP Batcherの本質は「ドローコールを減らす」のではなく「ドローコールを軽くする」ことだ。

まとめ

観点	要点
歴史	ドローコール削減（Unity 5）→ セットパスコール削減（SRP Batcher）へパラダイムが移行した
本質	描画コストの主因は「シェーダー切り替え」であり、マテリアルのパラメータ差異ではない
指標	Stats の Batches ではなく、Frame Debugger でセットパスコール数を確認する
実践	SRP互換シェーダーを使い、シェーダーバリアントを減らす。マテリアルの統合は優先度低
注意	Dynamic Batching は SRP Batcher と競合する。GPU Instancing は同一メッシュ大量描画に限定

シリーズ案内: ゲームエンジンのレンダリング技術

回	テーマ
第1回	レンダリングパイプラインの全体像
第1.5回（本記事）	ドローコールからセットパスへ
第2回	ライティングとライトマップの技術
第3回	シャドウとアンビエントオクルージョン
第4回	アンチエイリアシング完全ガイド
第5回	ポストプロセスで画をつくる

参考情報

資料	著者/出典	内容
Unity 5 Game Optimization	Chris Dickinson	Dynamic/Static Batchingの詳細制約
Video Game Optimization	Eric Preisz	ドローコール計測とステート変更コストの実測
SRP Batcher: Speed up your rendering	Unity Technologies	SRP Batcherの公式解説
GAMES104 Lecture 07	Wang Xi	レンダリングパイプラインの包括的講義

本記事は UniMCP4CC プロジェクトの技術知見を基に執筆しています。Unity × Claude Code でのゲーム開発に興味がある方はぜひご覧ください。