【CEDEC2018】「モンスターハンター：ワールド」の最適化事例　現代機のスペックを活かすための取組

「モンスターハンター：ワールド」の最適化事例 現代機のスペックを活かすための取組 株式会社カプコン 技術研究開発部 技術開発室 技術推進チーム 矢萩 太郎

「モンスターハンター：ワールド」 とは？ 2 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

なんやそれ？ • 「モンスターハンター：ワールド」 – 全世界向けハンティングアクション – PlayStation4,XboxOne,Steam – 全世界1000万本出荷！ – 本講演はPS4/XB1について 3 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

本日の講演の内容 • ゲーム中のCPUとメモリに焦点を当てる • I/Oに関して下記セッションでもお話します 「モンスターハンター：ワールド」 におけるファイルI/O最適化 17:50 R311+312 グラフィックについてはCEDEC2017 『MONSTER HUNTER: WORLD』 のレンダリング技術とGPU最適化の紹介 をご参照ください 4 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

自己紹介 5 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

自己紹介 • ２００５年 株式会社カプコン入社 • カプコン内製エンジン「MT FRAMEWORK」に携わる – 主にPlayStation3（SPU最高☺） • MT FRAMEWORKを使い、関わったタイトル – ドラゴンズドグマ、ドラゴンズドグマオンライン – ロストプラネット、ロストプラネット２ – バイオハザード5、バイオハザード６ • 入社以来、ずっとやってる業務は「処理上げ（Optimize）」 – ん？上げ？処理上がったらやばいんちゃうん(‘3’)？ • ゲームコードは？ – 書いていません(´・ω・`) ※：処理上げはカプコンの独自名 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED. 6

アジェンダ • MT FRAMEWORKとは 「モンスターハンター：ワールド」のベースエンジンについて • CPUの最適化事例 レンダリングスレッドの混在化、 ロングタスクオフロード用のバリアジョブ、非同期スレッド スレッド同期の最適化 • メモリの最適化事例 システムメモリ（ヒープ）とVRAMの混在化、フラグメント対策 リソース調整時のメモリ再調整コストの削減 テクスチャ可変解像度システム • I/Oの最適化事例 透過的なアーカイブシステムの構築、スレッドやキャッシュについて 7 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKとは 8 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKとは • カプコン内製のエンジン「MT FRAMEWORK」 • 「モンスターハンター：ワールド」は上記のエンジンがベース • エンジン自体、だいぶ最適化されていた • 旧世代ハード向けにデザインされている 9 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

CPUの最適化事例 10 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム について 11 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム • タスク単位の並列化 – すべてのゲームオブジェクト（プレイヤー、エネミー、エフェクト等） – タスクの更新には並列更新と同期更新が存在する – 同期更新はタスク依存を考慮したシングル更新処理 同期更新 Core0 Core1 並列更新 Core2 IDLE 描画処理 Core3 Time 12 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム • タスクにはラインという概念が存在する – 同ラインにあるタスク同士が並列化可能 同期 同期 Core0 Core1 LINE-1 Player Task LINE-2(並列処理) Enemy Task LINE-3(並) Effect Task Enemy Task Effect Task Core2 Enemy Task Effect Task Core3 Enemy Task Effect Task 同期更新 描画処理 Time 13 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム • 理想的なタスクの状況 – ゲームオブジェクトがCPU数分存在し、同期ポイントにそろって動作 – 一切CPUを無駄にしてない☺ 同期 Core0 LINE-2 Enemy Task LINE-3 Effect Task Core1 Enemy Task Effect Task Core2 Enemy Task Effect Task Core3 Enemy Task Effect Task Time 14 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム • 現実のタスク – 理想的にはいかない – コア数分なかったり、同期にそろっていなかったり – 結構空き時間ができてしまう Core0 Core1 Core2 Core3 LINE-2 Enemy Task LINE-3 Effect Task IDLE Enemy Task Enemy Task Enemy Task 同期 Effect Task IDLE IDLE Effect Task No Task IDLE Time 15 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのタスクシステム • PlayStation3の場合 – コア自体が少ない場合は問題も少ない 同期 Core0 Core1 Enemy Task LINE-2 Enemy Task Enemy Task Enemy Task LINE-3 Effect Task Effect Task Time 16 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

「モンスターハンター：ワールド」の状況 • 実際のゲーム中のCPU使用状況 Time 17 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

隙間を埋めていく最適化 18 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

レンダリングスレッドについて Core0 Core1 Core2 Core3 同期更新 中間コマンド生成 描画処理 並列更新 Time ↑Before Core0 Core1 Core2 Core3 GPUコマンド生成 / After↓ 同期更新 並列更新 中間 コマ ンド 生成 同期更新 中間コ 並列更新 マンド GPUコマンド生成 生成 （レンダリングスレッド） Time 19 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

レンダリングスレッド • レンダリングスレッドの処理時間 27ms • 並列更新処理の空き時間 35ｍs • そうだ！レンダリングスレッドをここに並列に動かそう！ 20 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

スレッドの設定 • レンダリングスレッドをいい感じに混在化させる – レンダリングスレッド5本、メインループを阻害しない様に低優先 – クラスタ0にレンダリング用スレッド3つ、クラスタ1には2つ – クラスタ0に4つにしないのはメインスレッドが高優先の為 • メインスレッドが空くことがないため • レンダリングスレッドはタスクスレッドの間を利用する クラスタ０（CPU0,1,2,3） 優先 Main 低優先 Render Task Task Render Task Render クラスタ1（CPU4,5） Task Task Render Render 21 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

レンダリングスレッドを4本入れた場合 • レンダリングスレッドをクラスタ0に4本セットしたときの最悪なケース レンダリング開始！ Render-3がここ で初めて開始 メインスレッド Core0 Core1 Render-0 Core2 Render-1 Core3 Render-2 ジョブスレッド ジョブスレッド ジョブスレッド Render-0 Render-3 Render-1 Render-2 Time 22 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

良い例 • 非常にいい感じに混在化されたケース – アイドルだった部分にレンダリングスレッドが動いている – CPUを無駄なく使用☺ Core0 Core1 Core2 Core3 同期 LINE-2 Enemy Task LINE-3 Effect Task Rendering Enemy Task Enemy Task Enemy Task Effect Task Rendering Rendering Effect Task Rendering Time 23 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

悪い例(割とよくある) • 一部タスクが長すぎてレンダリングスレッドが終わってしまう – 結局アイドル時間ができてしまう 同期 Core0 Enemy Task Core1 Core2 Core3 LINE-2 Rendering IDLE Enemy Task Enemy Task Enemy Task Rendering LINE-3 Effect Task Effect Task Rendering IDLE Rendering Effect Task IDLE Time 24 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ロングタスクについて • ロングタスクのオフロード AIの経路検索は強烈な負荷。 ↓ しかし、実はそこまで即時性はいらない。 ↓ 次のフレームまでに結果が間に合えばいい。 低プライオリティのスレッドを追加で５本用意し、オフロードしたタスクを 割り当て。 必要になった時点で起動し、 レンダリングスレッド同様にメインループに混在化させて挙動。 メインループの密度を上げ、効率よく動かす。 25 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

先ほどの図 • エネミータスクを・・・・ 同期 Core0 Enemy Task Core1 Core2 Core3 LINE-2 Rendering IDLE Enemy Task Enemy Task Enemy Task Rendering LINE-3 Effect Task Effect Task Rendering IDLE Rendering Effect Task IDLE Time 26 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ロングタスクのオフロード • オフロードする！ – オフロードされたジョブを「バリアジョブ」と命名 – バリアジョブの終了同期はフレームエンド Core0 Enemy Task Core1 Core2 Core3 LINE-2 Rendering 同期 LINE-3 Effect Task Rendering Enemy Task Enemy Task Enemy Task Effect Task Rendering Effect Task Enemy Barrier Job Rendering Rendering Time 27 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

全体的な最適化に話を戻します 28 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

CPUを限界まで使う • レンダリングスレッドとバリアジョブを混在化 – 同期更新（シングルスレッド）の際に終わってしまっていた 同期更新 バリアジョブ 並列更新 レンダリング I D L E 描画処理 Time 29 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

CPUを限界まで使う • さらにUmbra （遮蔽カリング）のスレッドを混在化させる – バリアジョブ – レンダリングスレッド – ミドルウェア：Umbra レンダリング ＆ バリアジョブ 同期 同期更新 バリアジョブ 並列更新 レンダリング 残 タ 描画処理 ス ク Umbra x4 Time 30 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

今までの結果 BEFORE AFTER 31 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

混在化後の処理上げ • 混在化やオフロードで十分速くなった – しかし、快適なゲーム体験の為、さらなる高速化をしたい！ • CPUの空き時間はもう無い – ならば同期そのものの高速化 32 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

イベントとセマフォ、 アトミックによるスピンロック 33 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

その前に・・・ • イベント – 他スレッドに起動通知や終了通知を行えるもの • セマフォ – 複数のスレッドに対して起動通知できるが、どのスレッドかは確定しない • アトミック – 値の更新を行う場合に他のスレッドが介在できない仕組み – 変数への原子操作（Atomic Operation） • スレッドコンテキストダウン – スレッドがノンアクティブになる事 – プリエンプト（割り込み）や、タイムスライス、自発ウェイトによる 34 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの起動方法変更 • イベントでジョブスレッドを起動 – ジョブスレッド分のイベント起動時間がかかる 改修前 ジョブスレッド ジョブスレッド ジョブスレッド ジョブスレッド イベント起動 メインスレッド Time 35 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの起動方法変更 • セマフォでジョブスレッドを起動 – 起動用のコストは1回分。まとめてジョブスレッドが起動する 改修後☺ ジョブスレッド ジョブスレッド ジョブスレッド ジョブスレッド セマフォ メインスレッド Time 36 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの終了方法変更 • イベントでジョブスレッドを待った場合 – それぞれのジョブスレッドを待つため、時間がかかる 改修前 – あまりに小さいタスクだとイベント待ちのほうが高コストに 小さいタスク シグナル送信 メインスレッド イベント待ち Time 37 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの終了方法変更 • イベントでジョブスレッドを待った場合 – コンテキスト復帰に無駄な時間がかかってしまう 改修前 – この処理はゲームには必要ない シグナル送信 ジョブ イベントシグナル処理 ＋コンテキスト復帰 無駄な処理時間 メインスレッド コンテキスト イベント待ち ダウン Time 38 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの終了方法変更 • アトミック更新によりジョブスレッドを待った場合 – 最後のジョブがアトミック更新を行ったら、即動ける 改修後☺ – これが同期の高速化のキモ ジョブ アトミック更新 スピンロックなので イベントシグナル待ちも コンテキスト復帰もない メインスレッド スピンロック待ち Time 39 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ジョブスレッドの終了方法変更 • アトミック待ちの場合は小さいタスクでも問題なし☺ 改修後☺ 小さいタスク ジョブスレッド分の待ち は発生しない メインスレッド Time 40 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

スピンロックのデメリット • ジョブスレッドが長い場合、メインスレッドが無駄に動く – CPUリソースの無駄が発生する ジョブスレッド 何も処理してないけど、 メインスレッドが無駄に CPUを占有し動き続ける メインスレッド スピンロック待ち Time 41 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

イベント待ちで同じような状況が発生した場合 • 他のスレッドが動けるが、復帰処理がくっついてくる – 復帰処理がフレームレートに影響を与えるのでこれはよくない。 – レンダリングスレッド処理はメインスレッドを空けなくても十分な状況 • よって、この時間は許容した ジョブスレッド 他のスレッドが動ける 復帰処理 メインスレッド コンテキストダウン イベント待ち Rendering Time 42 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

実際のイベント待ちの時間 • Event待ち – 約 10 マイクロ秒 – 1マイクロ = 100万分の1秒 ジョブが終わった瞬間 Event同期 次のジョブ開始時間 イベント待ちから復帰する時間 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

実際のアトミック更新待ちの時間 • アトミック更新待ち。画像の縮尺は違います – 約 ２ マイクロ秒 – 1マイクロ = 100万分の1秒 アトミック同期 ジョブが終わった瞬間 次のジョブ開始時間 8micro secの高速化。 こいつが100回ぐらいある。 ＝1ms高速化！ 44 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

CPUまとめ メインループに混在化し、邪魔をしないレンダリングスレッド。 AIなどの長い処理はオフロードし、空いているCPU時間をしっかり使う。 CPUコアや同期が多い場合は、セマフォ＋アトミック更新待ちへ。 ↓ CPU使用効率：85～95％(↑) 45 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

メモリの最適化事例 46 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKにおける メモリの問題について 47 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORKのメモリ MT FRAMEWORKではアプリケーション起動時に、それぞれ用途別にメモリ を確保し、そこに独自アロケータを割り当て、使用しています。 これは並列で確保・解放する速度を保証する為に行っていました。 48 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

用途別アロケーションの問題点 用途別アロケータのイメージ SYSTEM, 300 拠点ではVRAMは2000必要 人が一杯いるからTaskは500 TASK, 700 総量的にはできるが、 固定配分では不可能 デモシーンはVRAMを2500欲しい Taskは200でいい VRAM, 3000 VRAM TASK SYSTEM ＊VRAM:ビデオメモリ ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED. 49

用途別アロケーションの問題点 理想 拠点ではVRAMは2000必要 人が一杯いるからTaskは500 OK☺ デモシーンはVRAMを2500欲しい Taskは200でいい メモリ, 4000 50 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

用途別アロケーションの問題点 • 横軸はメモリの使用量 • 用途別に分けた場合はこのように境界線が見える VRAM領域 シーンA シーンB シーンC SYSTEM領域 System VRAM VRAM VRAM System System Memory 4GB 51 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

真・アーティスト征魂戦 • アーティストからテクスチャのクオリティを上げたい要求が来る – システム側は空いてるのに要求を実現できない VRAM領域 シーンA シーンB シーンC SYSTEM領域 System VRAM アーティストの真の要求 VRAM 無理 System System Memory 4GB 52 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

QUEST COMPLETE • 境界線がなければアーティストの要求にこたえられる☺ ボーダレスメモリ領域 シーンA シーンB シーンC System VRAM アーティストの真の要求 VRAM OK System System Memory 4GB 53 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ボーダレス化にあたって • 単にメモリを確保するたびにOSからメモリを取れば終了！ – OSからメモリを確保するのはシングルスレッド処理 – MT FRAMEWORKにあった、メモリ並列確保と解放が出来なくなる – これはやばい • OSへのメモリ要求はめちゃくちゃ遅い！ – 仮想空間の検索・確保、物理メモリ検索・確保、メモリマッピング – 仮想空間と物理メモリがフラグメントしてるとさらに高コスト – これはやばい 54 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

解決にあたって 実際のメモリレイヤーと挙動 55 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

メモリキャッシュレイヤー モンスターハンター：ワールド 各自スレッド分の メモリプールを持つ 並列確保・解放を保証 用途別のアロケータ群 VRAM System 各種アロケータ ・・・ AI プールが枯渇したので要求（シングルスレッド） グローバルプール＆アドレスマッパー 同一要求であれば キャッシュ 要求メモリを64KiB単位に拡張：フラグメント対策 物理メモリ(４GB) 56 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

実際の物理メモリ取得の挙動 57 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • メモリの初期状態 – 緑は確保済みのメモリ 仮想メモリ空間 128KiB 128KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 58 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 192KiBのメモリ確保が来た 仮想メモリ空間 128KiB 192KiB 要求 128KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 59 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 192KiBのメモリ確保成功 仮想メモリ空間 128KiB 192KiB 128KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 60 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 128KiBのメモリ返却 仮想メモリ空間 128KiB 返却 128KiB 192KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 61 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 再度192KiBのメモリ確保が来た 仮想メモリ空間 192KiB 192KiB 要求 128KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 62 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 192KiBのメモリ確保成功 仮想メモリ空間 192KiB 192KiB 要求 128KiB 物理メモリ 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 63 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

64KiBアッパーパディングメモリマッピング • 物理メモリはフラグメントしない！ 仮想メモリ空間 192KiB 128KiB 192KiB フラグメントに強い 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 64KiB 物理メモリ 64KiB 64KiB 64 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

メモリの可変化 • ボーダレス化したことで、自由にメモリが行き来できるようになった – しかし全体容量の調整方法が確立されていない 65 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

最大値を超えた場合の再調整コスト • シーン別のメモリ配分 – シーンBは今のところ収まっている ボーダレスメモリ領域 シーンA System VRAM シーンB シーンC VRAM VRAM System System Memory 4GB 66 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

極・アーティスト征魂戦 • アーティストからさらなる要求が飛んでくる – ついでにシステムメモリも増え続ける • こうなると都度リソースを調整していかないとならない（高コスト） ボーダレスメモリ領域 シーンA シーンB シーンC 無理 System VRAM アーティストの極の要求 VRAM System System Memory 4GB メモリの大半はテクスチャ 67 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ここから テクスチャ可変解像度システム の話です 68 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャ可変解像度システム • テクスチャの解像度をリアルタイムで変更し、メモリを自動で調整する – シーン別の調整コストをなくす – メモリオーバーによるクラッシュをなくす メモリ足りてる？ Freq:500ms オーダースレッド 監視 Texture Variable Resolution System 69 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャ可変解像度システム Worker x 8 Freq:50ms 監視＆取得 テクスチャ セット ワーカースレッド 足りない！ オーダースレッド 監視 Texture Variable Resolution System 70 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャのクオリティを決定するMETAデータ • テクスチャのデフォルトの指定解像度が入っている – メモリが足りない場合は優先度の低いテクスチャから下がる デフォルトで表示する解像度を設 定するMETAデータが存在する メモリ上の テクスチャデータ ＋ METAデータ METAの書き換えだけでクオリテ ィーコントロール可能 71 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

クエストのデータの非同期ロード • クエスト受注時にデータをゲームのバックグラウンドで読み込んでいる • 読み込んでいる最中は自由に動けるので便利☺ – しかし、その分読み込むための余剰メモリが必要 – さらに、クエストごとに必要なメモリも異なる 72 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

実際のゲームでの挙動例 • クエスト受注前の拠点でのVRAM使用量 – VRAMの最大値としては3000MBを設定している – すでに2929MBのVRAMを使用している Tex:2929MB < 3000MB 73 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

実際のゲームでの挙動例 • クエスト受注後の拠点でのVRAM使用量 – 受注後で2999MBのVRAMを使用している。3000MBは超えない – 約3000枚のテクスチャをリダクションしてメモリを空けている Tex:2999MB < 3000MB 74 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャ可変解像度システム を利用したカットシーンの画質向上 75 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャにMETAデータを組み込む メモリ上の テクスチャデータ ＋ METAデータ ＋ EVENT LEVEL METAデータに 「特定シーンのみ高解像度で読み込まれる」 為のフラグとしてイベントレベルを用意 76 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャ可変解像度システム（カットシーン時） カットシーンだ！！ オーダースレッド 通知 監視 Texture Variable Resolution System 77 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

テクスチャ可変解像度システム（カットシーン時） 通知フロー（前述の為、省略） 高解像度化 EventLevelが設定されていれば 設定されてなければ低解像度(´・ω・`) オーダースレッド 通知 監視 Texture Variable Resolution System 78 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

カットシーン高解像度化の例 ノーマルクオリティ ハイクオリティ 79 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

カットシーン高解像度化の例 ノーマルクオリティ ハイクオリティ 80 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

QUEST COMPLETE(まとめ) 従来の用途別のメモリ取得をやめて、再配分調整コストをなくした 物理メモリをページ単位のみでマッピングすることで、フラグメントに強く テクスチャを自動でリダクションして、シーン別の調整コストを削減 ↓ Memory使用効率：９５％ 81 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oの最適化事例 82 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

MT FRAMEWORK 開発時のアーカイブについて 83 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oの問題点について • MT FRAMEWORKではアーカイブ機能がすでに実装されてる – ファイル群を単一のアーカイブにZlibで圧縮する – 必要なファイル群のアーカイブになるのでわかりやすいし、読み込みも高速！ ファイル群 圧縮 アーカイブ ファイル群 圧縮 アーカイブ ファイル群 圧縮 アーカイブ 84 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oの問題点について • アセット内部のファイルに変更があった場合 – 必要なアーカイブだけが再圧縮 – まぁ、問題にならない ファイル 更新 ファイル群 再圧縮 アーカイブ ファイル群 アーカイブ ファイル群 アーカイブ 85 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oの問題点について • それぞれのアーカイブに共通のファイルがあった場合、全変換！ – 現代機でファイルがでかくなりすぎてこの時間がシャレにならない！ 更新 ファイル ファイル群 再圧縮 アーカイブ 再圧縮 アーカイブ 再圧縮 アーカイブ 更新 ファイル群 更新 ファイル群 86 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oの問題点の解決 • 再圧縮によるアーカイブの時間を短縮するには – ファイルのアーカイビングは開発後期のみに – I/Oのインターフェース（API）は共通に • 開発時とアーカイブ時を共通化することでチェックコストを抑える 87 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

「モンスターハンター：ワールド」 I/Oレイヤーと挙動について 88 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oレイヤー概要図 「モンスターハンター：ワールド」 エンジンのI/Oレイヤー QA デイリーROM 開発時 ファイル 連結 TOC 連結データ 圧縮 QA 製品版 圧縮データ ※TOC：ファイルの目次データ ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED. 89

TOC+連結データ 「モンスターハンター：ワールド」 エンジンのI/Oレイヤー ファイル読み込み ファイル 連結 FindFile（検索）置き換え Exist（存在チェック）置き換え ファイル読み込み（Read）置き換え 個々のファイル を独立して扱っ 10秒程度で作成 てるように錯覚 TOC させる 連結データ 90 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

圧縮ファイル 「モンスターハンター：ワールド」 エンジンのI/Oレイヤー 展開レイヤー TOC 多重 連結データ エミュレーション 圧縮データ ファイル エミュレーション ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED. 91

圧縮について • データは256KiB毎に分割（TOCごと） 、後に圧縮 256KiB TOC Oodle使用 256KiB 分割 連結データ 256KiB 256KiB 256KiB 256KiB 圧縮 圧縮データ 92 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

「モンスターハンター：ワールド」 I/Oレイヤーの高速化ポイント 93 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ファイルの展開の高速化 • ローダースレッドのオフロード – リード、展開、リード、展開、・・・・・繰り返し 読み込みたいファイル 展開データ 256KiB リード 展開 圧縮データ 圧縮ブロ ック リード 展開 圧縮ブロ ック 展開データ 256KiB 展開データ 256KiB 展開データ 256KiB 圧縮ブロッ ク リード 展開 リード 展開 圧縮ブロッ ク 94 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ファイルの展開の高速化 • ローダースレッドのオフロード ローダースレッド ロード 展開 ロード 展開 ロード 展開 I/Oキューが遅れる セマフォ＆アトミック スピンロック ローダースレッド ロード ロード 展開スレッド 展開 ロード スピン ロック 展開 展開 Time 95 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ファイルの展開の高速化 • 読み込みたいファイルと次に読み込みたいファイルが連続している場合 – 同じデータを2回も展開するのはもったいない 読み込みたいファイル 展開データ 256KiB 圧縮データ 圧縮ブロ ック 次に読み込みたいファイル 展開データ 256KiB 圧縮ブロ ック 展開データ 256KiB 圧縮ブロッ ク 展開データ 256KiB 圧縮ブロッ ク 96 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ファイルの展開の高速化 • 256KiB単位24エントリーのキャッシュ（LRU） – 部分的に展開された場合、再度必要になる可能性があるのでキャッシュする – 実際のゲームではキャッシュヒット率40％ 読み込みたいファイル キャッシュ 圧縮データ 展開データ No Cache 圧縮ブロ ック 次に読み込みたいファイル 展開データ Cache 圧縮ブロ ック 展開データ No Cache 圧縮ブロッ ク 展開データ Cache 圧縮ブロッ ク 97 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

I/Oまとめ • 透過的なI/Oレイヤーを用意することで開発イテレーションの向上 • ロード関数のロード要求と展開を別スレッド化することによる高速化 • 無駄なロードを省く、ブロックごとの24エントリーキャッシュ（LRU） 98 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.

ご清聴ありがとうございました • おわりです。 99 ©CAPCOM CO., LTD. 2018 ALL RIGHTS RESERVED.