テラシュールブログ

旧テラシュールウェアブログUnity記事。主にUnityのTipsやAR・VR、ニコニコ動画についてのメモを残します。

【Unity】ECSの並列処理"IJobForEach"におけるスケジューリングの挙動

デカイ記事を書こうとして中々更新まで辿り着かないので、今回はサクっとECSの並列処理におけるスケジューリングの挙動について書いておきます。

 

 

IJobForEach?

 

以前は`IJobProcessCommand`という名前のAPIでしたが`IJobForEach`と分かりやすい名前になりました。

ECSは参照するComponentDataでスケジュールが決まる

ECSのIJobForEachを使用すると、特に面倒くさい事を考えなくとも良い感じにスケジューリングしてくれます。
どういった感じにスケジューリングされるのか見ていきます。

f:id:tsubaki_t1:20181223211917j:plain

結論を言えば、どちらかが同じComponentDataに書き込む可能性がある場合、並列で処理されません。逆を言えば、異なるComponentDataに書き込む場合は並列処理が可能で、ミッチリとスレッドを詰めて処理されます。


異なるComponentDataへアクセスするジョブは並列処理する

まず異なるComponentDataへアクセスするジョブは、並列で処理されます。
下の例ではSampleData1とSampleData2という異なるComponentDataへアクセスしている場合の挙動です。

gist.github.com

実行してみると、2つのジョブが並列で実行されるのが確認出来ます。

f:id:tsubaki_t1:20181023234353j:plain

これは複数のJobHandleを合成した場合も同様です。
例えば下のコードではSampleData1とSampleData2に対しての処理と、SampleData3とSampleData4に対する処理を呼び出します。
結果、全て並列で処理されました。

gist.github.com

f:id:tsubaki_t1:20181024000456j:plain

同じComponentDataへアクセスするジョブは並列処理されない

一方、同じComponentDataへアクセスしている場合。この場合は並列処理されず、片方の終了を必ず待ちます。
下のコードでは2つのシステムがComponentDataへアクセスしているので、並列で処理されることはありません。

gist.github.com

これは片方がReadOnlyだった場合も同様です。

f:id:tsubaki_t1:20181023234637j:plain

またJobHandleをまとめた場合、中にReadWriteが一つでもあれば分割されます。
下のコードではまとめたJobHandleの一つがReadWriteなので、処理が分割されています。

gist.github.com

f:id:tsubaki_t1:20181024000846j:plain

ReadOnlyのComponentData同士は並列でアクセスになる

同じComponentDataにアクセスしている場合でも、ReadOnlyの場合は同時にアクセスが可能です。

gist.github.com

f:id:tsubaki_t1:20181023235251j:plain

RequireComponentTagは並列アクセスになる

RequireComponentTagを使用しても並列アクセスになります。絶対に書き込まない設定なので、当然といえば当然ですが。

gist.github.com

f:id:tsubaki_t1:20181223210753j:plain

分割数はチャンクに依存

どうもIJobForEachの処理分割数はチャンクに依存するようになったみたいです。

要するに、たくさんComponentData(タグは除く)を持っているEntityは積極的に分割されやすく、余り持っていないデータは積極的に統合されます。
(分割数が少なければ少ない程、効率的に処理される)

 

感想

ということで並列処理の動作を見てみました。
ECSで「単一の動作を突き詰める」ようなデモを作ろうとすると、頑張って並列化を推し進めようとします。ただ、そこまで頑張らなくともジョブを発行しまくってたら意外とWorker Threadがジョブで埋まるねという感想

とりあえずJobHandleで依存関係を勝手に作ってくれるのは楽で良いです。

【Unity】ECSでチャンク単位のバッチ処理を実現するChunk Iteration、それとEntityQuery

最近のECS界隈で特に理由もなくChunk Iterationを採用されている事をよく見るので、今回そのChunk Iterationついて書いてみます。

ComponentDataの組み合わせの爆発

ECSは基本的に「特定のComponentDataの組み合わせ」で処理する対象を判定しています。Interfaceのような特定の型ではなく組み合わせです。
例えば下の図では「人力で移動するシステム」と「エンジンで動くシステム」があり、荷物のComponentDataを保持している場合には荷物に関する処理が追加されます。 System要求するComponentDataを持つEnittyが処理されていきます。この要求は「全てのブツを所持している(AND)」及び「該当のブツを所持していない(NOT)」です。

f:id:tsubaki_t1:20181016191933j:plain

さて上の図で少し気になるのが「人力」と「エンジン」のシステムです。基本的に動き自体は人力だろうとエンジンだろうと本質的には同じ「移動システム」です。コードで比較すると、多分殆ど同じようなコードになります。

ここで動力の種類の数だけSystemや EntityQuery を用意すると同じようなクエリーが大量に生成されることになるので余り宜しくないです。Interfaceで抽出出来るなら楽なのですが、ComponentData単位でしか取得出来ません。

f:id:tsubaki_t1:20181016230302j:plain

そこでECSでは「OR」を新しく追加して大雑把にEntityの組み合わせを取得、処理内で行うべき処理を割り振る機能を追加しました。
それがEntityArchetypeQuery、そしてChunk Iterationという機能です。

Chunk Iterationという回避方法

考え方は割と単純です。

EntityQueryを要求する際に緩い条件で検索をかけて、内包するComponentDataの組み合わせに応じて処理を切り替えを行うだけです。
これで要求するQueryの種類が減らせます。

検索に使用できるのはこの3種類

  • AND(全てのブツを含む)
  • OR(指定したブツが含まれる)
  • NONE(指定したブツを含まない)

例えば下の場合、今までは「人力&タイヤ」OR「エンジン&タイヤ」の組み合わせで取得していましたが、これを「(人力 OR エンジン) & タイヤ」で取得します。そして処理を行う際、保持するComponentDataが「人力」か「エンジン」かを確認し処理を切り替えます。

f:id:tsubaki_t1:20181016195416j:plain

このように複数のComponentDataを許容すると処理を行う際に1Entity毎に「実行する処理の内容を切り替える」事になりそうですが、そこらへんは大丈夫になっています。

ECSでは基本的にComponentDataの組み合わせ(archetype)毎にまとめて配置されています。この塊はチャンク(Chunk)と呼ばれます。同じチャンク内なら全て同じComponentDataの組み合わせであることが保証されています。

要するに、処理の切替えはEntity毎ではなくチャンク毎です。

f:id:tsubaki_t1:20181016201957j:plain

tsubakit1.hateblo.jp

ということで、このChunkの処理はじめに指定のComponentDataを持っているかチェックし、処理を切り替えを行っていくことで効率的なバッチ処理を実現しています。

これ逆を言えば、ORを使用しないのであれば(付属するComponent次第で処理を切り替えしないならば)EntityQueryを素直に使ったほうが多分良いです。

また効率で言えばIJobProcessComponentDataを使うのが良いそうです。

コードを書いてみる

詳しい記述方法は 【Unity】Entity Component System入門(その2)【2018.2】 - Qiita で紹介されています。この書き方は色々と応用が効きそうですが正直この書き方は苦痛なので自分はIJobChunkを使用して楽します。

まずEntityを取得する部分ですが[Inject]ではなくGetEntityQueryを使用します。その際にEntityArchetypeQueryを使用すると取得時にORを指定できます。

query = GetEntityQuery(new EntityQueryDesc()
{
    All = new ComponentType[] {
        ComponentType.ReadWrite<Translation>()
    },
    Any = new ComponentType[] {
        ComponentType.ReadOnly<ManPowerData>(),
        ComponentType.ReadOnly<EngineData>()
    },
    None = System.Array.Empty<ComponentType>()
});

次はJob側の定義です。
ジョブの取得にはIJobChunkを使用します。こちらはQueryを渡すと、Queryが参照するチャンクの数だけ並列で処理を実行してくれます。

return new MyJob
{
         ...
}.Schedule(query, inputDeps);

取得したチャンクにHasを使用して、指定するチャンクが任意のComponentDataを保持しているかチェックします。
あとはComponentDataの有無に応じて処理を分けます。

public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
{
    var array = chunk.GetNativeArray(typePosition);
    if (chunk.Has(typeManPower))
        ProcessManPower(array);
    else if (chunk.Has(typeEngine))
        ProcessEngine(array);
}

あとはジョブを実行します。

IJobChunkで実行する場合、EntityQueryを渡せば良いのでかなり楽が出来ます。
この時、チャンクのComponentDataにアクセスするためにGetArchetypeChunkComponentType()を使用します。これはEntityManagerにも同名のAPIがありますが、必ずComponentSystemのものを使用します。 自分はこのトラップに引っかかり「InvalidOperationException: The previously scheduled job」を散々見る事になりました。

全文

gist.github.com

感想

Chunk Iterationでした。

利用するシーンの多い良い機能ではありますが、無条件で使うべきものでもないので、状況次第で使っていくのが良さそうです。

追記:低レベルAPI扱いとなりました。

関連

Chunk Iterationについてディープな解説をしている記事です。

【Unity】Entity Component System入門(その2)【2018.2】 - Qiita

【Unity】Auto Sync Transformと移動時の判定、それと注意点

たぶん2017.2辺りからAuto Sync Transformという項目が追加されました。 この設定はパフォーマンスの観点からOFFが推奨ですが、ONにすべきタイミングもあるかもしれないので、その辺り少し紹介です。

Transform変更時に即座にColliderに反映させるAuto Sync Transform

Auto Sync TransformはProject SettingsのPhysicsの設定項目の一つです。
この項目をONにすると、Transformで座標を変更するたびにColliderの情報を更新するというものです。
つまり同じTransformを何度も操作するようなコードを記述していると、もしかしたら無駄な負荷を生じさせているのかもしれません。

docs.unity3d.com

f:id:tsubaki_t1:20181005231406j:plain

確認のため下のようなコードを書いてみます。

gist.github.com

このコードを実行した時、Auto Sync Transformの有無で結果が変わります。

ONだった場合、座標の変化は即座に反映するので4.5fという数値になります。逆にOFFだった場合、前フレームの最終的な座標である9.5fという数値になります。

つまりAuto Sync TransformがOFFの場合、対象の座標移動後にRaycast等のAPI接触結果を取得するために1フレーム待たなければならないという事です。
更新のタイミングはFixedUpdate後です。

テストを使用している場合に注意

これが問題になるのは、テストの時かもしれません。
例えば下のようにテスト時にCollider付きGameObjectを生成している場合、Auto Sync Transformの有無により結果が変わります。

gist.github.com

Auto Sync TransformをONにしていると全てのテストは通りますが、OFFだと生成直後や動かした直後にyield return null;を挟まないと反映されません。

f:id:tsubaki_t1:20181006005342j:plain f:id:tsubaki_t1:20181006005354j:plain

更に驚くことに、この結果はRun IN Playerを実行した場合にも変化します。
問題となるのは「1フレーム待つ」のテストが失敗している事で、その原因は「オブジェクトが生成されていない」となります。

f:id:tsubaki_t1:20181006005821j:plain

この原因はyield return null;だとFixedUpdateまで到達しないことじゃないかなと思います。試しにyield return null;yield return new WaitForFixedUpdate();に変更したところ、エディターでのテストと同じ結果になりました。

f:id:tsubaki_t1:20181006010153j:plain

後はテスト時に前のテストのゴミが残るかなーと予想していたんですが、とりあえず試した感じは残りませんでした。
はて?

感想

Collider関連をテストする時には、Auto Sync Transformは有効にしとくのが良さそうです。
逆に普通に動かす場合、Auto Sync TransformがOFFなのは理にかなっていそうです。でも当たり判定をPhysics系APIを基本としている場合は少しトラップになるかな?

軽い気持ちで調べたら意外と深刻だったでござる

【Unity】新・AnimatorのGameObjectを非アクティブにするとステートマシンがリセットされる問題の対処法

f:id:tsubaki_t1:20181004235357j:plain

以前、下のリンクで紹介した「AnimatorのGameObjectを非アクティブにするとステートマシン(その他諸々)が破棄される」問題の、対処法です。

tsubakit1.hateblo.jp

Animator.keepAnimatorControllerStateOnDisable

新しい解決方法は簡単で、animator.keepAnimatorControllerStateOnDisable = true;を呼び出すだけです。これでオブジェクトが非アクティブになった時でもステートマシンがリセットされません。

https://docs.unity3d.com/ja/2018.3/ScriptReference/Animator-keepAnimatorControllerStateOnDisable.htmldocs.unity3d.com

keepAnimatorControllerStateOnDisableはシリアライズが可能

ここで驚くべきというか面白いというかユニークなのは、Animator.keepAnimatorControllerStateOnDisableという設定、実はシリアライズが可能という事です。 エディター拡張等でAnimatorを持つPrefab郡に対して片っ端からanimator.keepAnimatorControllerStateOnDisable = true;を実行してやれば、初期化コード等が無くとも非アクティブ時のステートマシン破棄を防ぐ事が出来ます。

なおInspectorをDebugにすると、Inspector側からでも設定が可能です。

f:id:tsubaki_t1:20181004235930j:plain

何故か言語設定を「日本語」にしてると、Inspectorで表示される項目名が全く違う名前(アニメーターコントローラーレイヤー)になってるので、そこんとこ注意です。

追記: WriteDefaultは相変わらずリセットされる(正確にはアクティブ時に書き込まれてしまう)ので、GameObjectのアクティブ切替はまだ注意が必要です。

tsubakit1.hateblo.jp