GL_GENERATE_MIPMAP bug (nVidia)

I just came across this minor issue.

When uploading textures with the texture parameter GL_GENERATE_MIPMAP set to GL_TRUE, the nVidia drivers require the internalFormat parameter (3rd param) of glTexImage2D to be 1,2,3 or 4 (the way it worked in the old days). Passing the enums (GL_RGB, GL_BGRA etc) will result in a non-complete texture when mipmap filtering is enabled. However, mipmap level 0 is always functional, as evident when swapping GL_LINEAR_MIPMAP_LINEAR for GL_LINEAR, or restricting mipmap access by setting GL_TEXTURE_MAX_LEVEL to 0.

In other words, the driver suffers from the exact same shortcoming that most gluBuild2DMipmaps implementations suffer from. I guess because the driver writers copied the GLU code, without updating the parameter checks.

On a side note, glCompressedTexImage2D doesn’t have this problem.

I haven’t had any problems.
Which driver and GPU are you experiencing the problem with?

NV8800GT v280.26 on Windows XP. These are the latest drivers (haven’t tried beta though).

I first noticed the issue with v190.xx, so it’s been around for a while. I just didn’t realize it was a driver problem until today. I think most people use the numbers instead of the GL enums to play safe, for backward compatibility, or old habit. Likely few are affected, and no one noticed.

I just installed 280.26-notebook-win7-winvista-32bit-international-whql.exe on my gf8600 and GL_GENERATE_MIPMAP is working fine on a old context.
I haven’t used 1, 2, 3, 4 since the early version of GL. I only use GL_RGBA8.

I have not noticed any mipmap problems either and I do use both methods to generate mipmaps.
I use both a mobile nVidia 8600GT and AMD 4850 - both seem to work well.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.