Search Unity

2021 年へのロードマップ:パフォーマンス最適化チーム

, 11月 9, 2020

先日、2021 年に向けたロードマップを発表しました。ブログでは、ロードマップで掲げた目標に向けて活動しているチームを紹介しています。チーム紹介シリーズの第2回となる本記事では、パフォーマンス最適化チームをご紹介します。

Unity は 2021 年に向けたロードマップにて、来年に優先して取り組む内容を提示しています。私たちは、皆さんから、現在の Unity に足りないものに関するご意見に基づいて、正式版機能のアップデートや、主要な新機能をお届けするための取り組みを行っています。しかし、私たちは、ワークフローを改善し、エディターで作業する際の全体的な作業のしやすさを向上させることにも同じくらい注力しています。

この記事は、ロードマップ実現に向けた仕事の舞台裏をお見せするシリーズの第 2 回目です。これらの取り組みに取り組んでいるチームに直接話を聞き、何がチームを動かしているのかを知り、チームの仕事の進捗状況を見ていきます。今回のブログ記事では、パフォーマンス最適化チームのチームリーダーLyndon Homewood とシニアソフトウェアエンジニア Richard Kettlewell に話を聞き、彼らが注力していることや来年の計画について詳しく説明してもらいます。

パフォーマンスとは、単に速度だけを指すのではない

パフォーマンスとは、実行時の速度だけを指す概念ではありません。パフォーマンスが高いと、読み込み速度、デバイス上の消費電力、エディターで作業するクリエイターが反復作業に使う時間にも改善をもたらします。パフォーマンスが悪いと、フレームが遅いと視覚的なスタッタリングが発生してユーザーの没入感を阻害したり、CPU アクティビティが過度に高くなりモバイルデバイスのバッテリーを消耗したりといった悪影響が起こります。Unity のクリエイターにとって、パフォーマンスはクリエイティブな野心に技術的な限界を設ける要素であり、それは何が作れるかということに影響を与えます。また、エディターのワークフローがどれだけスムーズであるか、フロー状態に入って、可能な限りの生産性を発揮できるかといったことにも関わってきます。

約 2 年前、Unity は機能としてのパフォーマンスに特化した最適化チームを結成しました。今回、成長を続けるパフォーマンス最適化チームを率いる Lyndon と会い、このチームの仕事の詳細を知るチャンスを得ることができました。

パフォーマンスの社内チャンピオン

このチームのミッションはシンプルです。クリエイターのために Unity エディターのワークフローのパフォーマンスを向上させ、Unity プラットフォームの幅広い範囲にわたってエンジンシステムを最適化することです。これは、最も効率的なワークフローを提供し、開発全体にわたって活用する機能が、可能な限りパフォーマンスを発揮できるようにするという 2021 年の製品に関するコミットメントと一致しています。

「パフォーマンスはユーザーにとって繰り返し現れる重要な問題です」と Lyndon は説明します。「これは、日々の Unity 開発の経験と密接に関係しています。私たちは、パフォーマンスはそれ自体が機能として扱われるべきだと考えています」と Lyndon は説明します。このような考えが、最適化専門チームの結成につながっていきました。

パフォーマンスの社内チャンピオンとして、最適化チームは R&D と全面的に協力しています。プロファイリングと最適化に関する意識と知識を高め、Unity 全体にベストプラクティスを共有します。また、プロファイリングチームは最適化チームの目標達成に不可欠なツールを提供していることもあり、緊密に連携しています。重要なパートナーはもう 1 つあり、それはこのシリーズの最初の記事で紹介した「Quality of Life」チームです。同チームは、クリエイターのためのワークフローの改善に取り組むチームで、当然ながらパフォーマンスについても考慮しています。

チームメンバーのほとんどは、ゲームシステムやゲームエンジン開発の経験が数年あるシニアエンジニアで、Unity に入社して 3 年目の Lyndon もそうです。彼にもまた、10 年の社内向け技術開発の経験があります。

ゲームを開発する上での問題点とそれを解決する技術を理解することが鍵となります。チームメンバーはパフォーマンスにこだわり、パフォーマンス向上のためにコードベースのハードウェアにできるだけ近い所まで行くために、複数のレイヤーをくぐり抜けなければならないことがよくあります。他の Unity エンジニアと協力して、既存のシステムを学んで分析し、ハードウェアをより効率的に使用するための最適な更新方法を洗い出します。

最適化の問題は、いくつかの点でチームの注意を引きつけます。小さなチームであるため、すべてを監視することはできませんが、フォーラムやソーシャルチャンネルには目を光らせ、コミュニティや製品チームにも最適化チームに問題を伝える手助けをしてもらいます。そうして集めた情報から、最も多くのユーザーに影響を与える問題を判断し、その解決を最優先します。

パフォーマンスチームの面々。上段:Kim、Lyndon、Richard。中段:Stine、John、Alex。下段:Amandine、Vicky。

パフォーマンス最適化は後回しにすべきではない

経験の浅いゲーム開発者によく行われるアドバイスは、プロファイリングを頻繁に行うこと、それも開発プロセス全体を通して進んで行うことです。もうすぐ出荷という時になって、プロジェクトのパフォーマンスを見るのでは少し遅いのです。最適化チームは 2020 年だけでも、対象としている分野のいくつかで、100 倍のスピードアップを実現する素晴らしい改善をいくつか成し遂げました。

このような結果が出るということは、最初の設計が悪かったということでしょうか。Lyndon によれば、そうではありません。「数年前の、コンテンツの需要が低かった時期に実装されたシステムや個別の機能があります。それらのシステムは、当時の要件に対してはそれなりの性能を示しましたが、ハードウェアが改良され、コンテンツの量が増えるにつれ、よりパフォーマンスの高い方法で機能を拡大していくために、基礎となるアルゴリズムを見直す必要があります。」

多くの場合、システムのスケーラビリティは Big O 記法を使って測定できます。O(n^2) の複雑さを持つシステムアルゴリズムの場合、n(コンテンツの量)が大きくなるまで、その影響の大きさに気づかないかもしれません。時には、小さなコンテナの変更がアルゴリズムを最適化して(うまくいけば O(1)まで)、パフォーマンスを大きく向上させられることもあります。

「ソフトウェア開発は生きているプロセスであり、ユーザーにとっての価値を最大化するために絶えず努力し続けることが求められます。大規模なコンテンツを持つ新しい空間や異業種へと、Unity エンジンの活用先がこれまで以上に拡大し、コンテンツが可能性の限界を押し広げていく中で、パフォーマンスを改善できる部分を見つけ出す機会が尽きることはありません。」

その好例が、Unity 2018 でのプレハブワークフローの改善です。Lyndon のチームは、プレハブの入れ子構造とバリアントが、クリエイターにより大きな柔軟性を与え、かつ大規模なシーンで作業する際の生産性を向上させるために設計に組み込まれたユーザーワークフローを通じて問題にアプローチしました。「これらのワークフローが洗練され、堅牢なものになったとき、規模を大きくしても動作することを確認するために、2 回目の検証を実行する機会を得ました」と Lyndon は述べています。結果、最適化チームは、ネスト状のプレハブの操作を最大 250 倍高速化しました。

Unity 2020.2 ベータ版にすでに搭載されている改善点

チームの最近の成果のいくつかは、すでにブログで紹介されています。こうした新しい性能改善は、Unity 2020.2(記事執筆時はベータ版として利用可能)に搭載されています。

ネスト上のプレハブの操作を最適化したほか、RegisterScriptedImporters が最大 800 倍に高速化され、2D テクスチャの読み込みが最適化されたため、サイズの大きいテクスチャを読み込む際に発生していたいくつかの不具合を回避することができました。

もう 1 つの例として、Camera.main スクリプト関数があります。この関数はこれまで、Camera.main を呼び出すと、Unity はタグ付けされたすべての GameObject のリストを検索するため、呼び出しにコストがかかる関数でした。最初に Unity は MainCamera タグを持つすべてのゲームオブジェクトのリストを作成し、その後、Unity はこの一時リストに対して 2 回目の処理を行い、Camera コンポーネントを含む最初のアクティブな GameObject を探して返すという動作をしていました。

「これは Unity に残る古い部分の例で、プロジェクトにせいぜい数百個のゲームオブジェクトしかなかった頃に書かれたものです。ゲームオブジェクトが何千個もあるのが普通になった現代のプロジェクトではうまくスケールしませんでした。」

チームのシニアソフトウェアエンジニアである Richard は、MainCamera としてタグ付けされたオブジェクトを作成時に専用のリストに保存することで、この特定のパフォーマンスのボトルネックをどのように解決したかを説明しています。この単純な変更によって、Camera.main 関数が、他のタグがついたオブジェクトを除外して MainCamera タグを持つゲームオブジェクトのみを見るようになったということです。

Spotlight Team の顧客向けプロジェクトで実証(下図)されているように「何百ミリ秒も掛かっていた部分が全部消えてしまった」のです。

改善前:

改善後:

Camera.main の最適化

2021 年に予定されていること

パフォーマンス最適化チームは成長を続けています。Lyndon と Richard は現在、チームメイトとなるべき人材を 3 人募っています。「パフォーマンスを出し切ることに情熱があり、特定のハードウェアがパフォーマンスに与える影響を徹底的に分析できる、という方をぜひチームに迎えたいと考えています。」

パフォーマンスの高いコードと、それが低レベルのハードウェアにどのようにマッピングされるかを理解することが最も重要ですが、リアルタイムゲームシステムの要件をよりよく理解するためには、ゲーム開発者としてのバックグラウンドを持っていたり、内製のゲームエンジンに携わった経験を持っていたりということも非常に有益です。パフォーマンスの高いソフトウェア開発への情熱をお持ちの方は、募集中の職種へのご応募をぜひご検討ください。

Unity の R&D では全員の仕事がある程度パフォーマンスについて触れており、最適化チームは R&D の全員と協力して、注力すべきポイントを絞り込む機会を得られます。近い将来、最適化チームは、インポートとデプロイのサイクルに関してアセットパイプラインチームと密接に連携することも見込まれています。

来年には Asset Bundle API で非同期アンロードがサポートされる予定です。これまでアンロード処理は同期的に行われていましたが、非同期アンロードを可能にすることでアンロード時のヒッチを最小限に抑えることができます。これは、既存の機能が、最適なパフォーマンスを実現するために見直され、リファクタリングされた素晴らしい例です。

チームはテストプロセスの中でコミュニティが作成したテストプロジェクトを活用しており、2021 年にはこうしたテストプロジェクトの活用をさらに広げる予定です。私たちの最も重要なベータテスターの一人である Peter77(別名 QA Jesus)によるパフォーマンステストプロジェクトなどがそうしたプロジェクトの例になります。

2021 年には、ユーザーベースが最も多いコアプラットフォームの最適化に加えて、コンソールプラットフォームやレガシーシステムにも注目し、将来にわたって Unity が次世代ハードウェアに対応していけることを保証していきます。

改善してほしい部分を教えてください

最適化チームは、機能としてのパフォーマンス向上に専念していますが、最適化作業は Unity のすべてのチームで行われています。

エディターでの作業のやりやすさを向上させるために、具体的にこの部分のパフォーマンスを改善してほしいというご要望がある方は、ぜひこの記事のコメントやフォーラムでお知らせください。

舞台裏をさらに知りたい方へ

この記事は、将来バージョンの Unity に向けた開発に取り組んでいる人たちを紹介し、それらの人々のインスピレーションと開発の原動力に触れる、開発者ダイアリーのシリーズ第 2 回目となる記事です。第1回目の記事では、コードネーム「Quality of Life」を名乗って活動するチームを取り上げました。見逃した方は、ぜひこちらのページで記事をご覧ください

今後のブログ記事で、特に取り上げてほしいチームや機能分野がある方は、この記事のコメント欄でお知らせください。

20 replies on “2021 年へのロードマップ:パフォーマンス最適化チーム”

Lol
I give Unity one more year and it will start to break appart and start to devaluate. Really I don’t see any reason to keep using Unity. There’s nothing new, nothing ground breaking. Introducing more crap that no one needs and more bugs that breaks projects.

I think optimization in the editor – not just build – is really really important, it’s really good to see work done in that direction :)) I know UIElements is faster than IMGUI for more complex things like node graphs, which is super duper fantastic.

How about making the standard shader parameters _EmissionColor and _Color instanced by default. That way the one material can have many variations without invoking multiple batches.

SRP Batcher tries to batch anything with the same shader – not material – together, if you’re lucky enough to be able to use URP/HDRP, that’s an option. Otherwise I’d advise making your own standard shader. It’s pretty helpful, since you can add whatever features you need! :)

Yes, right, but…

-Unity runtime is still a pretty outdated mono version. Not CoreCLR and not even the newest version of mono with performance improvements.
-Burst is really good, but what good does it make when most of the time the mere act of *scheduling* jobs is much more expensive than jobs themselves? And why make the job scheduling on main-thread? Do you believe that the general developer with Unity won’t be able to debug it if errors appear?
-Likewise, why so many checks for threadIndex == 0 in many classes provided by Unity? You not only waste performance with them, but you lock out developers to do certain optimizations (why do we even need TransformAccessArray?). Are you sure that the general user won’t be able to adequately debug apparent issues?
-Why does Unity first load all the queued scenes and only then activate them? Not even asset integration happens during scenes loading! (https://forum.unity.com/threads/scene-loading-best-practicies.921548/) Considering how many small, granular scenes a modern project can have, that seems like an obvious target for improvement (https://youtu.be/6lRzXqfMXRo?t=444).

I’m sorry, I’m just a bit concerned that many (if not most) performance woes are tied directly to making the engine easy/aggressively safe to use at the expense of said performance and/or opportunities to improving it.

Faster project build time in HDRP is welcomed. More performance when using many VFX graphs.
Question: when will 2020.2 be released, out of beta?

Could you implement a performance anomaly detection system that would automatically alert developers to areas of their games that are slower than average or performance bottlenecks. In theory with enough data and coverage you could build up a database of problems and solutions that could inform the developers and even autofit the problem.

Important optimization areas that I believe the team(s) should focus on:
– HDRP: very difficult to reach 120+ fps in HDRP in simple scenes whereas URP easily goes 300-400+ fps on same hardware. Even when deactivating volumetrics/refraction/subsurface/etc and other expensive stuff
– UI: perhaps the real solution to performance issues in UnityUI is using UiToolkit instead? Would be cool to hear more about UIToolkit
– Import, platform switching & build times
– Diagnostic Tools that can help any inexperienced user understand obvious ways to improve build sizes, memory usage, etc…
– A proper sample project that demonstrates good workflows for streaming of open worlds

> – Diagnostic Tools that can help any inexperienced user understand obvious ways to improve build sizes, memory usage, etc…

Hi there, I work on the UI of the Memory Profiler package. We’re aware of the general need for better Asset Profiling and will continue to improve the UX and workflows regarding Memory Profiling, but I am curious if there are any specific needs you have in mind here.

Been using Unity since 4.0 as an Environment artist – We need Mesh to terrain blending for HDRP.

https://www.youtube.com/watch?v=d_at-NawTbY – This guy nailed the visual look, the height map blending is extremely realistic and the lighting between the surface normals is perfectly clean

That the only thing we environment artists needs to start actually contributing to forums, groups and art portfolios that feature outdoor/organic.

Almost all other engines support this, its time for us to finally, hopefully, eventually show what Unity can do without it looking last-last gen.

Thank you, I hope you will consider this. Great work guys!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です