Actually I have seen something ominous myself with respect to FBO’s:
glTexParameteri(m_texture_type, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(m_texture_type, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexImage2D(m_texture_type, 0, //target and mipmap level
0, //border size
NULL //no data uploaded
//NOTE!! Ask to generate mipmaps here!!
//attatch the texture to the framebuffer object:
produces GL_FRAMEBUFFER_UNSUPPORTED. Which is very odd, one can see that I ask for mipmaps to be generated there? Anyone out there know what is going wrong there?
If I add:
all nasties go away.
Edit: Ahh nevermind, I truly posted without thinking! Ahem: in my code I was also attaching integer texture targets, and for those you are not supposed to do filtering at all… though I would think that glGenerateMipmap should have generated an error on integer textures.
One more edit: looking at the GL 3.2 specification, for minification filtering, I only see this:
When target is TEXTURE_RECTANGLE, certain texture parameter values may not be specified. In this case, the error INVALID_ENUM is generated if the TEXTURE_WRAP_S, TEXTURE_WRAP_T, or TEXTURE_WRAP_R parameter is set to REPEAT or MIRRORED_REPEAT. The error INVALID_ENUM is generated if TEXTURE_MIN_FILTER is set to a value other than NEAREST or LINEAR (no mipmap filtering is permitted).
Is there anywhere in the spec that actually says that filtering is NOT allowed to integer textures?
Edit: too fast to post:
If the internal format of the arrays is integer (see (see table 3.12), TEXTURE_MAG_FILTER must be NEAREST and TEXTURE_MIN_FILTER must be NEAREST or NEAREST_MIPMAP_NEAREST.
page 171 on texture completeness.
Another edit: I don’t know if this is a driver bug or not, but using GL_NEAREST_MIPMAP_NEAREST on an integer texture and then using glGenerateMipmap still will generate GL_FRAMEBUFFER_UNSUPPORTED, and looking at how glGenerateMipmap is specified it looks like integer texture targets should work ok with glGenerateMipmap.