【GTMF2018TOKYO】ハードウェアの性能を活かす為の、Unityの新しい3つの機能

【GTMF2018TOKYO】ハードウェアの性能を活かす為の、Unityの新しい3つの機能
ハードウェアの性能を活かす為の、  Unityの新しい3つの機能 ver 1.1 ユニティ・テクノロジーズ・ジャパン山村達彦
Unityの目指しているものゲーム開発の民主化難しい問題の解決成功を支援今回得に解決するもの
スクリプト、基礎から考え直す ECS C# Job System Burstコンパイラ GameObject MonoBehaviour (簡単、様々な用途で使える。だが遅い） (よりHWに寄り添う）（パフォーマンスのために  　難しい事をする必要がある）
“ ” Performance By Default デフォルトで高性能なコードを
３つの機能・C# Job System ・Entity Component System (ECS) ・Burst Compiler 今回はコレの話
Entity Component System オブジェクトを制御する：存在：部品：システム
コンポーネントは状態と処理を持つ GameObjectはコンポーネントのコンテナ GameObject GameObject • ゲーム世界内での物体 • 複数のComponentを持つTransform Component Component • 単体で動作 • フィールドを持つ • ロジックを持つ • 他のComponentを操作する  （Transform等） Data Data Data Logic Logic
GameObject / Componentの場合動作はオブジェクトごとに独立動作を決める為に他のオブジェクトへの参照が必要ハンドルタイヤエンジンハンドルの入力処理曲がる動作の処理加速する動作 Data Data Data DataData
GameObject Monobehaviourは他オブジェクトへの参照を持つ Transform Move Control GameManager Gun GameFlow 参照関係が複雑になるとセットアップがややこしくなる n
GameObject / Componentの場合依存関係が面倒な場合、Singletonが活躍ハンドルタイヤエンジンドルの入力処理がる動作の処理加速する動作神 Super Special Awesome ultra Game Manager
“ ” それで、ECSではどうなってんの？
ECSではオブジェクト毎にロジックを持たせず、 ComponentSystemが一括制御する Component A Data Data Data Component A Data Data Data Component A Data Data Data Component A ComponentSystem処理処理処理毎フレーム呼ばれるイベントを持つ
ComponentSystemへのオブジェクト登録は自動 ComponentSystem Transform[] GameObject Transform Component GameObject Transform Component GameObject Transform Component GameObject 全体から効率的に自動検索。 Systemは誰がオブジェクトを  生成しているか知らなくても良い Group
取得するオブジェクト一覧は、要求するComponentでフィルタリングする ComponentSystem Transform[] Move[] GameObject Move Transform GameObject Move Transform Player 必要なコンポーネントが揃った状態で取得できる Group GameObject Transform Moveが足りない
Small Demo Rigidbody スピードキャラクター操作する  System 入力を受け付ける  System Object システムが他のシステムを参照しつつ、オブジェクトを操作する例 GameObjectEntity
Demo ComponentSystemを継承
Demo Systemが要求する Componentを登録
Demo[Inject]でオブジェクトへの参照を注入
Demo OnUpdateにオブジェクトを操作する処理を記述
複数のシステムでEntityの動きを作る入力  システム入力座標形状耐久力移動  システム当たり判定  システム死亡判定コントロール流れ作業のようにComponentDataを操作して、動きを作る
ECS上では、保有するComponentの組み合わせで動作が変わるタイヤ人力タイヤ人力荷物荷物タイヤタイヤエンジンエンジンエンジンで  移動荷物を  運ぶ人力で  移動
Groupが要求できる組み合わせ ComponentSystem Group Entityに登録した • Component • ComponentData • SharedComponentData • … を含む及びを含まない要求できるものなにこれ Entity / GameObject
Entityは超軽量なGameObject ComponentDataはロジックを持たないコンポーネント Entity • ゲーム世界でのモノ • 複数のComponentDataを持つPosition Wheel Engine ComponentData • Entityに含まれる • 値を持つ • 参照型を持たない • ロジックは持たない
GameObject Transform Component Data Data Logic Logic Position Wheel Engine EntityもGameObjectも役割は同じ「モノ」という概念 Entity
public struct Engine : IComponentData { public float power; } IComponentDataを継承値のみ持つ何もデータを持たない事もある public class Engine : MonoBehaviour { public float power; } MonoBehaviour ComponentData 定義の違い構造体
var entity_manager = World.Active.GetOrCreateManager<EntityManager>(); var entity = entity_manager.CreateEntity(typeof(Engine)); EntityManagerで生成 var obj = new GameObject(“obj”, typeof(Engine)); MonoBehaviour ComponentData 生成の違い
ComponentDataArrayや EntityArrayで取得 struct Group{ GameObjectArray objs; ComponentArray<Monobehaviour> comps; } MonoBehaviourを要求 ComponentDataを要求 Systemが要求する時の違い struct Group{ EntityArray entities; ComponentArray<ComponentData> comps; }
“ ” GameObject&Componentから EntityとComponentDataに変えて何かメリットでもあるの？ Q先程のGameObjectとの組み合わせる場合はECSハイブリットと呼ぶ
“ ” ECSが本気モードになる A ハードのお勉強
メモリキャッシュ・CPUコア CPU CPU メモリメモリからデータをロード  するのは時間がかかる１アクセスの間に２００サイクルも処理ができるメモリのアクセス速度と  CPUの性能は大きな差がある
メモリキャッシュ・CPUコア CPU CPU メモリキャッシュを活用してギャップを緩和キャッシュから使えば 100倍早くなるかも L1  キャッシュ L1  キャッシュ L2キャッシュ２〜３  サイクル２0〜３0  サイクル
一回でロードするのは64バイト 1byteしかデータを使用しない場合でも64byte単位でロードいかに無駄なくデータを  配置できるかがポイントメモリ CPU L1  キャッシュ L2キャッシュ 64byte 64byte 64byte キャッシュライン
「クラシック」の問題（１）データが散在していてキャッシュが使いにくい必要なデータを集めるのに何度もロードが必要 Transform GameObject 1 Data Renderer Data Data Data Data Monobehavour Data Data TransformRigidbody Data DataData GameObject 2 Data Monobehavour Data GameObject 3 Data Transform Data Data Rigidbody Data Data Data
「クラシック」の問題（２） float Speed; Transform transform … Vector3 up; Vector3 right; Vector3 forward; Vector3 position; Vector3 localPosition; Quatrainion rotation; Quatrainion localRotation; … MoveScript Transform 余計なデータがたくさん含まれる余計なデータでキャッシュがすぐ埋まる太字：必要なデータ細字：不要なデータ
ECSのメモリレイアウト（見た目） Positoin Positoin Positoin Positoin Rotation Rotation Rotation Rotation Speed Speed Speed Speed Entity 0 Entity 1 Entity 2 Entity 3 EntityはComponentDataを持つコンテナのように見えるが…
ECSのメモリレイアウト（実際に近いイメージ） Positoin Positoin Positoin Positoin Rotation Rotation Rotation Rotation Speed Speed Speed Speed pos Array rot Array spd Array … … … ※実際にはもっと複雑で様々な最適化を含む Entityは唯のID、実態は構造体の配列 0 1 2 3 Entity2
ECSのシステムがアクセスするデータ Positoin Po Rotation Ro Speed Sp Pos Array Rot Array Spd Array 使用するデータのみアクセスする余計なデータでキャッシュがすぐ埋まらない
連続するデータは先読み予測が効く POS POS POS POS POS POS POS POS POS POS POS POS 読んだキャッシュライン読んだ多分次はココやろ先に読んどいたるプリフェッチ
メモリはNative Containerで確保 •アンマネージドなメモリを提供＝ GCは発生しない •利便性を損なわず効率アップ •IL2CPPではインデクサが１命令 •AOSやSOAのなどに対応（get/setのオーバーヘッドなし） NativeArraySOANativeArray
NativeArray var a = new NativeArray<MyStruct>(32, Allocator.Persistent); 生成解放 Allocator.Persistent Allocator.Temp Allocator.TempJob 永続的に使用可能同じフレームで解放しないとエラー４フレーム以内に解放しないとエラー  ジョブ終了時に自動開放させるオプション有 a.Dispose();
オブジェクトの増減が低コスト POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS POS 最後の要素で塗り直すだけガベージコレクションは発生しない要素を削除したときは POS
GameObject 1 Data Renderer Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data 手続き的な手法を踏まずにオブジェクトをロード Entity Entity Entity Entity Entity Data Data Data Data レイアウトが確定しているので、ロードしたデータをそのままメモリに展開 Data Entity Entity Data Data Data Data Entity Entity ちょっと未来話 File
ECSまとめ新しいオブジェクトを制御する機構コンポーネント志向に近い形のオブジェクト制御メモリレイアウトがCPUに優しいデータ志向のレイアウトキャッシュ、フェッチを活用してアクセスを効率化 ECSで組めばHWを知らなくてもよしなにしてくれる
“ ” C# Job System 安全・簡単にマルチコアを活用
最近のコアは増加傾向にある１コア辺りのクロック数コアの数 1989 2018 ※イメージ図モバイルですら６〜8コア積んでる時代 iOS/Android
一つのコアで複数の処理を実行 Core 0 Core 1 Work Work Work Work Work Work index[0] index[1] index[2] index[3] index[4] index[5] ZZZzzz 一つのコアが作業している間、他のコアは仕事が無い
複数のコアで複数の処理を実行複数のコアで分担して作業すれば早くおわる Core 0 Core 1 Work Work Work Work Work Work index[0] index[1] index[2] index[3] index[4] index[5] だからもっとコアを活用しよう！と言いたいが、
とはいえ、マルチスレッドは難しい粒度同期競合大きな区分で仕事を任せた方が色々と早いが、分担が難しい同僚の仕事が終わらないと自分の仕事を始められない使用中のデータを、誰かが書き換えて結果がおかしくなるデッドロック互いに完了待ちしてしまい、仕事が停止するバグるとデバッグしんどいです
C# Job Systemでしんどくないマルチコア対応ルールに従えば簡単・安心にマルチコア活用 ECSとも簡単に連携できる Burstを通すと、もっと高速化並列処理で処理が完了するまでの時間を短縮
High Performance C#　（C# Job Systemの制約） Class Type無し Boxing無し GC Allocation無し Exception無し大丈夫！まだ（一応） C# All Basic Types Struct Enum Generic Properties Safe Sandbox 高速なC#を組む為のルール
メインスレッド以外もガンガン使うの楽しい
C# Job Systemの2つのAPI IJob Main Worker 0 Worker 1 Worker 2 IJobParallelFor 別のコアで処理複数のコアで一括処理 Main Worker 0 Worker 1 Worker 2 処理メインスレッドはジョブ発行するマン処理が追いつかなければメインスレッドも使って一括処理
例えばシューティングの当たり判定
C# Job Systemの基本的な流れ（１/3） pos[0] pos[1] pos[2] pos[3] pos[4] pos[5] res[0] res[1] res[2] res[3] res[4] res[5] ３つのバッファーを用意する Jobの処理は全て確保したバッファーに対して行う NativeArray <float3> NativeArray <int> 座標データとか座標的に接触したか NativeArray <int> 結局、接触したのか ans[0]
C# Job Systemの基本的な流れ（2/3） pos[0] pos[1] pos[2] pos[3] pos[4] pos[5] res[0] res[1] res[2] res[3] res[4] res[5] 複数のコアで担当する要素を処理し  結果をバッファに格納する NativeArray <float3> NativeArray <int> 計算に利用するデータ結果を格納する Core 1 で処理 Core 3 で処理Core 2 で処理
C# Job Systemの基本的な流れ（3/3） res[0] res[1] res[2] res[3] res[4] res[5] ans[0] 結果をまとめて最終的な判定を行う NativeArray <int> 最終的な結果 Core 1 で処理 NativeArray <int> 結果を格納するココを見て接触したか判定
pos[0] pos[1] pos[2] pos[3] pos[4] pos[5] res[0] res[1] res[2] res[3] res[4] res[5] Core 1 で処理 Core 3 で処理Core 2 で処理 ans[0] Core 1 で処理 IJob IJobParallelFor 弾が特定の場所に接触したかを全てのコアを使って並列処理やってみる並列処理（１）
IJobParallelForを定義（１/3） struct 弾の判定ジョブ : 　　　　　　　　{ public void Execute(int id) { } } IJobParallelForを継承した構造体を定義継承 IJobParallelFor
IJobParallelForを定義（２/3） struct 弾の判定ジョブ : IJobParallelFor { public void Execute(int id) { } } Jobが使用するバッファを定義入出力のバッファ public NativeArray<Vector3> pos; public NativeArray<int> res; C# Job Systemは入出力を明確にする
IJobParallelForを定義（3/3） struct 弾の判定ジョブ : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { } } Jobの処理をExecuteに記述 idは供給される Jobが実行する処理 res[id] = (Vector3.Distance( Vector3.zero, pos[id]) < 1) ? 0 : 1;
IJobParallelForを使う（１/4） struct 弾の判定 : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { pos[id] = (Vector3.Distance( Vector3.zero, res[id]) < 1) ? 0 : 1; } } Jobを生成 void Update() { } 生成 var ajob = new 弾の判定ジョブ()｛｝ ;
IJobParallelForを使う（２/4） struct 弾の判定 : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { pos[id] = (Vector3.Distance( Vector3.zero, res[id]) < 1) ? 0 : 1; } } Jobにバッファを登録 void Update() { var ajob = new 弾の判定ジョブ(){ } } データ参照 pos = positions, res = results1
IJobParallelForを使う（３/4） struct 弾の判定 : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { pos[id] = (Vector3.Distance( Vector3.zero, res[id]) < 1) ? 0 : 1; } } void Update() { var ajob = new 弾の判定ジョブ(){ pos = positions, res = results1 } } 実行指令１ジョブでまとめて実行する回数毎フレームScheduleを呼ぶ var handle = ajob.Schedule(positions.Length, 8);
IJobParallelForを使う（4/4） struct 弾の判定 : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { pos[id] = (Vector3.Distance( Vector3.zero, res[id]) < 1) ? 0 : 1; } } void Update() { var ajob = new 弾の判定ジョブ(){ pos = positions, res = results1 } var handle = ajob.Schedule(positions.Length, 8); } 即時ジョブ起動完了まで待つ以下は必要に応じて JobHandle.ScheduleBatchedJobs(); handle.Complete();
動かしてみる
メインスレッドの処理（ジョブの発行）ワーカースレッドの処理（当たり判定の計算）
pos[0] pos[1] pos[2] pos[3] pos[4] pos[5] res[0] res[1] res[2] res[3] res[4] res[5] Core 1 で処理 Core 3 で処理Core 2 で処理 ans[0] Core 1 で処理 IJob IJobParallelFor やってみる並列処理（2）
IJob struct 結果を受け取るジョブ : 　　　{ public void Execute() { } } 継承 IJob
IJob struct 結果を受け取るジョブ : IJob { public void Execute() { } } 入出力 public NativeArray<int> res; public NativeArray<int> ans;
IJob struct 結果を受け取るジョブ : IJob { public NativeArray<int> res; public NativeArray<int> ans; public void Execute() { } } ジョブの実行内容 var length = res.Length; for(var i=0; i<length; i++){ if( res[i] == 1){} }
IJob struct 結果を受け取るジョブ : IJob { public NativeArray<int> res; public NativeArray<int> ans; public void Execute() { var length = res.Length; for(var i=0; i<length; i++){ if( res[i] == 1){ return ;} } } } 結果を格納 ans[0] = 1; ans[0] = 0;
IJob struct BJob : IJob { public NativeArray<int> res; public NativeArray<int> result; public void Execute() { for (var i = 0; i < positions.Length; ++i) { var pos = positions[i]; if( pos.x > -0.5f && pos.x < 0.5f){ result[0] = 1; return; } } } } 要素への参照なので危険がつきまとう読込専用なら兎も角、読み書きするジョブが複数同時に同じ要素を操作するとヤバイ [ReadOnly]や[WriteOnly]属性をつけるデータの読取専用データの書込専用
IJob struct 結果を受け取るジョブ : IJob { public NativeArray<int> res; public NativeArray<int> ans; public void Execute() { var length = res.Length; for(var i=0; i<length; i++){ if( res[i] == 1){ans[0] = 1; return ;} } ans[0] = 0; } } 読取専用・書込専用の属性を付ける [ReadOnly] [WriteOnly]
問題が起こりそうならエラーを出してくれる InvalidOperationException: The previously scheduled job Job1:AJob writes to the NativeArray AJob.positions. You are trying to schedule a new job Job1:BJob, which writes to the same NativeArray (via BJob.positions). 要約：複数のジョブが同じNativeArrayに同時に書き込むかも
InvalidOperationException: The native container has been declared as [WriteOnly] in the job, but you are reading from it. 要約：書込専用のNativeArrayを読み込んじゃあかん問題が起こりそうならエラーを出してくれるありがたや
ジョブの依存関係 Scheduleの引数にJobHandleを入れる void Update() { var ajob = new 弾の判定ジョブ() { …}; var bjob = new 結果を受け取るジョブ() { … }; var handle = ajob.Schedule(positions.Length, 8); handle = bjob.Schedule(handle); } bJobはaJobが完了したら実行
動かしてみる
集計処理メインスレッド
ECSとのC# Job Systemの連携（１） public struct RigidbodyPositionJob :　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 { } [Inject]無しにComponentData注入、若干効率的 Injectの代わりにジェネリックでComponentDataを要求 IJobProcessComponentDataを使う IJobProcessComponentData<Position, RigidbodyPosition>
ECSとのC# Job Systemの連携（２） public struct RigidbodyPositionJob : IJobProcessComponentData<Position, RigidbodyPosition> { } [Inject]無しにComponentData注入、若干効率的 [ReadOnly][WriteOnly]属性で、競合しないように、ジョブの実行順を自動調整してくれる機能付 IJobProcessComponentDataを使う public void Execute(ref Position pos, ref RigidbodyPosition rot) { // 処理 }
.NETのThreadと比較して、どう違うの？ UnityのWorker Thread上で動作コンテキストスイッチの増加を防ぐオーバーヘッドが少ない ※IL2CPPでビルドした場合使うための制約がキツイハイパフォーマンスなC#記述を強制ケースバイケースで使い分け推奨 .NET 4.xやC#7.2対応で使えるようになった複数フレームを跨ぐ処理に向かないそもそもコアを使い切る為のもの
結局、マルチスレッドの難しい点は解決出来たか？ • ジョブのまとめて実行する数を指定できる　→粒度をある程度コントロールする・複数のジョブが同じ参照先に書き込み可能だとエラー　→競合の発生をエディターで防ぐ
結局、マルチスレッドの難しい点は解決出来たか？・ジョブはメインスレッドでのみCompleteできる　→デッドロックを起こさない・ジョブはメインスレッドでのみScheduleできる　→Completeとの整合性を重視
“ ” 危険なのは自由すぎるマルチスレッド
“ ” Burst 厳しい条件下で最適化するコンパイラ
第三の選択肢 IL2CPP Burstコンパイラ使い勝手を維持しつつ単純にC++へ変換厳しい条件下で最適化 Mono IL １ 2 3 option option option
厳しい前提条件の上で最適化 High Performance C#前提 Class Type無し Boxing無し GC Allocation無し Exception無し連続したメモリレイアウト前提データの入出力がハッキリしてる前提制約を設ける事で限界まで最適化 ECSやC# JobSystemで組めばOK
struct 弾の判定 : IJobParallelFor { public NativeArray<Vector3>pos; public NativeArray<int> res; public void Execute(int id) { pos[id] = (Vector3.Distance( Vector3.zero, res[id]) < 1) ? 0 : 1; } } 使い方 IJoｂ系のインターフェースに BurstCompile属性をつける [Unity.Burst.BurstCompile]
Burst OFF Burst ON だいたい0.2msだいたい 7ms （IL2CPPで4倍くらい高速化）
様々な最適化最適化しやすいMathライブラリも提供 CPU拡張命令を積極的に使う計算の精度を下げる（オプション）厳密な結果が必要ない箇所に使うオプションプロセッサ向けの最適化をUnityで行う avx2, sse4, neon, arrch その他、様々な最適化
Burstでコンパイルした後のアセンブリは確認出来る最大効率でないなら、レポートすれば修正が入るかも
PackageManagerで提供新しいプロセッサが追加された際、  Unityエンジンを自体をアップデート  せず対応が可能 ECSパッケージには最初から含む
“ ” ECSでメモリレイアウト制御（難しい）をよしなにしてくれる C# Job Systemでマルチコア対応（難しい）をよしなにしてくれる BurstでCPU演算向け最適化（難しい）をよしなにしてくれるまとめ
“ ” 頑張って最適化せずとも最初から最大効率で動作するコードになるまとめ
“ ” 空いた余剰スペックでもっと多くの要素をゲームにつぎ込めるように Thank You オブジェクト管理消費電力処理時間

Check these out next

【GTMF2018TOKYO】ハードウェアの性能を活かす為の、Unityの新しい3つの機能

Recommended

More Related Content

Slideshows for you(20)

Similar to 【GTMF2018TOKYO】ハードウェアの性能を活かす為の、Unityの新しい3つの機能(20)

More from Unity Technologies Japan K.K.(20)

Recently uploaded(20)

【GTMF2018TOKYO】ハードウェアの性能を活かす為の、Unityの新しい3つの機能