バージョン

menu_open
警告:このページでは、一部の保護された情報が表示されません。
あなたが特定プラットフォームのライセンスを所有しているユーザであれば、最初にログインしてください。
Wwise SDK 2023.1.3
メモリマネージャ

Wwiseサウンドエンジンのすべてのモジュールは、AK::MemoryMgr インターフェイスを介してメモリにアクセスします。サウンドエンジンクライアントによって、このインターフェイスの初期化および終了が行われます。

デフォルト実装は、静的ライブラリ(AkMemoryMgr.lib)としてSDKで提供されています。このライブラリを使うには、クライアントは、 AkModule.h ヘッダを含めて、 AK::MemoryMgr::Init の初期化関数をコールする必要があります。

AkMemoryMgr.libとその他ライブラリの使用に関する詳細は ビルド構成 を参照してください。

初期化

デフォルト実装では、デフォルトの初期化設定を AK::MemoryMgr::GetDefaultSettings を使い取得できます。

Memory Managerによって割り当てられるバーチャルメモリやデバイスメモリの合計を制限するには、以下の設定を使います:

追加のランタイムデバグ機能を有効にするには、以下の設定を使います:

これは、カスタム実装で、好きなだけのメモリデバグ機能を定義できるようにする不透明な値です。デフォルトの実装で、2つのレベルが提供されます。

  • Level 1は基本的なランタイムメモリデバグを有効にし、これに含まれるのは、アロケーションごとの FILELINE のキャプチャ、アロケーションごとのcallstackのトラッキング(可能な場合)、シャットダウン時の詳細なリーク報告、そして非常に軽いインテグリティチェックなどです。開発中にデフォルトで実行できるほど、軽いものです。
  • Level 2はstompアロケータの使用を有効にして各アロケーションでバーチャルメモリの個別のページを使い、out of boundsで発生する書き込みをトラップしようとします。これは、非常に遅くてリソース負荷の高いモードなので、開発中にデフォルトで有効にするのは避け、メモリストンプの原因を探し出そうとするときに限り使うことを、推奨します。

全てのアロケーションをファイルにダンプするには、以下を使います(必ず、 AkMemSettings::uMemoryDebugLevel を1として、Releaseコンフィギュレーションでないものを使ってください):

備考: サウンドエンジンが、 AK::IAkStreamMgr::CreateStd() を使って書き込み用のストリームを開きます。Stream Managerのデフォルト実装を使用している場合は、ファイルを開く処理は、Low-Level IOインターフェースの AK::StreamMgr::IAkLowLevelIOHook::BatchOpen() を実装した時に実行されます。

デバグ用のアロケーションをトラッキングするには、以下の設定を使います(Releaseコンフィギュレーションでは、これらはコールされません):

上記のデバグ関数は、下記の実際のアロケーション関数を置き換えるものではなく、様々なメモリアロケーションイベントの、通知コールバックです。

以下を使えば、rpmallocを使ったデフォルト実装をオーバーライドし、カスタムアロケータを設定できます。

上記のアロケーション関数が、AkMemType_Deviceビットを尊重し、ビットが設定されたらデバイスメモリを返すことが重要です。デバイスのメモリアロケーションは、一部のプラットフォームでしか使われていなく、具体的なパラメータに準拠する必要があるので、詳しくはプラットフォーム別のセクションを参照してください。

PS5では、デバイスメモリページを追加フラグで保護して返すことが重要です。PS5で正しくデバイスメモリアロケーション関数を実装する方法については、 メモリマッピング要件 を参照してください。

Xbox Oneでは、APU関数でアロケーションしたメモリページを返すことが重要です。Xbox Oneで正しくデバイスメモリアロケーション関数を実装する方法については、 APU メモリ を参照してください。

Xbox Series Xでは、APU関数でアロケーションしたメモリページを返すことが重要です。Xbox Series Xで正しくデバイスメモリアロケーション関数を実装する方法については、 APU メモリ を参照してください。

以下の設定を使うと、rpmallocの根拠となるページアロケーションメカニズムをオーバーライドまたは管理できます:

rpmallocをオーバーライドするために、カスタムアロケータを設定した場合は、上記関数はコールされません。デバイスのメモリアロケーションは、一部のプラットフォームでしか使われていなく、具体的なパラメータに準拠する必要があるので、詳しくはプラットフォーム別のセクションを参照してください。返されるメモリのアライメントが、プラットフォームの本来のアライメント(例えば、Windowsであれば64KB)に合致しない場合は、そのカスタムアライメントを、uVMPageSizeやuDevicePageSizeで指定する必要があります。

AK::MemoryMgr::InitForThread() をコールしたスレッドでは、uMaxThreadLocalHeapAllocSizeより小さいすべてのアロケーションがスレッドローカルヒープに移動されます。この値より大きいすべてのアロケーションは全スレッドが共有するグローバルヒープに移動されます。uMaxThreadLocalHeapAllocSizeのデフォルト値は0のため、デフォルトではすべてのアロケーションがグローバルヒープに移動されます。負荷の高いマルチスレッドのCPUアクティビティが発生している間は、グローバルヒープへのアクセスで非常に多くの競合が生じる可能性があります。そのような場合、uMaxThreadLocalHeapAllocSizeを例えば384、512、あるいは更に高い値に設定し、メモリ消費の増加と引き換えにCPU競合を低減することをご検討ください。

ゲームのメモリマネージャ初期化に関するサンプルコードと詳細は サンプル をご覧ください。

サウンドバンクのメモリ使用に関する詳細は、 バンクのロード を参照してください。

メモリアロケーションの最適化に関する詳細は、 メモリアロケーションの最適化 を参照してください。

メモリマネージャのオーバーライド

クライアントは、 AK::MemoryMgr のインターフェースのカスタム化された実装を提供することができます。 AkMemoryMgr.h で定義されている関数は、すべて実装してください。 AkModule.h で定義された AK::MemoryMgr ネームスペースの関数は、メモリマネージャのデフォルト実装のためのものなので、実装する必要はありません。

AkMemSettings の様々なアロケーション関数をオーバーライドするときと同様に、新しい AK::MemoryMgr の実装をプログラミングするときは、ビットが設定されたらデバイスメモリを返すことで、 AkMemType_Device ビットを尊重することが、重要です。デバイスのメモリアロケーションは、一部のプラットフォームでしか使われていなく、具体的なパラメータに準拠する必要があるので、詳しくはプラットフォーム別のセクションを参照してください。


このページはお役に立ちましたか?

サポートは必要ですか?

ご質問や問題、ご不明点はございますか?お気軽にお問い合わせください。

サポートページをご確認ください

あなたのプロジェクトについて教えてください。ご不明な点はありませんか。

プロジェクトを登録していただくことで、ご利用開始のサポートをいたします。

Wwiseからはじめよう