UIToolkitのパフォーマンスについての公演が日本語翻訳されていました
その内容からの抜粋です
概要
ドローコールとは「グラフィックスAPIを通して、画面への描画内容を指示すること」を指します
ドローコールはグラフィックス API に対して、何をどのように描画するかを指示します。各ドローコールには、テクスチャ、シェーダー、バッファに関する情報など、グラフィックス API が画面に描画するために必要なすべての情報が含まれています。
また、ドローコールの数がパフォーマンスに直結します
描画コマンドの処理は、DrawCall を一つの基準としてドライバが処理するため、DrawCall の増加が > CPU の負荷となります。
- コマンドバッファの蓄積
- コマンドバッファ(レンダーステート)の正当性のチェック
- ネイティブな描画命令への変換
- GPU への転送
そのため、ドローコールを減らすことはゲーム全体で意識することが必要です
UnityではFrame Debuggerというツールで、各ドローコールの詳細を確認することができます
複数の描画要素を一つのドローコールにまとめるバッチ処理がどのように行われているかも確認できます
Unity6ではGameパネルに虫さんマークが追加されており、これを押すことで簡単にFrame Debuggerを開くことができます
この記事では、UIToolkitにおけるドローコール削減テクニックについて解説します
頂点バッファによるBatching
UIToolkitでは、内部で頂点バッファを持っています
頂点バッファはパネルが作られる際にメモリが確保され、そればいっぱいになると新しい頂点バッファが作られます
頂点バッファごとにドローコールが作成されるため、頂点バッファを大きくすることでドローコールを抑えられることができます
こんなUIを用意してみました
8この要素が並んでいます
全て同じテクスチャを使っており、１つのドローコールにまとめられています
ここで男の子をいっぱい増やしてみます
なんとドローコールが2つに分かれています
これは大量の画像によって頂点バッファが2つに分けられてしまったために、ドローコールがわけれられてしまっているのです
ここで頂点バッファの大きさを大きくしてみます
頂点数を15000まで増やしてみました
すると1つのドローコールにまとまります
頂点バッファが溢れなくなったことで、バッチングされるようになりました
このサンプルでは746個の要素が配置されており、ちょうど分けられなくなる頂点バッファサイズは8952でした
1要素ごとの正確な頂点はドキュメントを見つけられませんでしたが、ちょうど12倍なことから、矩形でも12頂点を使ってしまうようです
バッファサイズはメモリ確保量と直結するため、プロジェクト全体で確保しないよう気をつけてください
テクスチャ周りのBatching
UIToolkitではテスクチャの違いによってドローコールが分かれないよう、様々な工夫がされています
こんなUIを用意しました
8種類のスプライトが順番に配置されています
これはドローコールが１つにまとめられます
UIToolkit使われているシェーダーでは8個までのテクスチャを受け付けていて、その範囲内であればドローコールがまとめられるようになっています
そのため、9種類以上になると...
大量のドローコールに分けられてしまいます
これは9種類目に追加されたテクスチャによって、1ドローコールで処理できなくなったことにより分けられてしまっています
ここでPanesSettingsでDynamic Atlasの設定をします
すると1つのドローコールにまとめられます
ダイナミックアトラスによって、複数のテクスチャが1つのテクスチャにまとめられることで、テクスチャ枠を節約できているんですね
このように大量のテクスチャが設定される場面では、適切にアトラスを設定する必要があります
ここでは動的アトラスを使いましたが、通常のアトラスも対応しているのでそちらも検討してみてください