Too many textures in GPU RAM?

D. Novak · Post by **D. Novak** » Tue Jan 20, 2009 2:37 pm

I have a dataset which consists of a 3D Model with an aerial photograph attached to it. The texture is made of around 1000 256x256 texture tiles. On my laptop with 512 MiB GPU RAM it runs fine (~500'000 triangles with ~45 FPS). On my working computer (256 MiB GPU RAM) it slows down to 1 FPS.

With Rivatuner I've checked the GPU memory usage on my laptop and noticed that it grows to 246 MiB.
Can it be that once the GPU RAM is filled Irrlicht is not able to put out more than 1-2 FPS?

An additional question that arose is, why the textures take up so much space on the GPU RAM. When I calculate the total size on my harddisk it's 40.6 MB - so it's basically increasing it's size by a factor 5.
Sadly I cannot measure the GPU RAM utilization on my working computer because it runs Fedora 7 with an ATi FireGL v7200 and I haven't found a program to read the GPU RAM utilization.

JP · Post by JP » Tue Jan 20, 2009 2:53 pm

Well if you fill up the GPU ram and still need more textures then textures will have to be switched in and out as necessary which is a costly procedure, so that will kill your performance.

Textures are stored in memory uncompressed. So you may have some lovely super compressed JPGs which are tiny on disc but when loaded into your app they're gonna be equivalent to 24/32bit BMPs pretty much. (this isn't Irrlicht's fault though!)

jontan6 · Post by **jontan6** » Tue Jan 20, 2009 3:01 pm

1. yes, swapping will hit ur performance very hard
2. yeah, that factor of 5 is incorrect.... texture is stored uncompressed in mem

D. Novak · Post by **D. Novak** » Tue Jan 20, 2009 3:04 pm

JP wrote:Well if you fill up the GPU ram and still need more textures then textures will have to be switched in and out as necessary which is a costly procedure, so that will kill your performance.

Textures are stored in memory uncompressed. So you may have some lovely super compressed JPGs which are tiny on disc but when loaded into your app they're gonna be equivalent to 24/32bit BMPs pretty much. (this isn't Irrlicht's fault though!)

I just did a quick calculation and you're right. When I save them as 24bit bmp's I get around 190 MiB of texture data. I guess a little bit more if I include the alpha channel.
So in other words: It's no use to compress textures at all?

Although one thing that strikes me odd: I've seen a similar behaviour on a different machine. When the model was in sight the frames dropped to 1 FPS - when I didn't see it it went back to 300+ FPS.

JP · Post by JP » Tue Jan 20, 2009 3:12 pm

The use of compressing the textures is that if you want to distribute your application then it's a much smaller package to distribute if you compress your textures! I don't know if loading times are particularly affected by the compression or not...

Maybe when your model is in view it's having to do the texture switching, if not then the textures aren't needed to be switched (as the model isn't being rendered) so it gets a decent framerate.

D. Novak · Post by **D. Novak** » Tue Jan 20, 2009 3:30 pm

I suppose the only solution would be to use some form of texture compression like DXT1 or similar to save memory space - just open source (FXT?).

rogerborg · Post by **rogerborg** » Tue Jan 20, 2009 3:57 pm

This is as I'd expect. I use .bmp textures unless I need an alpha channel, since they're faster to load, and compress down just fine if you zip up a distribution. They're only larger on disk, but disk space is cheap.

Also, remember that the texture memory required will be 1/3 larger than the largest (power of 2) resolution, unless you disable mipmapping.

So while a 190 x 490 24 bit RGB source .bmp would be ~273KB, a texture based on it will (due to rounding up, alpha channel and mipmapping) require:

256 * 512 * 4 * 1.3333 = 683KB

D. Novak · Post by **D. Novak** » Wed Jan 21, 2009 2:35 pm

I was expecting the 1/3 bigger size because of the mip maps - what I didn't know was that the texture is basically 'uncompressed' again, taking the same amount of space like a bitmap. That's why I was surprised by the size.

I have another question, that goes roughly into the same direction:

When I force my graphics card driver to force AA & AF to be 'off' I get worse FPS than when I set it to 'application controlled'.
The same model has ~26 FPS when I enforce AA & AF to be 'off' - with application controlled it goes up to 45 FPS. This is both happening under Linux and Windows. Any ideas what that is all about?