大規模スケールにおけるパフォーマンス：Unreal Engine 4.26 のシーケンサー

 
セクションには一般的に、キーフレーム データと、タイムラインに沿ってそれぞれのトランフォーム、プロパティ、またはアニメーションの希望の状態を定義する他のプロパティが含まれています。ゲーム内でシーケンスを再生する際のエンジンの役割は、これらのトラックとセクションをすべて受け取り、ゲーム ワールドから解決された目的のオブジェクトに正しい状態とプロパティを適用することです。

4.26 より前のバージョンでは、これらのトラックとセクションのそれぞれには、特定のタイミングで評価を行い、解決されたオブジェクトにプロパティを適用するために必要なデータとロジックの両方を含む独自のランタイム インスタンスがありました。これらのインスタンスは従来のオブジェクト指向のパラダイムを使用するよう設計されており、仮想 API を通じてアクセスします。このアプローチでは、少数のトラックについては許容範囲のパフォーマンスを提供できますが、トラックの数が増加して相対的な複雑度が増すとうまく対応できなくなります。さらに、膨大な数のアニメーションまたはシーケンスを並行して実行すると、それぞれのインスタンスのパイプラインを初期化するための、高レベルのパフォーマンス コストが増加します。

広範なユース ケースの CPU プロファイル データへのアクセスにより、最適化のための努力の結果、仮想関数呼び出し固有のオーバーヘッドと低レベルのキャッシュ局所性が原因で、大規模スケールにおいては収穫逓減が生じることが明らかになりました。さらに、ブレンド、部分的にアニメートされたトランスフォーム、トランスフォームの相対的原点、アタッチメント、コンポーネント速度などに対する役割が増すにつれて、トランスフォーム トラックなどのトラックが負担となりつつありました。

コンソールまたはモバイル ハードウェア上のその他すべてのゲーム システムとともに、このようなコンテンツをリアルタイムで実行するために必要な最適化を実現するには、さらに多くのシステム再設計が必要であることが明らかになりました。
 

スピード重視のデザイン

シーケンサー ランタイムの新しい基礎について、当社ではデザインに関して次の各目標に重点を置きました。

スケーラビリティ
新しいランタイムでは、数百ものトラックまたはシーケンスを含むコンテンツの作成が可能になり、このコンテンツ全体の評価ロジックを最適化することができるようになります。これには以下が含まれます。

• アクティブなシーケンサー トラックの数によってパフォーマンスがすぐに低下しないよう、データを割り当てて整理する。
• 不要なロジックとブランチを完全に削除する機能。フレームごとにかかるこれらのコストを省くことができます。最速のコードというものは存在しません。これは、最上位のレベルだけでなく、シーケンサー評価コードのあらゆる面で適用できるはずです。
• 評価ロジックには、複雑または非効率的な抽象化を通じてメモリとやり取りする必要なく、バッチ内の必要なデータへの無制限で直接的な高効率のアクセスが必要。

同時並行性
評価ロジックの記述はシンプルで、アップストリーム/ダウンストリームの依存関係 (すべてのカーブを並行して評価するなど) についての柔軟な表現の定義を含む、複数のコアに安全・効果的に自然な形で拡張されるものである必要があります。これにより、パイプラインを一度だけ設定すればよいという利点によって、多数の小さくて軽量のアニメーション、さらには巨大なシーケンスに関連してメリットがもたらされます。

拡張性
コア システムを再実装せずに、ロジックをビルトインの機能に加えることができる必要があります。また、コア機能とやり取りするアップストリームまたはダウンストリームの機能の追加も合理的にある程度可能である必要があります。これには以下が含まれます。

• 現在のフレームのデータは、パイプラインのあらゆる時点ですべて透明で可変である必要がある。
• 信頼のおける依存関係管理。

これらのデザイン目標は、問題のあるシーケンサー領域も併せて、データ指向のデザイン原則が適していることを示しています。これには次の理由が挙げられます。

• ほとんどのシーケンサー データは一様であり、連続してレイアウトすることが可能。
• 一般的に、各データ トランスフォーメーションのロジックは自己完結型であり、コンテキストに依存しない (例：カーブに対して f(x) を実行)。
• 制御およびデータ フローはリニアであり、循環依存または再帰依存は存在しない (例：計算済みの値の再計算を必要とするロジックはない)。
• スレッド化について制限があるのは、初期の設定と最終的なプロパティのセッターのみ。

4.26 は、エンティティ コンポーネント システムのパターンに基づき、評価フレームワークを介して、キャッシュ効率が高く透明な方法で評価データがレイアウトされるように再デザインされています。トラック インスタンス (内部では「テンプレート」と呼ばれる) は、評価において必須ではなくなりました (ただし、レガシー ランタイムは新しいシステムとともに実行されます)。代わりに、トラックのそれぞれのタイプのデータとロジックが分離されました。エンティティがソース トラック データに関連するコンポーネントのパーツを表し、システムが特定のコンポーネントまたはコンポーネントの組み合わせに関連する単一のロジカル データ トランスフォーメーションを表すようになりました。システムでは、クエリに一致するすべてのデータをバッチで処理するようになりました。これにより、例えばすべてのトランスフォーム プロパティや、すべての浮動小数点チャンネルの評価を行うキャッシュ効率の高いアプリケーションが、アニメートされるトランスフォーム プロパティの数にかかわらず、キャッシュミスもほとんどなしに単一の関数呼び出しのみで有効になります。

結果として、4.26 以降のバージョンから移行したトラック タイプの大規模コンテンツに対する、シーケンサーによる評価にかかるオーバーヘッドが大幅に低下しました。 

さらに、このアプローチでは多くのシーケンスまたはウィジェット アニメーションの評価データを融合することもでき、実行中の一連のアニメーション全体に対する最適化の可能性がさらに広がります。これにより、以前よりも多くのウィジェット アニメーションを同時に実行し、必要に応じて、複数の個別のアニメーションまたはシーケンスを一緒にブレンドできるようになります。

パイプラインの例 
すべてのトランスフォーム トラックを評価するためのパイプラインの例を見てみましょう。シーケンサーのトランスフォーム トラックは、そのコンポジット浮動小数点 (位置 - X/Y/Z、回転 - ロール/ピッチ/ヨー、スケール - X/Y/Z) に対する 1 ～ 9 個のキーフレーム チャンネルで構成されています。トランスフォームをオブジェクトに適用するには、まず現在の時点におけるこれらのカーブを評価し、次にその結果とともに USceneComponent::SetRelativeTransform を呼び出します。4.26 より前のバージョンでは、チャンネル データは、最大 9 個のチャンネルと、これらのチャンネルを評価してオブジェクトに適用するロジックを含むテンプレート オブジェクトにコピーされていました。

以下に示す理由により、新しいアプローチには大幅な改善がなされていることがわかります。

• 関心、データ、インストラクション キャッシュ局所性がよりうまく分離され、大規模スケールにおいてより高速であることが実証されている。 
• 仮想関数呼び出しの数は、個別のトラック数ではなく、アクティブなシステム タイプの数に伴ってスケーリングされる。 
• キャッシュミスの数は、データ全体のサイズではなく、コンポーネント データの組み合わせの数に比例している。 
• さらに、最適化がそれぞれのトラックに限定されるのではなく、すべてのデータ セットにわたってこれらのメリットを得られる可能性がある。 
• ロジックの大幅な変更なしに、パイプラインのパーツを並行して作成できるようになった。

例えば、上記の例で示されている「Evaluate Float Channels」(浮動小数点チャンネルの評価) システムでは、アニメートするプロパティや、組み合わせまたは適用方法にかかわらず、現在のフレームの浮動小数点チャンネルをすべて同時に評価することができます。

さらに、複数のトランスフォームを単一のオブジェクトにブレンドするものなど、中間データ トランスフォーメーションの導入がよりシンプルになり、より区分化されるようになります。

4.26 より前のバージョンでは、この機能は、すべてのプロパティ タイプのすべての入力/出力を格納して処理する専用クラス内に実装されていました。これにより、小さな割り当ての最適化とダイナミック ディスパッチにかかるコストが原因で、格納と CPU のオーバーヘッドが生じました。また、さらに複雑度が増し、共通コード パス (ブレンドなし) に降格されたブレンド コード パスを理解できるよう、プロパティの適用を表現する必要もありました。

メモリのレイアウト

シーケンサーのメモリ内における評価データの様子を詳しく見てみましょう。当社では、データ レイアウトに対するさまざまなアプローチを試した結果、メモリ サイズ、キャッシュ効率、再割り当てコスト、同時アクセスのバランスがうまく取れている下記のデータ モデルを採用することにしました。 

各エンティティは、「エンティティ割り当て」と呼ばれるバッチごとにグループ化されます。それぞれの割り当てには少なくとも 1 つのエンティティが含まれています。ここで重要なのは、割り当てに含まれるすべてのエンティティには、同じタイプのコンポーネントが同じ数だけ含まれている点です。コンポーネントを特定のエンティティに追加または削除すると、このコンポーネントは異なる (または新規の) 割り当てに移行されます。それぞれの割り当てのサイズは、予約されているキャパシティに応じてダイナミックに設定されており、malloc への呼び出しなしに新しいエンティティを追加できます (必要なのはコンポーネント データの初期化のみです)。

ご覧のとおり、割り当て内では同じタイプのコンポーネントがすべて連続して並べられています。コンポーネント A、B、C を含む割り当てでは「AAA..A、BBB..B、CCC..C」というようにレイアウトされ、それぞれのタイプはキャッシュ行に沿って配置されます。データをこのように整理することで、エンティティ ID に影響を及ぼすことなく、そのエンティティ データの位置を制御できます。また、タイプ間の優れたパッキングを維持しながら、各コンポーネント配列に対する読み取りまたは書き込みアクセスを制御することも可能です (現時点ではミューテックスを使用しますが、競合が問題になる場合は将来において専用のスケジューラに拡張される可能性があります)。コンポーネント A と B のすべてのコンポーネント データをシステムで読み取る場合は、(ビット マスクで示された) 割り当てのタイプを確認するだけで済みます。このことから、システムでは、含まれる (数千にも及ぶ可能性のある) エンティティが、目的とするタイプと一致するかどうかを瞬時に判断できることがわかります。 

この「パターン マッチング」のアプローチでは、データ トランスフォーメーション ロジックをデータのコンポジションから完全に切り離すため、システムでは、関連しないパーツに関する情報なしに、大規模スケールでのパフォーマンスを維持しながら、コンポーネント データのさまざまな多数の組み合わせを並行して処理することができます。上記の例をさらに展開すると、すべてのトランスフォーム トラックをトランスフォーム原点に相対付けるシステムの挿入は簡単で、コア トランスフォーム システムへの煩わしい変更は必要ありません。

スレッド化

読み取り元と書き込み先のコンポーネントのタイプについてロジックを定義できるようになったので、コンポーネント データに対するアップストリームおよびダウンストリームの依存関係も定義できるようになりました。これにより、合理的な場合には、これらのデータ トランスフォーメーションをタスク グラフに安全かつ自動的に、そして非同期でディスパッチできるようになります。複雑なキーフレーム カーブを多数含むコンテンツなど、大規模なデータ セットを評価する際は、他の計算処理とともにこのようなカーブの評価を非同期で実行することができ、プラットフォームで許容されている並列処理を行うことができます。コンテキスト切り替えまたはスレッド プリエンプションの潜在的なコストと比べて見合うものであれば、これにはメリットがありますが、スレッドセーフな設計が施されたシーケンサーでは、この判断を内部で、またはユーザーが行うことができます。

シーケンサーで作業するプログラマー向けの包括的なアーキテクチャ詳細情報については、近日公開予定です。
 

旧版ランタイム システムと 4.26 以降のビヘイビアの違い

全般的に、ビヘイビアについては大きな変化はありません。スポーン可能なものやアタッチメント、トランスフォームやその他のプロパティは以前と同様に機能します。ただし、次に示すような細かな点は変更されました。

• 同じタイプの複数のアクティブ シーケンスがすべて同時に評価されるようになりました。4.26 より前のバージョンでは、2 つの異なるアクティブ シーケンスが同じオブジェクトの同じプロパティでアニメートされる場合、それぞれが個別に評価されるため、そのプロパティのコントロールを巡って競合が生じます。4.26 ではこれらのシーケンスが一緒に評価され、自然な形で互いにブレンドされます。将来のリリースでは、シーケンスのブレンドまたはオーバーライド方法を制御できるよう機能拡張される予定です。
  • すべてのアクティブなウィジェット アニメーションがまとめて評価されるようになりました。
  • すべてのアクティブなレベル シーケンスがまとめて評価されるようになりました。
• シーケンスまたはウィジェット アニメーションに対する手動での再生、停止、または位置設定時に、場合によっては、当該の関数呼び出し内でシーケンスが同期的に再評価されないようになりました。このような場合は、シーケンスの再生ヘッドを再生または移動するためのリクエストが次のフレームまで延期されることがあります。
  • パフォーマンス コスト (負荷) はかかりますが、シーケンスの [Async Evaluation (非同期評価)] オプションを無効にすることで、特定のシーケンスに対してこれを無効にすることができます。このように設定すると、同期的な再評価が強制的に実行され、前述のブレンド ビヘイビアは無効になります。

 

• シーケンス評価に関して再入可能性が生じるイベント トラック (他のシーケンスを再生するイベントや再生状態を変更するイベント、再生ヘッドを移動するイベントなど) は、Post Evaluation 位置に限定されるようになりました。例えば、PreSpawn または PostSpawn では許可されません。これが、新しいイベント トラックのデフォルトです。4.26 より前のバージョンでは、イベント トラックのデフォルトは PostSpawn に設定されていました。既存のトラックについてはデフォルト設定として PostSpawn が維持されますが、新しいトラックではデフォルトで PostEval に設定されます。 

 
本記事をお読みくださりありがとうございました。本記事の情報がユーザーの皆さんにとって興味深く、役立つものであることを願っています。シーケンサーの詳細については、シーケンサーのドキュメント ページを参照してください。