OGRE-Next
2.3
Object-Oriented Graphics Rendering Engine
|
Ogre has the following samples to show how to cleanup memory:
Memory is not released immediately. Of special relevance functions for cleanup are:
SceneManager::shrinkToFitMemoryPools
VaoManager::cleanupEmptyPools
Notice that these can take a large time as they defragment memory thus they should not be called aggressively
For tracking resource consumption there is:
VaoManager::getMemoryStats
(see Samples/2.0/Tutorials/Tutorial_Memory)TextureGpuManager::dumpStats
TextureGpuManager::dumpMemoryUsage
You can iterate through all textures (TextureGpuManager::getEntries
) and call:
TextureGpu::getSettingsDesc
to get a string describing the textureTextureGpu::getSizeBytes
TextureGpu::getSourceType
to understand where it comes from (regular textures vs compositor vs shadow mapping, etc)BT_DEFAULT_DYNAMIC
is optimized for data that is modified every frame from scratch. It's rare to have to have a lot of this type of data except for particle FXs.
By default we triple the buffer size because Ogre manually synchronizes data to prevent arbitrary stalls. Ogre 1.x let the driver handle synchronization.
If your code was structured to map the buffer, even though you should be using BT_DEFAULT
then we recommend you simply use a malloc'ed memory ptr:
When initializing Ogre through the first Root::createRenderWindow
, you can provide settings via NameValuePairList params
.
It accepts the following
Note the default settings are different for Mobile (Android + iOS) builds
The pool VaoManager::TEXTURES_OPTIMAL
is used on many GPUs but not all of them.
As it depends on VkPhysicalDeviceLimits::bufferImageGranularity
property. When this value is 1, then VaoManager::TEXTURES_OPTIMAL
pool is not used because all texture memory will go to the VaoManager::CPU_INACCESSIBLE
pool. Mostly AMD, and some Intel and Qualcomm GPUs are able to use this.
When the property is not 1, then all textures are placed into VaoManager::TEXTURES_OPTIMAL
while buffers go into VaoManager::CPU_INACCESSIBLE
.