Why is irrlicht storing the textures 3 times in directX?????

Pr3t3nd3r · Post by **Pr3t3nd3r** » Mon Oct 23, 2006 9:43 pm

I believe that irrlicht is storing the texture 2 times when using D3DPOOL_MANAGED. (one time in system memory and one time in video memory)
And is keeping the texture the third time ( device independently ) in the Image pointer.
The image pointer is useful for creating the direct x surface but after that i believe is completely useless. (i see that openGl is not keeping any image pointer ...)

I removed the Image->grab();
and
if (Image)
Image->drop();

The result is that the application is using now 200M (from 400M). And can run even on the systems on what it was beginning to have an very low fps ...
And no functionality seems to be affected. (alt+tab etc)

Please be free to verify if I'm right!
And now maybe i get credits in the irrlicht files for finding this bug. (if i'm right )

Spintz · Post by **Spintz** » Tue Oct 24, 2006 2:25 pm

I would say it depends. If loading a texture from a file, I believe the engine creates an IImage from the file. Then creates a deviceDependent texture and copies that IImage data into the texture. Aren't there some ways where the IImage is just passed to the getTexture call? I'll have to double check the API.

Pr3t3nd3r · Post by **Pr3t3nd3r** » Tue Oct 24, 2006 5:41 pm

I think the IImage data is only left a pointer to it in the directX texture. (of curse is private and no method for later access, and is only used at creation).

But in the OpengGl texture is not even keeping the IImage ... is just using it to create the deviceDependent and let it be trowed away.
(of curse the pointer to the image form the directX texture is not useful and need to be removed too)

From my check i didn't find any place where the IImage to be used (except at the creation of the surface)...

Any way keeping the image 2-3 times ... is really requiring much more memory ... the performance boost on my application is really visible on the systems with low memory ... (when the swap begin to be used as memory for textures ... the fps drops ... to 1-2 ...)

Also all my tests didn't show any bad behavior ... losing textures, etc ...

I believe Niko can clarify this faster ... why this error got in to the code. (i believe he initially was thinking at manually restoring the lost surfaces ...
or maybe was necessary in directX 8... not sure ...)

hybrid · Post by **hybrid** » Tue Oct 24, 2006 9:25 pm

It will be necessary when DeviceLost state is correctly handled (as textures are then recovered from images. And OpenGL also has an IImage stored, it's just shattered into pieces: All elements of IImage are also in the texture (except for one I don't remember for the moment), I just did not have the time to put it into an IImage.

sio2 · Post by **sio2** » Tue Oct 24, 2006 11:21 pm

hybrid wrote:It will be necessary when DeviceLost state is correctly handled (as textures are then recovered from images.

If D3D is managing a texture then it's a waste to have irrlicht keep the bits around as well. It's a bug.

vitek · Post by **vitek** » Wed Oct 25, 2006 6:08 am

Yes, it is a bug. The textures are currently created in the D3DPOOL_MANAGED pool [see docs]. This means the D3D runtime keeps a copy in system memory and uploads it as needed. There is no need to keep the additional in memory copy.

Travis

Grey Lantern · Post by **Grey Lantern** » Sun Dec 24, 2006 11:19 am

I may sound like a dummy but is this fixed in v1.2? It sounds nasty.

scrub that, just checked the svn patches tracker and it was only added on 2006-12-01 so I guess it's still pending.

hybrid · Post by **hybrid** » Sun Dec 24, 2006 11:32 pm

No, it's neither fixed nor is there someone to work out the proper code changes, yet. However, it's just system mem which is usually not really the main problem.