Irrlicht texture memory leak in Direct3D 9 driver

[Joe_R]

I'm using a recent trunk version of Irrlicht, with the Direct3D 9 driver. I have the value of _IRR_MATERIAL_MAX_TEXTURES_ set to 5. If I assign a texture to the 5th channel the rendering works properly. However in my application the visualisation part can be loaded and unloaded muliple times. If I use the 5th texture channel in any of my materials somehow the texture assigned to that channel doesn't get freed when closing the device, causing a memory leak. I've produced a minimum code which seams to reproduce the behaviour:

Code: Select all

 
#include <irrlicht.h>
#include <iostream>
 
using namespace irr;
 
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif
 
int main()
{
    for (int i = 0; i < 5; i++)
    {
        IrrlichtDevice* device =
            createDevice(video::EDT_DIRECT3D9, dimension2d<u32>(1024, 768), 32,
                false, false, false, 0);
 
        if (!device)
            return 1;
 
        IVideoDriver* driver = device->getVideoDriver();
        ISceneManager* smgr = device->getSceneManager();
        IGUIEnvironment* guienv = device->getGUIEnvironment();
        IMeshSceneNode* node = smgr->addCubeSceneNode();
 
        IImage* image = driver->createImageFromFile("cube/pos-x.png");
 
        ITexture* texture = driver->addTexture("TestTexture", image);
 
        node->setMaterialTexture(4, texture);
 
        image->drop();
 
        driver->beginScene();
        smgr->drawAll();
        driver->endScene();
 
        device->closeDevice();
        device->drop();
    }
 
    std::cin.get();
}
 

Put a breakpoint after device->drop() and see the changes in memory usage. If I change

Code: Select all

 
node->setMaterialTexture(4, texture);
 

to

Code: Select all

 
node->setMaterialTexture(3, texture);
 

or use the OpenGL driver the leak dissappears. When I'm debugging using VisualStudio memory snapshots I also load the .pdb for Irrlicht, so I should see the exact Irrlicht type that causes the leak, however it's not the case, it only sais "External frame". Is this a bug, or am I doing something wrong?

[CuteAlien]

Thanks, will have to debug that.

[Joe_R]

Yesterday I have tried it with the newest trunk version, the problem is still there (the version I use for my main project is 1-1.5 months old, so I thought it would be a useful information for you). I've tried it with the 1.8.4. version too, that seems to work properly (I can't revert to 1.8.4. because I need cubemaps )

[Mel]

I think we should finally do the move and enable 8 textures by default in Irr XD

[CuteAlien]

@Mel: The reason we didn't do that yet is that many cards (even many new cards) do not support more than 4 textures. (edit: there has been some thread in the forum once where someone (maybe Hendu) posted a list which gave an overview which cards support how many textures. ) (edit2: Maybe the limit is only for fixed function pipeline)(edit3: Also another reason was that it might be rather slow currently due to some reset code and we still have to change some internals or everyone will pay the for the 8 texture even if most projects don't use them, but I never got around to profiling this in more depth, just some small profiling I did hinted at a problem there)

[Nadro]

4-8 textures limit is related only to fixed function pipeline. In shader pipeline even Shader Model 2.x (D3D9) cards support 16 textures, Shader Model 5.x (D3D11) cards support 32 or even 64 textures. However it will be good to switch from fixed size array for textures (SMaterialLayer) to dynamic array in SMaterial before bump max texture limit.

[CuteAlien]

*sigh* I'd prefer to avoid having dynamic arrays, allocations are slow (and yeah, I realize Irrlicht uses lists all over the place...). If you check logs for materials/texturelayer classes you will notice there's been some fighting going on already in code about dynamic arrays in the past.

Btw... Nadro - this leak is likely in your area of expertice... so if you have time again for Irrlicht I'd be glad if you take that one over.

[CuteAlien]

@Joe_R: How exactly do you know you have a memory-leak? VS telling you? I tried to reproduce it with your code, but without success so far. (with and without changing _IRR_MATERIAL_MAX_TEXTURES_).
Also - which VS version?

Note that you can get memory-leaks usually when you close the console window while a device is still open as that kills the app without releasing the memory (but you would have to click that really fast with your example code, so that's probably not it).

edit: Please also tell which graphic-card you are using.

[Joe_R]

Sorry, I've completely forgot about this topic. I used memory snapshots in VS2015. I took the snapshots after device->drop() was called in my example code (so the console window was still open), and the allocated memory increased after every iteration. If I changed the used texture slot to anything in the range of 0-3, this didn't happen.