ゲームのメモリをプロファイリングして最適化する

ゲームのメモリをプロファイリングして最適化する

Appleプラットフォームが、ゲームに必要なメモリの計算や割り当てを行う仕組みをご覧ください。InstrumentsやGame Memoryテンプレートでゲームのプロファイルを作成したり、メモリグラフで現在のメモリ使用状況をモニタリングしたり、Xcode Memory Debuggerやコマンドラインツールで分析したりする方法を紹介します。また、Metal DebuggerのMetalリソースをはじめ、メモリ使用率を最適化するためのヒントやコツについても解説します。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC23
- 空間コンピューティングのためのアプリのパワーと性能の最適化
WWDC22
- Metal 3でバインドレスにする
WWDC21
- メモリ問題の検出と診断
- Metalのデバッグ、プロファイリング、アセット作成ツール
ダウンロード

♪ ♪
「ゲームのメモリをプロファイリングして最適化する」へようこそ AppleのGPU Software Teamの Jack Xu (许) です Seth Lù (陆) も参加してくれますここ数年私達チームは皆さんのようなゲーム開発者とともにゲームメモリを理解し改善するため一緒に取り組んできました今日は私たちが得た学びを共有したいと思います皆さんもゲームメモリをデバッグ最高のプレイヤー体験を提供する素晴らしいゲームを作る際先手を打てるはずです
CPU GPUの両オブジェクトからゲーム内のメモリ使用量を分解さらにゲーム内の割り当て物理メモリの実際の使用状況オブジェクト間の参照などを分析しますメモリには様々な側面があるため開発ツールも様々な角度からメモリの謎を解き明かしますガイドツアーでは Xcode インストゥルメントターミナルでのコマンドラインツールなど使い方を体験いただきます本日はまずゲームメモリを理解するための前段階を説明しますプロファイルメモリとメモリ成長を説明し Sethがインストゥルメントについてお話ししますインストゥルメントについて話した後Xcodeとターミナルのツールを使ってゲームのメモリグラフを分析しますこれらのワークフローはメモリ使用の現状とゲーム全体のメモリの内訳に着目しています最後にSethがMetalデバッガーを使ってMetalリソースを最適化する方法を紹介しますMetalリソースはゲームメモリ中でもやや独立したしかし中核となる領域ですさてゲームメモリを理解するところから始めましょう Modern Rendering with Metalのサンプルコードなど Xcodeからゲームを起動するとデバッグナビゲータでこのメモリーレポートを開くことができますゲームの現在および直近のメモリ使用量システムへの影響度を最初に確認できます
ゲージに表示される数字は現在のゲームメモリ使用量を示しますメモリデバッグの重要な第一歩はこの数値の意味を理解することである
To put it in one line, ひとことで言うとゲームで実際に使うメモリはアロケーションとは異なります実際の使用メモリは物理メモリ上です一方アロケーションはゲームが要求するメモリで仮想メモリアドレス空間上にありますそして異なるアロケーションは当然別々に計算されます
ゲームメモリを割当てた時それらの新しい割当てはすぐまた直接物理メモリ上のスペースを占有するわけではありません逆にシステムが各プロセスに提供する仮想メモリアドレス空間上にある程度の領域を確保することになるそして後で実際にプログラムがこの割当てを使う時にシステムは物理メモリ上にスペースを用意する
同じ種類の割当てはカテゴリーにまとめられ仮想アドレス空間をまばらに占拠するこれらのカテゴリーには: プログラムの実行バイナリです; 全ライブラリとフレームワーク; スタックはローカル変数と一時変数および一部の関数引数を格納するためのものです: 動的メモリ領域はヒープとも呼ばれます; クラスインスタンスのストレージやプログラムが手動で割り当てるメモリも含む; ゲームアセットファイルなど読取り専用リソースからマッピングされた領域; そしてもちろんバッファテクスチャパイプラインの状態オブジェクトなどゲーム内の金属オブジェクトこれらのカテゴリーはリージョンで構成されますメモリ操作はメモリページの単位で行われ最新Apple製デバイスでは 1ページが16キロバイトになるつまり各領域は1ページ以上を占め少なくとも16キロバイトの大きさである
ゲームが進むにつれてメモリはどんどん更新されます新しいオブジェクトが割り当てられ古いオブジェクトが破壊され領域がどんどん変化していきますしかし領域上で使用されるページだけが物理メモリ上にありシステムは他のAppと同様にゲームに電荷を供給します
ゲーム内のメモリページは: ダーティコンプレッションクリーンの3種類に分類されるその内容を見てみましょうダーティメモリページはゲームが書込んだメモリが含まれますこれにはヒープやフレームワークでのメモリ割り当てゲームでの変数やシンボルの変更も含まれます Apple siliconを搭載したデバイスではアクセスされたMetalリソースもこのカテゴリに入りますこれは CPUとGPUが同じ高速ユニファイド- メモリのプールを共有する為です
しかし一部のダーティページが長期間使用されない場合システムはこれらのページを圧縮したりフラッシュやディスクに格納したりして物理メモリ上での存在感を低下させることがありますこれをスワッピングと呼びますこれで端末はより多くのAppやサービスを実行できますその後ゲームがこれらのページを再び要求したときシステムはディスクからそれらいずれかを解凍しますただし非圧縮サイズでもチャージされますクリーンメモリページにはテクスチャやオーディオアセットなどディスクからマッピングされた読み取り専用のファイルやプロセスにロードされたフレームワークが含まれますシステムはいつでもディスクを空にしたり再ロードしたりできゲームのメモリフットプリントにカウントされることはありませんしかしメモリ上に常駐することもあり使いすぎるとシステムやゲーム動作が遅くなります通常最初の2つを見るのが最も興味深いですがこれを合わせてメモリ- フットプリントと呼びますそしてシステムはこれを利用しメモリ制限を実施する
用語の中にメモリのフットプリントを意味する「ダーティメモリ」という言い方がありますがこれはダーティがクリーンの反対語であることに由来しますあいまいになってきたらどちらを指しているのか呼びかけますのでご安心をこれでメモリとゲームへのシステムチャージの仕組みは理解頂けたと思いますこのXcodeのメモリゲージ以外にもMacのアクティビティモニタAppなどシステム上の様々な場所でメモリ- フットプリントを確認することができます Appleの一部のプラットフォームで Appのメモリ制限の為使用されますこの指標を利用してゲームのメモリ使用量も調整できます現在のフットプリントと使用可能メモリを照会する便利なAPIがありますここでざっと見てみましょう iOS iPadOS tvOSのゲームで使用可能なシステムメモリを取得するにはヘッダーファイルos/proc.hにある os_proc_available_memoryを呼び出します
またどのAppleプラットフォームでもメモリフットプリントについては “get pid “からプロセスIDを “rusage_info_current” （現時点ではバージョン6）データストアからproc_pid_rusageを介して取得することが可能ですそして物理的フットプリント又は最大物理的フットプリントのプロパティを取得
このセクションではメモリに関するいくつかの概念を復習しましたゲームでの割り当ては仮想メモリのアドレス空間で行われゲームからアクセスされると 16キロバイトのページとして物理メモリ空間を占有することになりますメモリフットプリントはゲームの実際のメモリ使用量判断のため Appleプラットフォームにおける主要かつ普遍的な指標ですこれにはダーティページ圧縮ページスワップページがありました Apple silicon搭載のCPUとGPUのオブジェクトが含まれていますそしてメモリ制限の実施に使用されますゲームはシステムAPIを呼出しフット- プリントと使用可能なメモリを取得できますさてメモリが舞台裏でどう機能しているか分かった所でゲーム内でどのように見えるかを確認しましょう続きはSethにお願いしますありがとう Jack さっそくゲームのメモリ増設をキャプチャしてみましょう引き続きModern Rendererのサンプルを使用します Xcodeからゲームを実行するとメモリーゲージが時間経過とともにメモリ- フットプリントを表示しますしかしインストゥルメントでゲームをプロファイリングすることでより詳細なメモリ使用状況を把握できますゲーム起動時に大量のメモリが割当てられることがある為既存の実行にアタッチするのではなく新しいゲームの起動からプロファイリングから開始するとよいでしょう Xcodeからゲームのプロファイリングを素早く始めるには実行ボタンを長押し「プロフィール」を選択しますこれで自動的にインストゥルメントが表示されますインストゥルメントAppにはシステムのさまざまな側面を記録するプロファイリングツールが集められており記録されたデータをタイムライン上で視覚化できます今年は新たにメタルゲームにおけるメモリの成長をより把握できる「ゲームメモリ」テンプレートが追加されました
このテンプレートはメモリ割当てを履歴とともに記録するアロケーションおよびメタルリソースイベントメモリフットプリントを記録する VM トラッカー仮想メモリアクティビティを記録する仮想メモリトレースメタル関連イベントを記録するメタルAppおよび GPUの各ツールが付属しています
このデモでは3つのインストゥルメントにハイライトを当てる: アロケーションメタルリソースイベントそしてVMトラッカーですその前にゲーム用のトレースを記録しておこうここで録画ボタンを押すと録画が開始され終了時は同じボタンを押し録画停止するかゲーム自体を終了しますインストゥルメントがモダンレンダラーを記録している間別の方法でトレースを記録する方法を紹介します xctraceコマンドを使用するとプログラムで記録を実行できるため自動化ワークフローに有用な場合があります
さらにデバイス名を指定することで iPhone iPad AppleTVをターゲットとして選択できます
さてインストゥルメントのトレースをキャプチャしたのでまずアロケーションについて見てみましょうアロケーションツールではメモリ割り当てそのサイズオブジェクト参照カウントを詳細に確認できますただしプライベート- メタルリソースは含まれない統計ビューには全ヒープアロケーションと匿名VMが表示されます
All Heap Allocationsにはオブジェクトを含むmalloc’ed bufferが含まれ All Anonymous VMにはダーティな可能性のあるVM領域が含まれますこのカテゴリーにはメタルリソースも含まれる事が分かっています
ではAll Heap Allocationsの内部を見てみましょう通常アロケーションが大きい程最適化に適しています単一の最大割当てを見つけるにはサイズ表の列をクリックしてサイズ別に並べ替えることができます
アロケーションの場合この矢印をクリックするとSwiftと Objective-Cの参照カウントの変化を確認できます
この大きなアロケーションをリストで選択した状態でインスペクタにアロケーションの履歴のスタックトレースが表示されますボタンをクリックするとシステムライブラリやフレームワークを非表示にできますここではスタックトレースによるとモダンレンダラーがアセットをロードする際にアロケーションが発生します
フレームをダブルクリックするとソースコードも表示されます少し戻って「All Anonymous VM」カテゴリの中を見てみましょう
MetalゲームではIOAcceleratorや IOSurfaceのカテゴリに多くのアロケーションを見つけられるかもしれません IOAcceleratorのアロケーションは Metal リソースに対応します
スタックトレースからアセットをロードする時これら問題が発生したことがわかります
IOSurfaceのアロケーションはドローアブルに対応スタックトレースにMetalKitのビューのドローアブル要求が示されています
アロケーションインストルメントはデフォルトでサイズを視覚化しますただし別のルックスも用意されていますアロケーショントラックの矢印ボタンでアロケーション密度を可視化する表示モードをカスタマイズすることができますこれによりグラフが更新され時間経過とともに実行された割当ての量が表示されメモリ割当てのスパイクが明らかになるこのスパイクがメモリ増加の原因の可能性がありますアロケーションに表示されるデータは低レベルのものです割当てられたMetalリソースをより深く理解するため Metalリソースイベントの説明に移りましょう MetalリソースイベントはMetalリソースを中心に設計されたインストゥルメントですリソースイベントビューでは Metalリソースの割当てと割当て解除の履歴を見ることができますここではMetal APIを通じてプログラム的に指定できるラベルによりMetal リソースを識別できますまたアロケーション-インストルメントと同様にインスペクタで履歴のスタックトレースを確認できます
このインストゥルメントではMetal- デバイスの下にアロケーションとディアロケーションのトラックを追加していますイベント密度を可視化するのに役立ちますここまでアロケーションと Metalリソースイベントでメモリ割当ての理解が深まったと思いますしかし常にメモリフットプリントに反映されるわけではありませんそこで次はVMトラッカーで実際のメモリ使用量を調査しましょう
VMトラッカーインストゥルメントには非圧縮のダーティメモリと圧縮またはスワップされたメモリが表示される「ダーティサイズ」は非圧縮のダーティメモリを表します「スワップサイズ」は圧縮又はスワップされたメモリを表しますこの収録ではモダンレンダラーによる圧縮メモリーやスワップメモリーの使用はありません「サマリービュー詳細（Detailed Summary view）」には VMリージョンが表示されますまた「マップドファイル」領域にはゲームアセットなどメモリマップされたリソースが含まれることがありますモダンレンダラーがビストロ- アセットファイルをメモリにマッピングします以上インストゥルメントのアロケーションメタルリソースイベント VMトラッカーについて簡単に説明しましたメモリ増加のプロファイリング方法を簡単におさらいします: まずゲームメモリテンプレートを選択しますそしてそのトレースを記録し解析するメモリの増加パターンを再現・検証する際にこの作業を数回繰り返すこともあります新しいゲームメモリテンプレートがメモリ割当てやフットプリントの増加をより理解するために役立つことを願っていますインストゥルメントの使用方法について他のビデオもご覧くださいここでJackに戻します
ゲームメモリー- テンプレートはクールな機能ですね時間の経過に伴うメモリー使用の変化を理解するのに役立ちそうですさらにある時点でのゲームメモリ状態を把握することでそのメモリ状態を深く掘り下げさまざまな角度から検証できますそのためにメモリグラフなど一連のツールを用意してます
メモリグラフはオブジェクトの作成履歴や参照圧縮やスワップなどゲームのメモリ状態の完全なスナップショットを効率的に保存するためのファイルです
問題が発生した時あるいは比較のため問題発生の前後などいつでも好きな時にスナップショットを撮ることができるスパイスとしてメモリグラフを使ったメモリ解析の方法を料理本に例えて説明しましょう原材料と調理法をお見せします
For the Ingredients, well, you would need your game; something called Malloc Stack Logging; 具体的には:ゲームMalloc Stackという状況ログそしてメモリグラフをキャプチャすることが必要です
Malloc Stackログはゲームプロセスにおける割当て情報を記録するこれはスキーム設定にありますランアクションを選択し診断に進み Malloc Stackログチェックボックスにチェックを入れます
全てのアロケーションと空き履歴は割り当てが解除された後も全てのオブジェクトを記録しますログデータは多くのメモリを消費するかもしれませんが断片化などの問題をデバッグするのに便利です一方「ライブアロケーションのみ」は割当て解除されたオブジェクトを履歴から破棄するためより軽くなる今回はライブオブジェクトの参照だけを調査しているのでこのオプションを選択することができます実際ほとんどの場合「ライブアロケーションのみ」が推奨されるでしょう
またXcodeから起動しない場合は環境変数を設定することも可能です mallocマニュアルページでいくつかの追加記録モードをチェックしてみてくださいその後メモリグラフも用意デバッグエリア内の「デバッグメモリグラフ」ボタンをクリックするだけです Xcodeはメモリスナップ-ショットを取得しそれを処理メモリデバッガに入れる Xcodeメモリデバッガはゲームのメモリ使用状況を直感的に把握できますちょっとだけビューを見てみましょう左側のデバッグ-ナビゲーターではオブジェクトインスタンスの階層的リストが表示されます
右側のファイルインスペクターではメモリフットプリント稼働時間キャプチャーの日付など有用な情報が表示されます
中央のエリアには左から選択したオブジェクトとそのオブジェクトへの参照の接続状況を示すメモリグラフビューが表示されますこのグラフについては後に説明します
また「ファイル」メニューではメモリグラフを将来の分析用に保存したりチームと簡単に共有したりできます
Macのゲームの場合leaksというコマンドラインプログラムでプロセスIDや名前を使いメモリ- グラフをキャプチャする事も可能つまりゲームがフルスクリーンで動作している場合カーソルがゲームにフォーカスされたままになるように安全なシェルでリモートで行うことができますメモリグラフ解析を始める為必要なものですね
Xcodeメモリデバッガとターミナルの多機能コマンド- ラインツールを使ってこのメモリグラフを調べ割当てやフットプリント等を確認しましょうまずメモリ使用状況をカテゴリー別に分類とよいでしょうフットプリントプログラムはまさにそれを実現します
フットプリントはメモリーグラフの情報を使いこのハイレベルなサマリーを再現一般的にまず大きなカテゴリーに注目するとよいでしょうモダンレンダリングのサンプルコードにあるこのゲームのメモリグラフの場合 IOAcceleratorは通常最大のものです Sethが言ったようにMetalリソースも含まれますここではヒープ割当てがいくつかの MALLOC-underscore-prefixedカテゴリに移動システムがヒープ割当てをサイズプールにグループ化し性能を向上させるためですこれらオブジェクトはサードパーティのプラグインやライブラリから来る可能性がありゲームではサウンドエフェクトや物理シミュレーションを行います
William “Cheer” Studioが制作した素晴らしいAppleアーケードゲーム『Manifold Garden』のメモリグラフを紹介しますゲームメモリの使用量表示を許可してくれたのは嬉しいですね Unityを使ったManifold Gardenのようなゲームエンジンやメモリマップの上にカスタム- アロケータを使用した場合そのメモリは次のようにタグなし VM_ALLOCATEとして表示されます AppleのプラットフォームではApp固有のタグを最大16個まで使用できるためメモリ使用量をより明確に把握することができます 1行の変更で済むのでとても簡単です
まず16種類の選択肢からタグを作りますそしてem mapを呼び出す際にマイナス1をこの新しいタグに置換え「ファイル記述子」としますタグやカテゴリの定義については em mapのマニュアルページをご覧ください
mach VM allocateを使用する場合アロケート時にflag引数に同じフラグを含めてください
フットプリントプログラムの世界ではダーティサイズにはスワップやコンプレッションも含まれるので各カテゴリーでチャージされる合計と考えればよいでしょう
以上が現在使用しているメモリの構成とそのフットプリントの簡単なイメージですメモリの一部は使用量が少なくなり圧縮されたりスワップされたりするこれらはメモリの節約につながるかもしれません次にゲームが使用している圧縮メモリやスワップメモリの量を調べ最適化することです
これではvmmapでメモリグラフを実行できます 2つのサイズを合わせたものではなくダーティサイズとスワップサイズになりますこのダーティカラムには現在スワップされていないまたは圧縮されていない通常のダーティメモリが含まれスワップされたカラムには圧縮またはスワップされたメモリの元のサイズが含まれていますシステムはこの2つの列を足してフットプリントを決定しかしスワップサイズの欄の内容はそれほど頻繁に使われるものではないのでゲームメモリを最適化するため何を見るべきか良い指標となりますちなみにこちらがアロケーションサイズで仮想サイズのカラムがありますそしてレジデントサイズには実行ファイルやメモリマップドファイルなどクリーンページが含まれます
便利なことにvmmapはヒープ割当てを別テーブルで表示します vmmapの出力の下部にはヒープメモリをゾーンごとにグループ分けして表示していますこれらはゲームでの使用状況やライフサイクルを反映します Mallocスタックログをオンにしたためヒープ上のアロケーションはツールのゾーンに入っていますまたは2つのデフォルトゾーンになる: 割当てサイズに基づきMallocHelperZoneと DefaultMallocZoneになるまたクォーツコアゾーンのような小さなシステムユーティリティゾーンをスキップできます
数十数百メガバイトといった高い断片化サイズや割合で示される断片化の疑いがある場合 WWDC 2021のセッションで断片化の問題について詳しく説明されています
またダッシュダッシュサマリーなしで vmmapを実行するか vmmapを標準モードで使用するとこれらのカテゴリ内の各vm領域が1行ずつ表示されます先ほど説明した仮想アドレス- 空間と同じようにですそこでvmmapを使えば活発に使用中のメモリから使われていないダーティメモリを抽出できるまた通常ゲーム内では様々なサイズの動的アロケーションつまりmallocされたヒープメモリの使用量もそれなりにあるものです特別な工夫が必要なのですヒープツールはマックロックされたリソースをクラスごとにグループ化しインスタンス数でソートしますこれらのクラスはVTable Objective-C またはSwiftでThinkNC++で決定されます
いくつかのメタデータに関するヘッダをスキップするためダッシュダッシュクワイエット引数を使用しています今年新たにヒープがより賢くオブジェクトの種類を識別するようになりました Mallocスタックログに記録された情報を利用し呼び出し元や担当ライブラリを提示するため巨大な非オブジェクトは過去のものとなるここで再び『Manifold Garden』のメモリグラフを紹介しますこの例ではFMOD Studioなどのプラグインや GameAssembly.dylibなどのゲームコンポーネントがどれだけヒープを消費しているかが初めて明らかにされましたこれでメモリがどう広がるか詳しく分かるようになりましたそしてその情報を得るための方向性を示していますこの例では開発者は FMOD Studioを開いてゲーム内のサウンドトラックやエフェクトを微調整したり Unityでゲームコードの最適化を探したりといった具合に利用できます
クラスのインスタンス数ではなくクラスの総サイズでソートする方が便利な場合もありますモダンレンダリングのサンプル- プロジェクトのメモリグラフでは 2億5800万バイト以上を使用するクラスが上位を占めていますモダンレンダリングサンプルで大きなオブジェクトを探し続けるにはヒープを使用してオブジェクトをクラスの合計サイズ毎にダッシュでソートし各クラスの要約ではなくダッシュでサイズを表示するすべてのオブジェクトをリストアップしますまたバイトストレージには255万バイトの NSConcreteMutableDataのオブジェクトが1つあり: これは一見の価値がありそうです次にその正体を探りましょうまずはアドレスを知りたいですねダッシュダッシュのアドレスを追加しパターン NSConcreteMutableDataの後にワイルドカードのドットスターを入力しブラケットには10メガバイト以上のオブジェクトのみをリストアップするサイズ- フィルタを入れていますそのオブジェクトのアドレスがこちら次のステップでより深く分析するために使用しますこれがインスタンスのオブジェクト識別が改良されたヒープツールですここまでで理解するための 3つのツールを見てきましたがどれも異なる見解を示していますゲーム内でどのオブジェクトがメモリを使っているのか今回お見せしたのはあくまでワークフローの一例ですゲームに使用する記憶パターンや技術によって使い分けが可能です
存在がはっきりしないオブジェクトの発見では次にその原点であるアロケーション-コールスタックを取得することになる
モダンレンダリングの 2億バイトのオブジェクトの場合ダッシュでツリーモードを呼び出し malloc_historyにそのアドレスを渡しています反転の引数を追加することで割り当てに最も近い機能にフォーカスできますそして出来上がりですこちらがアロケーションのバックトレースです同様にXcodeメモリ- デバッガでもオブジェクトの割当て履歴がインスペクタに表示されますオブジェクトを選択しメモリインスペクタをクリックするだけでそこに表示されます他の例としてアドレスの代わりにVM_ALLOCATEをクラスパターンとして渡すとゲームやプラグインで匿名のVM が使われているかどうかをチェックできますカスタムアロケーターをデバッグする場合などです Xcodeでもmalloc_historyでもアロケーションのバックトレースを知ることができその行でブレークポイントを設定するなどより深く掘り下げるか判断することができます
最後にオブジェクトの参照について調べることも有効ですメモリグラフは様々な理由で Mallocスタックログが無効の場合でも常にオブジェクトの参照を記録します以前Xcode外でメモリグラフをキャプチャするためリークを使用しましたリークはさらにやってくれますメモリグラフ内のすべての参照をチェックするためリークやリテインサイクルを知ることができるのですリークはこのオブジェクトへの参照ツリーをトレースツリー引数とヒープからのオブジェクト- アドレスを使って取得しますしかしこの例ではかなり大きなツリーなのでターミナルで表示するよりも多少良い方法があります
Xcode14ではメモリグラフビューのデザインを変更し選択したオブジェクトの入力エッジと出力エッジ両方を表示するようにしました
さらにXcodeに描画させたいエッジを選択するための新しい隣接選択ポップオーバーもありますこれにより複雑なゲーム状態でのオブジェクト参照を理解しようとする際の生産性が大幅に向上します
少し探ってみるとこのオブジェクトにアクセスしているのはテクスチャマネージャであることは間違いないようですゲームではリークツールとメモリグラフビューを使用して重要なオブジェクトの参照関係を見つけこれらのオブジェクトがゲーム内でどのようにアクセスされるか学ぶことを検討くださいそこでリークやXcodeを使用してオブジェクトの重要な参照を表示し見つける方法ですこれらのツールの詳しい使い方はリークのマニュアルページや Xcodeのヘルプをご覧ください
このメモリグラフ解析クックブックでは各ステップでいくつかの特定のツールを使用しますすべてが協力してメモリー- グラフ上の解析を完成させる
要約するとメモリグラフでメモリをキャプチャして分析する場合は Mallocスタックログを有効にすることが第一ですその後ゲーム用Xcodeでメモリグラフをキャプチャするか代わりにMacゲーム用リークツールを使用します次に大きなものやっかいなものを探しますフットプリント vmmap ヒープツールは高レベルと詳細の両方においてメモリの内訳を提供します malloc_history を使うとオブジェクトがどこに割当てられたか把握できリークはオブジェクトの使用状況や参照先を分析できますこれまでのセッションでは詳細なウォークスルーやこれらのツールのより多くの使い方のデモが含まれていますこれまでMetalリソースの探査は先送りにしていましたさて今がその時です Sethが説明してくれます戻ってきましたゲームではMetalリソースが大きなメモリ使用になることがありますがそのメモリ使用量を最適化する方法があります
ここではゲーム内のMetal- リソースを最適化する際に利用できるメモリ節約術をまとめましたリソースの監査にメタルデバッガがどのように役立つかを見ていきさらにメモリを削減するためのテクニックを学んでいきます
メタルデバッガーはゲームをデバッグするためのワンストップショップで GPUフレームキャプチャを撮影するとサマリーページが表示されますこれで取り込まれたワークロードに関する一般的な統計情報を得られます
ページの下半分には4つのカテゴリーに分かれたインサイトのリストがあります「メモリ」カテゴリのインサイトではゲームのメモリ節約を提案します対処した後数メガバイトのメモリを節約できますがこのトレースには特別にメモリに関する利点は多くありません
しかしあなたのゲームに特化したメモリ削減方法がある可能性があります Metalリソースが使用しているメモリの全体像を把握するには「メモリを表示」ボタンをクリックしメモリビューアを使用します
キャプチャしたリソースの一覧を表示できます上半分はフィルタリングの為の様々なカテゴリを示しますテクスチャーなどリソースを調べるのにすぐ使えます下半分はテクスチャーだけを表示したテーブルですとりあえずフィルターを外してみましょうリソーステーブルにはゲームを最適化するためカラムが集められますそして興味深いリソースを素早く見つけるのに役立ついくつかのコラムを紹介したいと思います
インサイトの欄は先ほどサマリーページで見たものと同じですこのカラムでテーブルをソートするとインサイトを持つ全リソースをすばやく表示できますまたインサイトアイコンをクリックするとポップオーバーで所見の説明と可能なアクションが表示されますこの欄の右隣にあるのが「割り当てサイズ（Allocated Size）」ですこの欄でソートすることで最大リソースを確認できます一部のリソースが実際にメモリサイズを有効に活用しているかチェックするのに役立つかもしれません例えばテクスチャの解像度を小さくしたりバッファに読み込まれるモデルのポリ数を少なくしてもゲームのビジュアルクオリティに影響がない場合はそうすることができますテクスチャーメモリを節約する別の方法もありますのですぐに紹介しますもう一つの興味深いカラムは「Time Since Last Bound」ですこの列でリソースを並べ替えると最近未使用のリソースが見つかりますリソースが一度も使用されていない場合そのアセットをロードする価値があるか否か再確認するのも良いかもしれません暫くバインドされていないリソースについては今後2度と使用しない場合はリリースを検討してもよいでしょうまたパージ可能な状態を volatileに設定する事もできます Metalリソースは不揮発性揮発性空の 3つのパージ可能な状態のうちの1つであるデフォルトではリソースは不揮発性であるパージ可能な状態をvolatileに設定することでシステム内のメモリ圧力が高い場合に Metalはメモリからリソースを回避させることができるリソースが空になるとシステムはそのリソースをゲームのフットプリントとしてチャージしなくなります再びリソースが必要になったらコンテンツがまだあるかどうかを確認し必要なら再ロードします使用頻度の低いリソースにのみ volatileを使用することを検討しパージ可能な状態が不利に働かないようにします
以上がすべてのリソースに対する一般的な注意点です次はテクスチャについて詳しく見ていきましょうメモリービューワのデフォルトではすべての列が表示されるわけではないですテーブルのヘッダーを右クリックするとテクスチャのピクセルフォーマットのようなカラムの表示・非表示が可能ですピクセルフォーマットを最適化で節約できる量は異なる場合がありますゲーム内の多くのテクスチャはメモリ使用量と帯域幅を減らすため 16ビット半精度ピクセル形式を使用できますアルファ成分が1つのテクスチャが必要な場合複数のカラーチャンネルを避けることができます最後に一部の読取り専用テクスチャはブロック圧縮を行うことでメモリ使用量を削減できる場合がありますブロック圧縮されたピクセルフォーマットには ASTCやBCなどのオプションがありますさらにA15 Bionic以降テクスチャやレンダーターゲットに非可逆圧縮を使用することで可能な限り品質を維持したままメモリを節約することができます詳しくは過去の動画でご確認ください
これらはメモリビューアーを使用することですぐに発見できるメモリ節約方法の一部ですしかしさらにゲームを最適化するためにいくつかのテクニックがありますテクスチャがシングルパスでしか使用されない場合そのストレージモードをメモリレスに設定することでメモリと帯域幅を節約することができますメモリーレステクスチャは深度ステンシルマルチサンプルテクスチャのような一時的なレンダリングターゲットに対して効果的に働きますそれ以外の場合テクスチャが GPUにのみ使用される場合そのストレージモードをプライベートまたはシェアードマネージドに設定できます注意点としてApple Silicon Macでは iPhoneやiPadと同様にマネージドモードは必要ありません以下はその例ですこのゲームにはDepth32Float_Stencil8 というテクスチャがあります深度テクスチャはパスをまたいで使用されますがステンシルテクスチャの内容は破棄されフレーム内で後に使用されることはありません代わりに2つのテクスチャを使いステンシルテクスチャをメモリレスにすることでメモリと帯域を節約することができます
最後にゲーム内のメモリを有効活用するためのテクニックとしてもうひとつ興味深いものを紹介しましょう同時に使用しない場合はヒープからエイリアスされたリソースを使用することができます同じアロケーションのメモリを共有することができますしかしそれらのリソースへのアクセスを同期させる時は特に注意が必要ですヒープから割り当てられたリソースの使用については「Metal 3でバインドレスにする」というトークで確認できますというわけでメモリ節約のチェックポイントは以上ですこのチェックリストがゲーム内の Metalリソースの診断に役立てば幸いです
ゲームメモリの最適化を目的としたメタルデバッガーの活用については WWDCで行われた他のトークをご覧ください Jackに戻します
ありがとう Seth 今日はガイドツアーに参加してゲームのメモリ使用量を理解し改善するためにできる多くの興味深い事柄を探りましたまずメモリフットプリントはゲームのメモリ使用量を把握するための主要な指標でありダーティメモリに加えて圧縮メモリとスワップメモリも含まれますそして強力なメモリデバッグ- ツールを体験しました Sethはインストゥルメントが有用な遠隔測定トラックでメモリプロファイリングを強化する方法を教えてくれました新しい「ゲームメモリ」テンプレートはまさにこのために作られたものですその後メモリ状態のスナップショットを保存するメモリグラフを紹介しましたオブジェクト参照割り当て履歴のメモリグラフを分析する柔軟で強力なコマンドラインプログラムがありますヒープツールの改善とXcode- メモリデバッガーの再設計によりゲームメモリ解析が超高速化されます最後にSethがMetalリソースのメモリ節約チェックリストとゲームでのMetalリソースの使用に関する質問にメタルデバッガがどのように答えるかについて説明しましたまた他のWWDCのセッションやドキュメントマニュアルページからも学ぶことができます
私達は皆さんのために最適で柔軟なツールを進化させています試さない理由はありませんよね？あなたが探しているものが見つかるかもしれませんよ
またご意見ご感想がありましたらフィードバックアシスタントなどを通じて遠慮なくお寄せくださいメモリの研究を楽しんでくださいご視聴ありがとうございます

#import <os/proc.h>

API_UNAVAILABLE(macos) API_AVAILABLE(ios(13.0), tvos(13.0), watchos(6.0))
size_t os_proc_available_memory(void);

7:07 - Current and peak footprint

#if __has_include(<libproc.h>)
#include <libproc.h> // On macOS.
#else
#include <sys/resource.h> // On iOS, iPadOS and tvOS.
int proc_pid_rusage(int pid, int flavor, rusage_info_t *buffer)  
    __OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_7_0);
#endif

rusage_info_current rusage_payload;
     
int ret = proc_pid_rusage(getpid(),
                          RUSAGE_INFO_CURRENT, // I.e., new RUSAGE_INFO_V6 this year.
                          (rusage_info_t *)&rusage_payload);
NSCAssert(ret == 0, @"Could not get rusage: %i.", errno); // Look up in `man errno`.
        
uint64_t footprint       = rusage_payload.ri_phys_footprint;
uint64_t footprint_peak  = rusage_payload.ri_lifetime_max_phys_footprint;

10:04 - Record an Instruments trace

xctrace record --template "Game Memory" \
               --attach ModernRenderer \
               --output ModernRenderer.trace \
               --time-limit 30s

10:14 - Record an Instruments trace, on a selected device

xctrace record --device-name "Seth's iPhone" \
						   --template "Game Memory" \
               --attach ModernRenderer \
               --output ModernRenderer.trace \
               --time-limit 30s

16:52 - MallocStackLogging

# See `man malloc`.
MallocStackLogging=lite # Live allocations only.
MallocStackLogging=1    # All allocation and free history.

18:07 - Capture a memory graph

leaks $PID     --outputGraph foo.memgraph
# or
leaks GameName --outputGraph foo.memgraph

20:12 - Tag mapped anonymous memory

size_t length;

int tag = VM_MAKE_TAG(VM_MEMORY_APPLICATION_SPECIFIC_1); // Check out `man mmap`.
    
void * reservation = mmap(NULL,
                          length,
                          PROT_READ | PROT_WRITE,
                          MAP_ANONYMOUS | MAP_PRIVATE,
                          tag, // Instead of using default `-1`.
                          0);

if (reservation == MAP_FAILED) {
    @throw [[NSError alloc] initWithDomain:NSPOSIXErrorDomain
                                      code:errno
                                  userInfo:nil];    
}

return reservation;

20:30 - Tag anonymous memory

size_t page_count;

mach_vm_size_t allocation_size = page_count * PAGE_SIZE;
mach_vm_address_t vm_address;
kern_return_t kr;

kr = mach_vm_allocate(mach_task_self(),
                      &vm_address,
                      allocation_size,
                      VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_APPLICATION_SPECIFIC_1));
    
if (kr != KERN_SUCCESS) { // Refer to mach/kern_return.h.
    @throw [[NSError alloc] initWithDomain:NSMachErrorDomain
                                      code:kr
                                  userInfo:nil];
}
    
return vm_address;

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21