Preload ~700mb worth of JPG-images

[fas]

Hello everyone,

I have around 750mb of JPG-images (all photographs). In each frame I select one of those images (unknown in advance) and load it with

Code: Select all

driver->getTexture(imageFilename)

before rendering it. This, however, is a real FPS-killer.

So my idea was to just preload all the images. For some reason, the images take up much more memory than I thought (I run out of memory). Disabling mipmaps and reducing the quality (and thus size) if the images to the minimum did not work either.

My questions are:
- Why do the images take up so much memory? I got around 2GB of memory available for the application and it only manage to load around 30% of all images.

- Do you have any ideas of how I could either pre-cache all the image data or how I can load it fast enough not to affect the frame rate? As I said, the choice of which image is to be displayed is not known in advance.

I hope you understand my problem. If not, feel free to ask me anything!

Cheers![/list]

[CuteAlien]

JPG is a rather good compression - but in memory you have them de-compressed so they will need a lot more memory. I don't think there is any way you can pre-cache them all.

[yamashi]

Asynchronous loading or multi threaded should be the best solution...
Remember that when you load a texture you also load it on your GPU so you have to worry about your GPU's memory limit as well.

[fas]

Thanks for the replies.

JPG is a rather good compression - but in memory you have them de-compressed so they will need a lot more memory.

That is probably the reason it does not work.

Asynchronous loading or multi threaded should be the best solution...
Remember that when you load a texture you also load it on your GPU so you have to worry about your GPU's memory limit as well.

I also tried loading it them as images (IImage) with the same result.
Would you mind explaining the asynchronous approach more in detail? Do you mean that loading the image in a seperate thread will stop the lagging?

[yamashi]

It will not affect the frame rate but it will still take time to load...
Instead of getting stuck while it's loading it will still show the previous picture while you are loading and once it's done loading you just replace the old one with the new one.
For asynchronous tasks it's going to be quite difficult in C++ since they are not native so you will have to play around with threads and callbacks...

[fas]

Thanks, I tried it out. Out of several problems this is the worst: even with the use of critical sections the application crashes if the images are are changed rapidly. Maybe I have to think it over and be more carefully. I heard irrlicht is not threadsafe, maybe this is a problem too.

Remember that Irrlicht is not thread-safe at all.
You HAVE to run Irrlicht in your main thread.

(http://irrlicht.sourceforge.net/phpBB2/ ... p?p=150190)

[Nox]

yeah irrlicht is not threadsafe but even if it would be threadsafe the "load" process from sysmem to device mem may take a long time. Moreover your app stores every image twice at least. Once in the sysmem and once in the devicemem. This is needed for the reset after a devicelost.
By the way: do you remove the old images? This may save some place but increase the reload time. Isnt there a compressed dataformat for texture in the device, is there? I think its called dxt but i guess irrlicht does not support it.

[fas]

Thanks a lot, Nox!

If I do

Code: Select all

material->setTexture(0, SceneManager->getVideoDriver()->getTexture(imageFilename));

then the image is only loaded into sysmem, not devicemem and only when the material is used (driver->setMaterial) the texture is moved to devicemem, right? I don't have access to the Irrlicht source code right now, so this is only a guess.

For the moment, I do remove the images again after they move out of view, yes. If I don't, the program crashes at some point when too many images have been shown (bad_alloc).

As for compressed textures: maybe this can be of use:
http://irrlicht.sourceforge.net/phpBB2/ ... p?p=209452.

[hybrid]

No, the images are directly moved to device mem also, in the getTexture call.
Compressed formats are not yet supported by Irrlicht natively.

[yamashi]

In order to load your texture in multithread, you can use a lock like such but would require to edit irrlicht's sources...
It crashes in the following cases :
- access to a texture that's not fully loaded
- access to a texture that it being loaded
- access to an unexisting texture

to get rid of the unexisting texture and the not fully loaded texture you have to make sure that the node will not register it self until it's loaded.
And to get rid of the texture being loaded which means that you are calling loading functions while rendering or doing anything GPU related... You have to lock the loading function and the rendering function.
Imo it should be something like this :

Code: Select all

function load_texture
loop 
>some code
>do it x times 
>signal condition
end loop

and in the rendering function

Code: Select all

loop
>wait for condition
>beginscene
>render
>endscene
>signal condition

I don't really know how irrlicht's texture loading function works so you might need to tweak it a little but that's basicly how you should do it and that's only if you won't do anything else like loading multiple textures at the same time...

[hybrid]

Instead of calling getTexture you can create an Image from file and addTexture from that image later on from the main thread. This increases the emory load, but avoids problematic GPU calls.