Anyone who has updated to the NVIDIA 175.16 drivers in recent days and who uses GL may have noticed 2 things:
1. They've fixed the GL stuttering problem introduced with 169.x (yay!)
2. Mipmaps are corrupted in GL (boo!)
The latter problem appears to be a flaw with the GL_SGIS_generate_mipmap extension implementation in this driver. It's possible to avoid it by disabling hardware mipmap generation for the moment, which will cause the mipmaps to be generated in software instead. Here's the patch (Shoggoth, in Eihort, use 'mGLSupport->getGLVendor().find("NVIDIA") == std::string::npos' instead of 'rsc->getVendor() == GPU_NVIDIA'):
An update on this, I've noticed that even with this workaround, mipmaps on cubic textures are corrupted with the 175.x drivers in OpenGL, although 2D textures are fine and so is D3D. I haven't found any workaround for this yet. I've reported it to nvidia too.
My advice is that if you have an nvidia card and want to use OpenGL (at least on Windows), stick to the 163.x driver stream. Both 169.x and 175.x seem to have issues with GL. This is disappointing as nvidia have normally been more reliable with GL drivers than most.
An update to this one, it's not just cubic reflection maps, it appears to affect some other DDS files too. I'm still trying to track down the exact set of circumstances.
Also, the workaround to turn off hardware generated mipmaps has caused an unexpected side-effect on OS X, certain demos (Demo_Smoke, Demo_ParticleSystem, Demo_Dot3Bump, only when changing to the knot.mesh) now start failing deep in the GL driver under glClear(). This is on an nvidia 8600GT based MacBook Pro. Restoring the hardware mipmap generation (ie undo revision 7493) fixes the problem - the Apple driver is also too old to have the mipmap corruption problem yet.
Something very odd is going on here, I'm going to have to pick through the mipmap code all over again I think to make sure there's no issues.
Thanks a bunch . I feel kind of stupid, but I never found a nice, useful "older drivers" link
An update to this one, it's not just cubic reflection maps, it appears to affect some other DDS files too. I'm still trying to track down the exact set of circumstances.
Good catches there!
Something very odd is going on here, I'm going to have to pick through the mipmap code all over again I think to make sure there's no issues.
Wait, do you think it might be something in Ogre that's going wrong? I think it's purely a driver issue, why would it be fine with older drivers and magically broken with the newer ones .
Ok, I've done some more investigation and so far I've only increased my confidence that this is not an Ogre problem. I'll post the contents of the update email I've sent to nvidia since that covers it:
Further testing has revealed more information, I was mistaken about the 2D problems being DDS loading generally, it *is* specific to DXT and cube maps. I'll summarise my findings.
The following situations seem to result in corrupt or missing mipmaps in the 175.x drivers:
1. Using GL_SGIS_generate_mipmap
2. Software generation of mipmaps for *any* cubic surfaces (compressed or uncompressed)
3. Software generation of mipmaps for DXT compressed 2D textures
The workarounds so far:
1. Detect nvidia and ignore reported support for GL_SGIS_generate_mipmap
2. None found for non-DDS textures, for DDS, precompute mipmaps and store them in the DDS
3. Same as 2
Since precomputed & stored DDS mipmaps seem fine in all cases it really does appear to be the mipmap generation that's at fault.
Things of note that DO work (for clarification):
1. Software generation of mipmaps for uncompressed 2D textures
2. Mipmaps for cubic textures if precomputed and loaded rather than calculated via GL
3. Mipmaps for DXT compressed textures if precomputed and loaded rather than calculated via GL
I hope that helps with the investigation. At least I can temporarily advise our users to use precomputed mipmaps for the cube maps and DXT compressed textures for now.
So for now, if you're hitting this problem with DXT compressed or cubic textures, please precompute your mipmaps (e.g. using DxTex or similar) to avoid the problem.
The Apple problem is a bit of a wildcard, I can't recreate it on any other hardware. There may be some additional problem with Apple drivers and software mipmap calculation right now - what I will do for the moment is make the disabling of hardware mip calculation not happen for Apple, since their drivers haven't broken this yet.
I'll let you know when I have any news on this from nvidia.
Ok, resolutions for all these problems are in Subversion branches/v1-4, branches/v1-6 and trunk.
There does indeed appear to be a confirmed bug in the hardware mipmap generation of non-compressed textures in 175.16 which NVIDIA have logged for fixing.
The cube map software mip generation problem was our bug, we were getting the internal format of the GL texture through glGetTexLevelParameteriv as is the recommendation, but for cube textures we were incorrectly using GL_TEXTURE_CUBE_MAP instead of GL_TEXTURE_CUBE_MAP_POSITIVE_X et al. Older drivers must have been happy with this, but it was getting thrown out as an invalid enum which was leaving the format as random for mipmap building.
The DXT mipmap issue was that in software generation mode, GLU can't generate mipmaps for compressed textures and indeed we weren't even asking it to because of that - you could only generate them in hardware. Luckily however, the bug in hardware mipmap generation does not appear to affect DXT compressed textures, so I've made the workaround for this more specific; instead of turning off all hardware mip generation, I only turn it off for uncompressed textures.
In my tests this fixes all the issues. It does mean that mipmap generation for regular uncompressed textures is likely to be slower on NVIDIA hardware until they fix the driver bug, but at least everything looks right.
OGRE EXCEPTION(3:): Error getting texture format: invalid enumerant in GLTextureBuffer::upload
Don't know why exactly it fails but when I replace the glGetTexLevelParameteriv(..., GL_TEXTURE_INTERNAL_FORMAT, ...) function call with PixelUtil::getComponentCount() it works.
Hmm, what hardware / drivers was this on? I tested with ATI too and it was fine. What's also odd is that the same call is made in the GLTextureBuffer constructor and presumably doesn't fail for you.
My concern with using mFormat to determine the components was that if the internal format had differed from the expected format, we wouldn't have necessarily detected it, but now I see that we derive mFormat from the result of glGetTexParameteriv anyway (the call in GLTextureBuffer that I assume must have worked earlier for you). Interestingly I also note that on Mac OS X there are reports that using the internal format directly may not work on some hardware, which might explain some of our mip issues there in the past.
I tested it in linux with a NVIDIA GeForce 7950 GT (driver 100.14.19).
But the error is not created by the glGetTexLevelParameteriv(..., GL_TEXTURE_INTERNAL_FORMAT, ...) function call it is created somewhere before. I placed some extra error checks and it seems that the error is created even before the GLTexture::createInternalResourcesImpl() function call. So another solution would be adding an dummy glGetError() function call at the beginnig of GLTexture::createInternalResourcesImpl().
Yeah, I've used your way anyway - I've discovered that some of the non-power of two texture problems on some more obscure drivers may have been caused by us using the internal format code instead of the number of components in this call, so the change is probably for the best anyway.
I'm not sure, but I think that this driver version also includes a bug where it won't honour the destination box used when blitting from memory, as done by http://www.ogre3d.org/docs/api/html/cla ... elBuffera9
I.e. it will blit to the whole buffer instead of just the area specified. I believe I haven't seen the problem until I upgraded my nvidia driver (and subsequently had to apply the patch mentioned here to get the mipmaps to work). I'll research it some more, but I though I should mention it in case someone else is seeing the same problem.
OGRE 1.4.9 has been released pretty much specifically to squash this issue. On NVIDIA hardware mipmaps will be calculated in software for now, until they fix their driver bug (or rather, released the fixed driver as they tell me they've already fixed it internally).
Sorry to re-open this, but has the cube-map issue been resolved with 1.4.9? I'm not 100% sure how it looked, but this is what's happening to me and some others messing with SPT:
I am using the new drivers right now, and this only happens to me in OpenGL mode (although, captnoord said it happens to him in DirectX mode as well on his 8600M GT). It happens whenever a cube-map texture is created, either manually or through "combineUVW" in the material. You can see there I'm just using the "nm_*.png" series of textures from the normalized cube-map face textures.
I've never had much luck re-arranging drivers on PCs for graphics, but I'm going to give it a shot to see if there's any change.
Yes, the cube map issue is solved. That boundary issue is usually because you haven't set the texture addressing mode to 'clamp' and it's filtering over a wrap of the cube face.
I had a problem with mipmap corruption with OpenGL in OGRE 1.4.9 on an integrated chipset (Intel 915GM) when running the basic tutorial 2. It seems Intel drivers have the same problem with uncompressed textures. Forcing texture compression in the driver settings fixes the problem:
I'm wondering if this bug is passed to OSX with the last OSX iteration (10.5.5), just found that our ogre based games break with an HARD NVIDIA driver crash on 8800gs based iMacs with 10.5.5, you cannot recover the machine with a "kill -9", the video is compromised till you reboot, the gdb backtrace of the game is the following:
#0 0x96f1c4a6 in mach_msg_trap ()
#1 0x96f23c9c in mach_msg ()
#2 0x924e6626 in io_connect_map_memory ()
#3 0x281c7d6f in gldUpdateDispatch ()
#4 0x281c8120 in gldFlush ()
#5 0x282ccb2a in gldGetTextureLevel ()
#6 0x281d1437 in gldGetTextureLevel ()
#7 0x281d19a9 in gldGetTextureLevel ()
#8 0x28015741 in glTexSubImage2D_Exec ()
#9 0x95034387 in glTexSubImage2D ()
#10 0x26efc3b7 in Ogre::GLTextureBuffer::upload ()
#11 0x26efc97a in Ogre::GLHardwarePixelBuffer::blitFromMemory ()
#12 0x26efca9e in Ogre::GLTextureBuffer::blitFromMemory ()
#13 0x00d0624a in Ogre::HardwarePixelBuffer::blitFromMemory ()
#14 0x00bfd38e in Ogre::Texture::_loadImages ()
#15 0x26ee2dbd in Ogre::GLTexture::loadImage ()
#16 0x26ee3175 in Ogre::GLTexture::loadImpl ()
#17 0x00c1a421 in Ogre::Resource::load ()
#18 0x00bfdaa3 in Ogre::TextureManager::load ()
#19 0x00bff191 in Ogre::TextureUnitState::_load ()
#20 0x00bbcc06 in Ogre::Pass::_load ()
#21 0x00bfaa7e in Ogre::Technique::_load ()
#22 0x00b6ff24 in Ogre::Material::loadImpl ()
#23 0x00c1a421 in Ogre::Resource::load ()\
#24 0x00bf8b0d in Ogre::SubEntity::setMaterialName ()
#25 0x00b4ebca in Ogre::Entity::buildSubEntityList ()
#26 0x00b4f5cb in Ogre::Entity::Entity ()
#27 0x00b4fb62 in Ogre::EntityFactory::createInstanceImpl ()
#28 0x00ba9138 in Ogre::MovableObjectFactory::createInstance ()
#29 0x00bde120 in Ogre::SceneManager::createMovableObject ()
#30 0x00bdf58b in Ogre::SceneManager::createEntity ()
#31 0x002c8ede in Pina::GameEntity::load ()
#32 0x000f23c9 in Pina::PointNClickApplication::createIntroResources()
The texture causing the problem is a compressed one, I'll try to recompile ogre disabling hardware mipmap generation (and maybe dds texture support) also on NVIDIA cards (I've already had to do it on ATI based cards..).
I reply to myself just to tell that I've backported to the 1.2 tree used by Jack Keane and Ankh2 the patch proposed by sinbad (the one that disables automipmap generation) and the games started to work again on 10.5.5
? "Archived drivers" doesn't show anything interesting.
. I feel kind of stupid, but I never found a nice, useful "older drivers" link 
.
. Excellent investigating there 
