シェーダーバリアントが多く作られるシェーダーの最大使用メモリを計測する

こんにちは、Unityエンジニアのオオバです。

Unityでキーワードを追加して処理を分岐させながらシェーダーを書いていくと、知らず知らずのうちにシェーダーバリアントが大量に増えることがあります。シェーダーバリアントを作成するためには#prgama multi_compileまたは#pragma shader_featureを追加だけなのでとても簡単です。

以前multi_compileについて執筆したので参考にどうぞ。
Unityシェーダーのマクロとマルチコンパイル

シェーダーバリアントが増えることによってコンパイルしたシェーダーが占有するメモリが増えていきます。本記事ではシェーダーバリアント増加によるメモリ使用量の計測について説明していきいます。

👉DOTweenの教科書を読んでUnityアニメーションをプログラミングしてみよう！

multi_compileとshader_featureの違い
シェーダーバリアントが最大でどのくらいのメモリを使用するかを把握する必要性がある
一時的にshader_featureをmulti_compileに置き換えてみる
計測方法

MemoryProfilerのグラフ
MemoryProfilerのSimpleビュー
MemoryProfilerのDetailビュー

サードパーティMemoryProfilerでは確認できない
念のためにXcodeで確認
最後に

multi_compileとshader_featureの違い

前述した通りmulti_compileとshader_featureはシェーダーバリアントを作成するために使用します。

shader_featureはビルド時に使用している組み合わせのみコンパイルされる
multi_compileは定義した組み合わせ全てをコンパイルされる

という大きな違いがあります。
基本はshader_featureでシェーダーバリアントを作成した方が生成される個数は最小限に抑える事ができそうです。

Uniteでのポストモーテムセッションや技術ブログを読むと、最適化する上でmulti_compileからshader_featureに置き換える話を見かけます。

そして、ここからが本題です。

シェーダーバリアントが最大でどのくらいのメモリを使用するかを把握する必要性がある

shader_featureで指定されているシェーダーバリアントが、本来どのくらい生まれるかは開発、運用してみないと分かりません。

なぜなら前述した通り、ビルド時に使用しているキーワードの組み合わせしか作成されないためです。運用を開始してからシェーダーを改修するのは難易度が非常に高くなるため、開発中(せめて中盤頃)にコンパイルしたシェーダーが占めるの最大使用メモリは決めておきたいところです。

もう少し詳しく説明すると、集団開発する上でシェーダーはエンジニア以外も触ります。Unityエンジニアが想定する範囲内での使用なら問題ないですが、例えばクリエータがそういった暗黙の決まりを知らずにシェーダーを使ってしまう場合もあります。
すると、いつの間にかシェーダーバリアントが爆増して、メモリ使用量が増えてアプリが落ちたり、またシェーダーのコンパイルに依るスパイク(カクツキ)が問題になったりします。
※スパイクについては本記事では割愛

以上の理由からUnityエンジニアはシェーダーバリアントの影響範囲を把握しておくべきだと考えます。

一時的にshader_featureをmulti_compileに置き換えてみる

どうやってシェーダーバリアントの影響範囲を把握するかですが、一時的にshader_featureをmulti_compileに置き換えて検証してみます。

こうすることで全てのシェーダーバリアントを作成することができます。この状態でコンパイルしたシェーダーが占めるメモリを計測して、そのシェーダーのポテンシャルを測ります。

計測方法

Unityエディタ上で実行するプロファイラの値にはノイズが入りすぎててあてにならないので、必ず実機を使って計測するようにしています。具体的にはUnityエディタのProfilerに実機(iPhone6s)を繋ぎ、その中のMemoryProfilerで確認します。
※PackageからインストールするMemoryProfilerではありません