[2.1] InternalErrorException in Release mode with large resource group

[DOS]

Hello,

I am getting the following error in Release mode (does not happen in Debug mode):



It seems to be connected to initializing a large Resource group with a lot of different textures, materials and meshes. What exactly does "active" mean in this context? It's not like all the different objects are actually being drawn, and why does it work in debug mode?

Additional question: We noticed that all textures are being loaded when the resource group is initialized as opposed to only being loaded once the mesh is actually drawn (as it used to be done in Ogre 1.x). The problem is that the initialization of the whole resource group takes very long because of that. Do you have any recommendations on how to speed the process up? E.g. would it be possible to split resources up into different groups and load them concurrently or something?

[dark_sylinc]

Hi!

What exactly does "active" mean in this context?

It means someone called HlmsManager::getMacroblock (or HlmsManager::getBlendblock, or getSamplerblock) without yet calling destroyMacroblock/Blendblock/Samplerblock (I wouldn't rule out there is a leak in Ogre).

It doesn't have to be in use during the frame.

They're reference counted so if you call getBlendblock twice with the same parameters, you have to call destroyBlendblock twice on that blendblock.

Ogre has a hardcoded limit that can be raised at compile time in OgreHlmsManager.h (Ogre needs to be rebuilt):

Code: Select all

#define OGRE_HLMS_NUM_MACROBLOCKS 32
#define OGRE_HLMS_NUM_BLENDBLOCKS 32
#define OGRE_HLMS_NUM_SAMPLERBLOCKS 64

and why does it work in debug mode?

This is suspiciously the cause of it. Often asserts in getMacroblock/destroyMacroblock and co. means that different DLLs have been mixed.

You can't mix Debug with Release, and you can't mix plugins and Ogre main that were compiled for different versions (e.g. 2.1.1 vs 2.1.2). I strongly suspect there is a mismatch somewhere. Usually it's mixing Debug with Release.

If it's truly that you're running out of blocks, you could try rising the limit. However I suspect the problem is caused by mismatched DLLs and that's just going to keep crashing (because the blocks are being kept filled with garbage parameters so Ogre thinks they're all different blocks instead of all of them being the same and thus share the same reference)

Additional question: We noticed that all textures are being loaded when the resource group is initialized as opposed to only being loaded once the mesh is actually drawn (as it used to be done in Ogre 1.x). The problem is that the initialization of the whole resource group takes very long because of that. Do you have any recommendations on how to speed the process up? E.g. would it be possible to split resources up into different groups and load them concurrently or something?

Move to Ogre 2.2. Textures were refactored to fix exactly this problem and you'll see massive VRAM savings.

The Ogre 2.1 manual has a section on dumping texture information to debug your memory usage and optimize it.

Ogre 2.2 has a similar workflow using TextureGpuManager::dumpStats (+ extra new info such as TextureGpuManager::getMemoryStats). Ogre 2.2 also has TextureGpu::getSourceType to know what each texture belongs to (see TextureSourceType)

Cheers