Fighting nvidia 175.16 mipmapping issues

· by Steve · Read in about 2 min · (330 Words)

Nvidia released their new 175.16 drivers about 10 days ago, and I was glad to see that the stalling issues we’d had on multicore CPUs with OpenGL / XP in the previous 169.21 driver were fixed. However, to my dismay a set of new problems have appeared with mipmapping, again on OpenGL only.

I’ve done quite a bit of testing over the past week to try to narrow the issues down, but the bottom line is currently this:

  1. Generating mipmaps in hardware using the GL_SGIS_generate_mipmap extension no longer functions correctly. OGRE uses this whenever it’s advertised to speed up mipmap construction, but now it results in corrupted mipmaps. The current workaround is to detect an nvidia card and ignore the advertised support for this extension until it’s resolved.
  2. Even with this extension disabled, software generation of mipmaps via gluBuild2DMipmaps works only for uncompressed 2D textures. Using it on any texture compressed with DXT / S3TC, or any cube map surface, results in missing or corrupt mipmaps. The only current workaround for these 2 scenarios is to use the DDS format, and to pregenerate mipmaps and save them in the DDS file using a tool such as DxTex, Texture Tools, or CubeMapGen. Provided the mipmaps are loaded rather than calculated, they work fine (our DDS codec will happily load the custom mips contained in the file and use them). You could also use OGRE’s own HardwarePixelBuffer interface to generate mip levels in code yourself of course.

I’ve reported this to nvidia and hopefully we’ll get a resolution in the near future, but in the mean time you can use the workarounds above. You can also discuss the issue in the forum thread I created for it. I’ve always been a bit of a cheerleader for nvidia on GL so it’s a bit disappointing to find these kinds of issues in the latest couple of drivers, but they are at least talking to me about it so I’m hopeful for a resolution.