Wwise SDK 2023.1.6
|
원하는 한도에 맞추어 메모리 사용량을 줄이는 것은 꽤나 어려운 일일 것입니다. 다음은 메모리 사용을 줄이는 데 도움이 되는 방법들입니다.
오브젝트 메모리 사용은, 메모리 내에 불러오는 사운드와 이벤트 개수 및 게임 오브젝트의 양에 따라 직접적인 영향을 받습니다. 오브젝트 메모리는 사운드 디자인의 작동을 구현하기 위해 프로젝트 안에 들어있는 오브젝트들의 모든 속성을 포함합니다. 여기에는 또한 모든 게임 오브젝트와 연관된 정보(게임 싱크 값, 위치, 방향, 등)도 포함돼있습니다. 더 많은 뱅크를 불러올수록 더 많은 메모리가 할당돼야 합니다. 이때 필요한 메모리 크기는, 하나의 시나리오, 레벨, 맵, 게임 영역 등과 같은 환경에서 재생될 사운드의 개수에 대해서만 영향을 받습니다. 이러한 할당을 줄이는 데 도움이 되는 방법이 있습니다.
Processing 카테고리의 메모리는 사운드를 재생하는 데 사용됩니다. 여기에는 오디오 음원을 압축 해제하고 효과를 적용하며 믹싱하는 데 필요한 버퍼가 포함돼있습니다. 이 메모리는 동시에 재생하는 사운드의 개수에 영향을 받습니다. 또한 동시에 사용되는 효과의 개수와 유형에도 영향을 받습니다. 이를 줄이려면 자신의 게임에서 한 번에 몇 개의 사운드가 들리도록 할 것인지를 곰곰이 생각해보는 것이 좋습니다. 어떤 게임의 시나리오는 사운드 10 개조차 드물게 들리도록 할 수 있지만, 또 다른 게임에서는 수백 개가 넘어갈 수도 있습니다. 이 때 최악의 상황을 고려해야 합니다.
참고로 일부 게임(Xbox One)을 프로파일링해본 결과 다음과 같은 수치가 나왔습니다.
처리에 사용되는 메모리를 줄이려면 동시 보이스 개수를 줄여야 합니다. 이는 다음과 같은 방법으로 처리할 수 있습니다.
참고: 버스에도 한도를 설정할 수 있습니다. |
참고: 볼륨 한계점을 런타임에 프로그래밍으로 변경할 수 있습니다. 이 방법은 많은 처리를 요하는 게임 장소에서 사용하면 더 많은 보이스를 'under volume threshold (볼륨 한계점 이하)' 상태로 보낼 수 있습니다. |
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. |
프로젝트를 등록하세요. 아무런 조건이나 의무 사항 없이 빠른 시작을 도와드리겠습니다.
Wwise를 시작해 보세요