拙訳
- 依存関係グラフ
- Task
- 入力を読み出し、データを出力に束縛するC++関数
- 新たにTaskをスケジューリングできる（Task間のデータ依存関係を定義）
- 並列に実行される
- Taskの結果は入力のハッシュ値によってキャッシュされる
- システムが非同期にIOを管理する
- Task
- 出力
- ゲームデータのパッケージファイル
- 以前のパッケージのパッチにもできる
- ゲームデータへ32ビットのIDで直接的に参照できる
- 実行時にそのまま使えるが、相互参照するデータを一緒に処理する必要がある
- コンテンツエラー検査情報
- ゲームデータのパッケージファイル
- 初代Destinyでは
- 古くなったデータを検出して、Taskの実行とキャッシングを繰り返し、パッチとログを出力する
- Task数とデータ数が膨大になっていた
- 追跡する構造が巨大
- 検査や把握が難しい
- 粒度がキャッシュ機構にとって厳しい
- グラフが過剰につながりすぎていた
- グラフ処理のオーバーヘッドが大きい
- ソースの変更が小さくても、たくさんのTaskが実行される
- そこに至った経緯
- Taskと並行してシステムを作っていた
- 伸び率が当初の想定より大きくなってしまった
- 影響度を理解せずに依存関係を追加するのが簡単すぎた
- データの依存関係の粒度に問題が合った
- 最適なゲームデータを生成するのにかなり注力していた
- 対象となるハードウェアが幅広い
- 最適なエンジンコードを記述するのに注力
- 詳細は、HandmadeCon 2016の”Asset Systems and Scalability”を参照
- Destiny 2では
- 生成するコンテンツをさらに多く速く、を第一目標に
- 今がより劇的な変更を加えるその時だと思った
- とはいえ、依然として以下である必要があると考えた：
- ソースコンテンツの後方互換性
- Mininal production wake
- Destiny 2のアセット・パイプライン
- グラフをより小さくアセットごとに分解した
- scope-of-contextな処理はタスク数を減らすほど高速になる
- アセットグラフ処理を並列に実行する
- 小さく単体のアセットグラフは検査や把握がしやすい
- キャッシュ粒度がより適したものになる
- アセット間のデータ依存関係を導入するのをより難しく、ワークフローの影響度をより分かりやすくした
- アセット参照を可能にして、ロード時に調整できるようにした
- 編集しているアセットのみをインポートおよびパッケージングして、残りはビルドファームからダウンロードする
- グラフをより小さくアセットごとに分解した
- イテレーション速度向上のための規則緩和
- 通常の依存関係グラフ処理はすべての入力が出力に反映されることを保証するが、このルールを緩めることでローカルのイテレーションを高速化できる
- “Free” Audio
- “Stale” Ambient Occlusion