Loading textures takes about 2/3 - 3/4 of initialization time in our engine. Lot of time is spent in driver for texture compression, and in our code for generating mipmaps for normal maps (down sample, normalize each vector). Can this be speed up ? Is there a way to make the driver create all mipmaps for normalmaps ? Can I load already compressed textures to save time ?

Use a file format that supports compression and mip maps, like DDS.

Use DDS. It's precompressed (to one of the S3TC/DXT formats), already in a format that's most likely native to your GPU, and can contain a full mipchain in each file. Don't be put off by the fact that you normally see it mentioned in conjunction with D3D; it's just a binary file format and all you need is a loader for it.

http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt

Can I use DDS with OpenGL ? Is so how do I load the data into OpenGL ?

Can I use DDS with OpenGL ? Is so how do I load the data into OpenGL ?

http://www.codesampler.com/oglsrc/oglsrc_4.htm#ogl_dds_texture_loader

I use DevIL to read the DDS file and the compressed DDS texture goes straight to GL. Look at

mhagain post for the extension to use.

I have played a little with this issue. I cannot use DDS files, because I want source data to be as small as possible to minimize download time. What I found is:
- OpenGL compresses textures very slowly, maybe I should write my own compression code.
- If I switch compression off glTexImage2D is still relatively slow.
- gluBuild2DMipmaps is much slower than generating mipmaps on client side and calling glTexImage2D for each mipmap level.

So my questions now are:
- Is there a third party library of some kind that can compress textures fast ?
- Why is glTexImage2D so slow ? it takes 3 sec for a ~2500 calls (with mipmaps and with out compresson) that is extreamly slow for just coping data.

glTexImage2D does more than just copy data. It needs to allocate video RAM too, possibly do some moving of already allocated data around to deal with fragmentation, possibly do some swapping, possibly allocate backup copies in system memory, and very probably convert data from non-GPU-native formats to GPU-native formats.

You'll get the most mileage on the latter point, and this relates to the 'format' parameter to glTexImage2D. If you're using GL_RGB you should investigate switching to GL_BGRA. In most cases this will be considerably faster, and I've personally benchmarked it up to 6 times faster on NVIDIA and up to 40 (!!!) times faster on Intel. Likewise if you're using GL_BGR you should still consider switching to GL_BGRA. For further info see here: http://www.opengl.or...and_pixel_reads

Of course this means that you need to store images in a format that supports BGRA, otherwise you'll need to convert on the CPU during texture loading. And that in turn means TGA is the only really viable option, which means bigger image files. So you're in tradeoff country right away.

That brings me to DDS again. I'm quite surprised that you found DDS files to be excessively large. It will give you between 8:1 and 4:1 compression over TGA, so unless you're using something like PNG as your image format (which will also contribute to slowness as it needs to be decompressed before being sent through glTexImage2D) DDS should be optimal.

I have played a little with this issue. I cannot use DDS files, because I want source data to be as small as possible to minimize download time. What I found is:

Maybe at this point it would be interesting to know what format you are using for your textures, if compressed DDS files are too large. And don't say "jpg".

Also, did you zip them and compare _that_ size? Because that's the only size that matters for downloads.