This is one question I’ve been wondering about for a long time. Say I had RGB and RGBA images, I put into texture atlases. I could mix the RGB and RGBA images, but then all texture atlases would have to be RGBA. Can savings in terms of GPU memory and/or performance be made by making RGB-only and RGBA-only texture atlases?
From performance point of view, if you use 8-bits per component then most probably RGBA is better anyway. Of course, if you store RGB textures in an RGBA atlas then maybe you loose some memory, but I think most probably nowadays every GPU represents RGB textures as RGBX (due to memory access peformance/capability limitations) so maybe there is no any memory saving if you use an RGB atlas as well.
It depends. What image format are you using? RGB and RGBA are very large classes of image formats.
For example an RGB8 image, in all likelihood, takes up the same space as an RGBA8 images. So you’d gain nothing from this. However, this is probably not true for 16F or 32F formats. And unless you’re using DXT1, it’s not true of any compressed format either.
However, you should remember that the purpose of a texture atlas is to improve performance by reducing the number of texture binds you do per frame. Performance improvements often come with drawbacks, like increased memory usage. So how much is the performance improvement of using a texture atlas worth?
OpenGL specifies that any texture image that has less than 4 components per-texel will be expanded to 4 components.
Unless you have really funky hardware that (1) is actually capable of supporting less than 4 components natively, and (2) doesn’t conform to the spec, then there is no memory saving whatsoever from using less than 4 components.
http://www.opengl.org/sdk/docs/man/xhtml/glTexImage2D.xml (GL_RGB/GL_BGR description)
Each element is an RGB triple. The GL converts it to floating point and assembles it into an RGBA element by attaching 1 for alpha.
I’m pretty sure that this is not the case with 32F, 32I or 32UI component formats, as Alfonse said.
I understand that differently. It does not say anything how this will be implemented and stored in the GPU memory, only defines the alpha value when dealing with RGB formats. Storage can still be 3 component RBG, but when you use the A part, it will be 1.
I also think that your interpretation is right. The GL spec does rarely talk about any internal representation. This part rather refers to how texturing will interpret the underlying data.
Well there’s also this: http://www.opengl.org/wiki/Common_Mistakes#Unsupported_formats_.233
As I already said, nowadays drivers in fact usually convert RGB8 to RGBX8 but this is only because of alignment issues. However, this is not the case with RGB32F for example.
So, in the case of RGB8 and RGBA8 formats, it probably doesn’t matter. Otherwise, one has to bench.