NVIDIA 175.16 drivers and mipmap corruption: get 1.4.9!

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

NVIDIA 175.16 drivers and mipmap corruption: get 1.4.9!

Post by sinbad »

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'):

Code: Select all

Index: RenderSystems/GL/src/OgreGLRenderSystem.cpp
===================================================================
--- RenderSystems/GL/src/OgreGLRenderSystem.cpp	(revision 7490)
+++ RenderSystems/GL/src/OgreGLRenderSystem.cpp	(working copy)
@@ -230,10 +230,18 @@
         // Check for hardware mipmapping support.
         if(GLEW_VERSION_1_4 || GLEW_SGIS_generate_mipmap)
         {
+			bool disableAutoMip = false;
 #if OGRE_PLATFORM == OGRE_PLATFORM_APPLE
 			// Apple ATI drivers have faults in hardware mipmap generation
-			if (mGLSupport->getGLVendor().find("ATI") == std::string::npos)
+			if (rsc->getVendor() == GPU_ATI)
+				disableAutoMip = true;
 #endif
+			// NVIDIA 175.16 drivers break hardware mip generation
+			// disable until fixed
+			if (rsc->getVendor() == GPU_NVIDIA)
+				disableAutoMip = true;
+
+			if (!disableAutoMip)
 				rsc->setCapability(RSC_AUTOMIPMAP);
         }
 
I'm raising the bug with my contacts at nvidia and committing this workaround to the v1-6 branch until they fix the drivers.
Last edited by sinbad on Tue Dec 23, 2008 12:45 pm, edited 3 times in total.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Post by nullsquared »

Where do I find older drivers :oops:? "Archived drivers" doesn't show anything interesting.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

163.75
169.21

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.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Post by nullsquared »

sinbad wrote:163.75
169.21
Thanks a bunch :D. I feel kind of stupid, but I never found a nice, useful "older drivers" link :oops:
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 :|.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Post by nullsquared »

Alright, sounds good to me :). Excellent investigating there :shock:
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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.

Thanks go to NVIDIA for helping me sort this out!
User avatar
kickin_bear
Kobold
Posts: 31
Joined: Sun Apr 06, 2008 10:06 pm
Location: Karlsruhe, Germany

Post by kickin_bear »

I get an exception with this workaround:

Code: Select all

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.

Here is the patch:

Code: Select all

Index: RenderSystems/GL/src/OgreGLHardwarePixelBuffer.cpp
===================================================================
--- RenderSystems/GL/src/OgreGLHardwarePixelBuffer.cpp  (Revision 7561)
+++ RenderSystems/GL/src/OgreGLHardwarePixelBuffer.cpp  (working copy)
@@ -381,19 +381,7 @@
        else if(mSoftwareMipmap)
        {
                GLint internalFormat;
-               glGetTexLevelParameteriv(mFaceTarget, mLevel, GL_TEXTURE_INTERNAL_FORMAT, &internalFormat);
-               GLenum glErr = glGetError();
-               if (glErr != GL_NO_ERROR)
-               {
-                       const char* glerrStr = (const char*)gluErrorString(glErr);
-                       if (glerrStr)
-                       {
-                               throw Exception(Exception::ERR_RENDERINGAPI_ERROR,
-                                       String("Error getting texture format: ") + glerrStr,
-                                       "GLTextureBuffer::upload");
-                       }
-
-               }
+               internalFormat = PixelUtil::getComponentCount (mFormat);
                if(data.getWidth() != data.rowPitch)
                        glPixelStorei(GL_UNPACK_ROW_LENGTH, data.rowPitch);
                if(data.getHeight()*data.getWidth() != data.slicePitch)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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'll try this workaround out, thanks.
User avatar
kickin_bear
Kobold
Posts: 31
Joined: Sun Apr 06, 2008 10:06 pm
Location: Karlsruhe, Germany

Post by kickin_bear »

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().
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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.
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4
Contact:

Post by Azatoth »

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.
Ember, GPL virtual world client.
Development blog
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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).
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

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:

Image

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.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

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.
User avatar
HexiDave
OGRE Expert User
OGRE Expert User
Posts: 1538
Joined: Sat Jan 14, 2006 8:00 pm
x 1

Post by HexiDave »

*Sigh*

Well, I'm a colossal idiot. I had my 1D lookup texture clamped, but the cube-map was missing that line.

Much appreciated!
User avatar
SiENcE
Goblin
Posts: 231
Joined: Thu May 11, 2006 3:07 pm
Location: Berlin
Contact:

Post by SiENcE »

It seems, that with the current driver 1.77 this problem is fixed :-).
Lafazar
Gnoblar
Posts: 5
Joined: Thu Aug 28, 2008 3:31 pm

Post by Lafazar »

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:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=43996
ggreco
Kobold
Posts: 25
Joined: Fri Sep 15, 2006 11:07 am

Post by ggreco »

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:

Code: Select all

#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..).
ggreco
Kobold
Posts: 25
Joined: Fri Sep 15, 2006 11:07 am

Post by ggreco »

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
sausage
Gnoblar
Posts: 10
Joined: Tue May 02, 2006 10:26 am
Location: Captains Flat, Near Canberra, Australia
Contact:

177 drivers for Linux mipmap issue fixed - Confirmed

Post by sausage »

I was going to create a new post rather than bump the topic but seeing it is a sticky...

I'd like to confirm for Linux users that the 177.x NVidia drivers do in fact correct the mipmap corruption bug, not just for windows users.

Test case was Ogre 1.4 on Fedora 9, Gnome with a 2.6.26 kernel.

Thanks to the original posters for the advice to get rid of 169.x drivers.
Post Reply