バージョン
Wwise SDK 2023.1.2
|
メモリの使用量を定められた制限内に抑えるのは、難しいことがあります。以下は、メモリ使用量を抑えるのに役立つ、幾つかのヒントです:
Objectメモリの使用量は、メモリにロードしたサウンド数やイベント数、そしてゲームオブジェクトの量によって直接、左右されます。これはプロジェクトがサウンドデザインの実装に必要とするオブジェクトすべてのプロパティを含んでいます。また、すべてのゲームオブジェクトとそれらの関連する情報 (ゲームシンク値、位置、向きなど)も含みます。より多くのバンクをロードすると、より多くのメモリアロケーションが必要となります。必要なサイズは、一つのシナリオ、レベル、マップ、ゲームエリアなどで一度に再生する可能性のあるサウンド数に依存します。このアロケーションを減らすには、以下のような心がけが役立ちます:
Processingカテゴリのメモリは、サウンドの再生に使います。これには解凍のためのバッファを含み、エフェクトを適用し、オーディオソースをミックスします。一度に再生するサウンドの数に直接影響されます。また、同時に使うエフェクトの合計数や種類にも影響を受けます。削減するには、同時にいくつのサウンドを聞かせたいのかを決める必要があります。ゲームによって、サウンドが10個以上聞こえるシナリオがほとんどないものもあれば、100個のゲームもあります。最悪のケースを考える必要があります。
ガイドラインとして、一部のゲーム (Xbox One) でプロファイリングを行い、次の数値を得ました:
処理に使用するメモリ量を減らすには、同時ボイス数を減らしてください。それには次を利用します:
注釈: また、バスの数も制限できます。 |
注釈: プログラム的にボリュームのしきい値をランタイムで変更できます。「ボリュームしきい値以下」の状態により多くのボイスを送るために、より処理が重くなるゲームの箇所でこれを利用できます。 |
サウンドバンク(SoundBank)のメモリ消費は主に、中にあるサウンドデータに起因します。サウンドデータ(メディア)のメモリ消費は、以下のテクニックで抑制できます。
Wwise uses an internal pool of memory to manage some temporary allocations that persist for less than one audio-render tick, which are represented in the Advanced Profiler's Memory tab as "Temp Alloc". These temporary allocations exist for a specific amount of time, have very little overhead, are handled internally by the sound engine, and cannot be forwarded to developer-provided memory allocation hooks. Instead, the only allocations in this regard that are observed by the Advanced Profiler and memory allocation hooks are the larger memory blocks that the temporary allocations are made from. Therefore, it might be desirable to manually tune the management of "Temp Alloc" memory blocks, in order to better optimize memory usage in your game.
During AK::MemoryMgr::Init
, AkMemSettings::tempAllocSettings
controls the behavior of the memory blocks for each Temp Alloc category. Notably, this includes configuring the size of the memory blocks, the minimum number of blocks that the system keeps allocated at all times, and how many blocks have to be unused for a tick before the system starts freeing memory. You can use AK::GetTempAllocStats()
to see how much memory the Temp Alloc system uses in your game at runtime, and better fine tune configuration of the system.
The following are some suggestions depending on your game's requirements, or other behavior observed during profiling:
AK::TempAllocInitSettings::uMinimumBlockSize
to a lower value than the default, so that it better matches the memory usage of your game's needs at any given time.AK::TempAllocStats::uPeakMemUsed
to view the Temp Alloc system's peak memory usage, and then ensure that the AK::TempAllocInitSettings::uMinimumBlockCount
is set to a high enough value so that all of the blocks you might use are allocated when the sound engine is initialized, and never freed afterward.AK::TempAllocInitSettings::uMaximumUnusedBlocks
to a high value to ensure that the system can allocate new blocks, but not free them, even during periods of low memory load.AK::TempAllocInitSettings::uMinimumBlockSize
so that using more workers does not cause a significant increase in used memory in your game.AK::TempAllocInitSettings::uMinimumBlockSize
to a slightly reduced value than intended in order to mitigate waste in this regard.Some debugging options are available in AK::TempAllocInitSettings
. In the Debug and Profile configuration of the sound engine, AK::TempAllocInitSettings::bDebugDetailedStats
and AK::TempAllocInitSettings::bDebugEnableSentinels
are enabled by default in order to improve tracking of usage statistics, and to provide some easy detection of buffer overruns. Disable these options when the highest performance, or most accurate profiling data, is required for your application. Support for these options is removed entirely in the Release configuration of the sound engine.
If your Memory Manager integration relies on Wwise's integration of rpmalloc, it might be desirable to adjust AK::MemSettings::uVMSpanCount
and AK::MemSettings::uDeviceSpanCount
in order to reduce the amount of memory reserved by the system. There are three options available for these settings, which provide different trade-offs for CPU and Memory use: AkSpanCount_Small
, AkSpanCount_Medium
, and AkSpanCount_Huge
.
AkSpanCount_Huge
is the default value, which offers the best CPU performance by reducing the number of calls made to AkMemSettings::pfAllocVM
, but also because in supported integrations, and on some platforms, memory mappings can be made using 2MiB pages, instead of 4KiB or 16KiB pages. Utilization of 2MiB pages can reduce the number of translation lookaside buffer (TLB) misses during sound engine execution, and help improve overall CPU performance.
AkSpanCount_Small
adjusts the amount of memory requested at any given time to be as low as 64KiB. This can reduce the amount of memory reserved by Wwise, but can increase the amount of CPU usage due to an increase in calls to AkMemSettings::pfAllocVM
. Depending on your implementation of the AkMemSettings::pfAllocVM
callback, this might also prevent the usage of 2MiB pages for memory mappings.
AkSpanCount_Medium
balances memory and CPU usage, by requesting memory blocks as low as 512KiB. This can reduce the number of calls to AkMemSettings::pfAllocVM
compared to AkSpanCount_Small
, but still might prevent the usage of 2MiB pages for memory mappings.
注釈: If your implementation of AkMemSettings::pfAllocVM provides blocks of pre-mapped memory, and rarely invokes a system call for a new memory mapping, we strongly recommend that you use a setting of AkSpanCount_Small because the relative cost of calls to AkMemSettings::pfAllocVM should be greatly reduced, and your pre-mapped memory might already be using 2MiB pages. |