nVidia drivers - ever heard of OGL_App_SupportBits?

I’m using a variety of nVidia cards. Mostly Quadro 900 and 980. Some FX 3000 cards. I’ve been using the 56.72 series nVidia driver for a long time now with no problems.

I was recently forced to start using FX 3400 PCI Express cards. Problem is these cards won’t work with the 56.72 drivers. No problem. I’ll just upgrade to the latest drivers. 71.84. I upgraded my drivers across the board for all my development hardware.

Big mistake.

I’ve encountered all manner of issues. Turning on stencil tests when rendering a large body of geometry brings things to a crawl, random crashes that trace back to glVertex3fv(…) NOT related to stencil tests, and so on.

Revert back to the 56.72 drivers on my AGP hardware. Problems disappear. Reinstall the 71.84. Problems are back. ARGGHH!!!

I contacted nVidia. An engineer told me to add this entry to my registry:
OGL_App_SupportBits with a value of 0x80.

Well, the crashes stopped for the most part. Not completely, but things are better. Performance is somewhat worse but livable. However, the random crashes, even if they are less frequent, are not something I can live with.

Does anyone have a similar experience or any helpful advice?

You do check the actual pixel format you get after wglChoosePixelFormat don’t you? If you don’t that might explain your stencil crash, and if you don’t check return values generally that could explain the rest of the crashes.

Doing stencil operations on a pixel format without stencil is well-defined in the GL spec and there should be no crash for that (though of course it’s not a very meaningful thing to do).

Originally posted by knackered:
You do check the actual pixel format you get after wglChoosePixelFormat don’t you? If you don’t that might explain your stencil crash, and if you don’t check return values generally that could explain the rest of the crashes.
Return values? :rolleyes:

Yes, I do check return values. That’s not the problem.

The stencil issue is one related to performance. Not crashing. Although with the 71.84 drivers my app does randomly crash in code that has no stencil tests enabled. Performance does drop considerably if stencil tests are on AND I send a lot of geometry to the video hardware though.

It’s a driver issue or one heck of a coincidence. Use the old drivers and performance is back and crashes are gone. Just changing the drivers from 56.72 to 71.84 and I notice a significant drop in performance and random crashes. In fact, just yesterday I spent a few hours trying to figure out a not so random crash that showed up on a machine which I just installed the 71.84 drivers on. Everytime I would get to a certain scene in my app, POOF. Crash to the desktop. I grabbed a copy of the exception log and traced the crash back to a glVertex3fv(…) call. I couldn’t figure out for the life of my what was going on. Anyway, someone rebooted the PC and the crashing stopped. I don’t recall ever having problems like this with the older drivers.

One other thing I left out in the message above. The hardware isn’t home grown. The PCs themselves are Dell Precision 450 models.

FWIW, I don’t use wglChoosePixelFormat, I use ChoosePixelFormat.

<snip>
I know, completely OT. Mod., feel free to delete.

Edited by dorbie:

Your wish is my command ;-).

NVIDIA generally maintains excellent driver standards, abstract bashing in a technical forum is futile. Feel free to discuss tangible problems and/or report grievances to the manufacturer.

I don’t suppose you could link to a example app for the rest of us to try. (I assume no problems on ATI as well?)

Do you use VAR? Newer Nvidia drivers may have lower performance for this old extension. (use VBO)

Do you use threads in this app of yours?

I also assume you have some glGetError() calls in your code and are not returning errors. (As a test, try running GLIntercept with the Full_Debug profile against your app.)

Originally posted by sqrt[-1]:
I don’t suppose you could link to a example app for the rest of us to try. (I assume no problems on ATI as well?)
Well, I built a sample app for nVidia. That’s how I found out about ‘OGL_App_SupportBits’. Haven’t tried ATI hardware. Don’t use it. I only use nVidia. I’ve got a lot of nVidia hardware that I have to make use of!

Do you use VAR? Newer Nvidia drivers may have lower performance for this old extension. (use VBO)
No VAR, VBO, or FBO. However, that’s the kind of question I’m trying to get answered. What does ‘OGL_App_SupportBits’ do? Is there a section of code in my app that the new drivers don’t like (obviously)? I’d consider rewriting it if possible.

I did find this, but it made no sense to me. Maybe it will to someone else. Before I added ‘OGL_App_SupportBits’ I traced the performance problem back to a block of code that simply rendered a bunch of triangles like so:

  

glClear(GL_STENCIL_BUFFER_BIT);
glEnable(GL_STENCIL_TEST);

glBindTexture (GL_TEXTURE_2D, texture);
glEnable (GL_TEXTURE_2D);

glBegin(GL_TRIANGLES);

for(...)
{
  glTexCoord2f(0.0f, 0.0f); 
  glVertex3fv(...);  

  glTexCoord2f(0.0f, 0.0f); 
  glVertex3fv(...);  

  glTexCoord2f(0.0f, 0.0f); 
  glVertex3fv(...);  
}

glEnd();

WIth this code as is on the new 71.84 drivers without ‘OGL_App_SupportBits’, performance is awful. Now, if I comment out the the glTexCoord2f(…) calls OR comment out the stencil test, performance is back. If I leave the code as is and add ‘OGL_App_SupportBits’ to the registry, performance is OK. OR, if I revert back to 56.72 drivers, performance is back.

Do you use threads in this app of yours?
Yeah, but nothing fancy. Actually, all my OpenGL stuff is done on one thread for the purposes of this test.

I also assume you have some glGetError() calls in your code and are not returning errors. (As a test, try running GLIntercept with the Full_Debug profile against your app.)

Well, I do have glGetError() sprinkeled throughtout my code, but it’s disabled for release versions. I’ll enable it for the release builds and add some logging.

GLIntercept huh? Have to look at that…Very cool indeed, I’ll have to check this out!

Thanks everyone!

FYI a quick google for OGL_App_SupportBits revealed: http://www.nvworld.ru/docs/sqe.html

It looks like a flag to enable driver tweaks for 3D editing applications…(3D Studio Max, Maya etc) Which would make sence as these apps probably make use of a lot of raw glBegin/End calls.

Originally posted by sqrt[-1]:
[b]FYI a quick google for OGL_App_SupportBits revealed: http://www.nvworld.ru/docs/sqe.html

It looks like a flag to enable driver tweaks for 3D editing applications…(3D Studio Max, Maya etc) Which would make sence as these apps probably make use of a lot of raw glBegin/End calls.[/b]
Unfortunately that page doesn’t tell me what exactly OGL_App_SupportBits does and what setting a value of 0x80 to it addresses. I suspect setting OGL_App_SupportBits to 0x80 in the registry turns off a driver optimization or the like. But, I really don’t know.

Maybe somewhere I’m doing something I shouldn’t be. I’m just not sure. If I knew what was going on I’d consider rewriting parts of my app just to make it play better with the driver.

Oh well. Maybe some nVidia engineer will see this post and enlighten us.

Does anyone have a similar experience or any helpful advice?
I guess you are doing something unusual which causes crashes. Are you making too many calls in glBegin/glEnd? Are you using display lists and doing some oddball thing with it.

Maybe there are other factors at play here like if you are using FSAA, or if you have dual monitor setup, …

Sorry, I can’t help more than that.

cru, would you be able to send me the sample app that reproduces the problem? I’d like to test it with our latest internal drivers and give it to a few of our driver engineers so we can figure out what is causing the crashes and performance degradation.

Originally posted by jra101:
cru, would you be able to send me the sample app that reproduces the problem? I’d like to test it with our latest internal drivers and give it to a few of our driver engineers so we can figure out what is causing the crashes and performance degradation.
Sure. If you don’t want to post your email address here just send me a PM (can you do that on this board?) and I’ll get in touch with you.