レポート一覧
GREE Tech Talk #07 : Unity Performance Casual Talk
niconico LIVE
パフォーマンスの最適化
- (描画の)パフォーマンス最適化は大きく分けて2種類
- CPUが遅い
- GPUが遅い
ドローコールとは
描画に関する何か
↓
描画が遅いっぽい
↓
ドローコールを減らせば何とかなる
↓
ではない！
- 描画処理のCPU側の処理
- 厳密にいうと、CPU側のドライバーがGPUに描画内容を渡す処理
- glDrawElements()とかが該当
CPU側の描画処理
Unity
マテリアルの設定
頂点データ、テクスチャ、カラー、マトリックスなど
↑
| ←こっちの処理のほうがだいたい重たい
↓
OpenGL ドライバ
リソースのロック
設定のバリデーション
データのコピー
ステートの保存
ここもMetal/DX12/Vulkanでマシになる(はず)
↓
GPUで描画
では、重いところは何か？
SetPass
CPU側の描画処理
Unity
↑
| ← SetPass
↓
ドライバ
Unity
↑
| ← SetPass
↓
ドライバ
↓
GPU
1回のSetPassを共有したドローコールは
大きな問題にはならない(今後さらに減る)
Unity5での具体的変更
- 描画量の最適化
- Static Batchingはドローコールの最適化を必ずしもしない
- ドローコール自体は安いが、Static Batchingで繋ぎすぎると 毎回デカいメッシュを送ることになる→GPUに悪影響
- 十分に小さいオブジェクトはBatchingする
- Static Batchingはドローコールの最適化を必ずしもしない
- ユーザーがやるべきこと
- Draw callよりSetPass Callに気を配る
- Umbraによるオクルージョンカリングを活用する(デザイン含む)
GPU側の描画の問題
- Rendererがいっぱい(ピクセル描画が重い)
- Tilerがいっぱい(頂点量が多すぎ)
- ドローコールを減らしても解決しない
GPU側の描画の問題か確認するには？
- Xcode & Instruments
- GPU Profier(Adreno, PowerVR, nVIDIA...)
GPU側の描画の問題
- Rendererがいっぱい(ピクセル描画が重い)
- fragment shaderが複雑すぎる
- テクスチャのキャッシュミスがひどい
- PVRTCなどのフォーマットの方がテクスチャのキャッシュにヒットしやすい
- Cube mapのようにランダムアクセスするテクスチャはキャッシュミスがひどい
- ピクセル描きすぎ(オーバードロー)
- Tilerがいっぱい
- 送信している頂点数が多すぎる
お約束
- モバイルは半透明に弱い(discardのコストが高い)
- 2DはUnity 2Dを使う(半透明のピクセルを極限まで減らす)
重い描画と重くない描画の発見
- Rendererがいっぱい(ピクセル描画が重い)
- fragment shaderを簡単にする - 発見方法：GPUベンダーのプロファイラ
- テクスチャのキャッシュミス - 発見方法：GPUベンダーのプロファイラ
- ピクセル描きすぎ(オーバードロー) - フレームデバッガ、Xcode、シーンビュー
- Tilerがいっぱい
- 送信している頂点数が多すぎる - フレームデバッガ、Xcode等
結論
- 描画が重い=ドローコールではない
- 重い原因に気を配ろう(思いどローコールと重くないドローコールの切り分け)
- 重い原因を解決しよう
- 原因の発見にはUnityのProfiler,Frame Debugger,GPUメーカーやベンダーのProfilerを使おう
おまけ
- Unity5でGL Frame Capureを使うには
- Unity 5.0p2以上を使用
- Player SettingsでGraphics APIをOpenGLES 2.0に設定
- Unity5でInstrumentsでシンボルを見るには
- 出力されたXcodeのプロジェクト設定でDebug Information Formatを 「DWARF with dSYM File」に設定