PDA

View Full Version : nvidia driver 310.xx or newer



aronsatie
03-08-2013, 10:50 AM
Hi,
I have been working on an application based on OpenGL 2.1.
For several years, no Nvidia driver has given me any trouble, I periodically downloaded and installed the new version with no issues whatsoever. Since version 310.90 or newer, my application can initialize a rendering context, FBO, etc., but then it crashes at various opengl function calls (if I comment out one 'culprit', then there will be another, etc.).
Is there any change in these new drivers, is maybe Open GL 2.1 support dropped? If this is not the right place to ask help with this problem, can someone point me in the right direction?
Thanks.
p.s. I almost forgot that I use Win7 64-bit and my range of cards include the GTX2xx, 5xx and 6xx line, and it doesn't matter which of these I try, they all crash with the new driver but work with any driver before 310.90

malexander
03-08-2013, 11:33 AM
Our users also experienced hangs and crashes when using 310+ on Windows 8, which we reported to Nvidia. They resolved the issue in the Quadro 311.15 driver, but the GEforce driver is still not patched, though a fix may be forthcoming in 319. In the meantime, we've advised Win8 users to use 306 or below.

aronsatie
03-08-2013, 04:20 PM
Our users also experienced hangs and crashes when using 310+ on Windows 8, which we reported to Nvidia. They resolved the issue in the Quadro 311.15 driver, but the GEforce driver is still not patched, though a fix may be forthcoming in 319. In the meantime, we've advised Win8 users to use 306 or below.

Did this happen only on Windows 8 but on Windows 7 and was it the 64-bit version? Thanks.

malexander
03-08-2013, 06:45 PM
Only happened on Windows 8 64b. Linux 64b and Windows 7 64b and Vista 64b were fine. We no longer support 32b OSes, so I'm not sure if those are affected or not.

aronsatie
03-09-2013, 12:21 AM
Only happened on Windows 8 64b. Linux 64b and Windows 7 64b and Vista 64b were fine. We no longer support 32b OSes, so I'm not sure if those are affected or not.

I support 32-bit any more either, but my OS is Win7. Can you tell me which version of OpenGL yours is based on and where can I report something like this to Nvidia?
Thanks.

malexander
03-09-2013, 08:55 AM
We're registered as a partner with Nvidia (https://partners.nvidia.com/Login.aspx), but there's also the developer zone which I believe has a forum (https://developer.nvidia.com/category/zone/game-graphics-development). Detailed, reproducible bug reports are the key to getting driver issues resolved.

Our app seemed to hang after creating/switching GL contexts a bunch of times. Eventually it'd be unable to make a context current. It didn't seem like the actual OpenGL code mattered, perhaps it was a WGL issue.

Aleksandar
03-09-2013, 02:09 PM
Our app seemed to hang after creating/switching GL contexts a bunch of times. Eventually it'd be unable to make a context current. It didn't seem like the actual OpenGL code mattered, perhaps it was a WGL issue.
May I ask why do you have to switch contexts?
Many years ago I used similar concept, making context current in each function call. But it is far less efficient (although much simpler) than having a dedicated drawing thread for each context.

aronsatie
03-09-2013, 02:46 PM
I still think the problem with these new drivers has something to do with the version of OpenGL. I still use 2.1, GLSL 1.2 based shaders and a single context used by a single thread. And the application (Win7 64-bit) crashes not once in a while or often, but every single time after I create a context, setup fbo and other stuff and rendering starts (even if there are no draw calls yet).
(BTW I registered on the nvidia developer's forum but I am yet to receive the confirmation email with the password.)

Aleksandar
03-09-2013, 03:24 PM
Could you just, for the sake of finding the source of the problem, switch to GL 4.1 and use debug_output to surgically precise find what exactly causes the problem?

aronsatie
03-10-2013, 12:42 AM
Could you just, for the sake of finding the source of the problem, switch to GL 4.1 and use debug_output to surgically precise find what exactly causes the problem?
I am not sure if I can do that. I use a few features like display lists that are deprecated and (I assume) have already been removed. I also use a few libraries that might be incompatible with 4.x now (glew, freeglut, glu). I tried to pinpoint where exactly does the application crash, but if I comment out that part, then it will be another.

Aleksandar
03-10-2013, 01:10 AM
You should try. It doesn't cost much. :)
Just create a compatibility/debug context and give it a try.
Compatibility profile should support all you have mentioned.

In the meantime, could you check whether your GL rendering context is valid and current at the moment crash happens.

aronsatie
05-06-2013, 12:27 AM
Thanks for all the tips. I finally had enough of insisting on older driver versions. Windows automatically updated my driver to 311 and I had to uninstall it every time I switched on. In the end I found out that the fault was mine. Sometimes the application tried to update a uniform that did not exist for the shader currently selected. Previous driver versions tolerated this, >=310.xx do not. It was much more difficult to find than to fix, so thankfully it is alright now. Thanks once again.

mhagain
05-06-2013, 05:07 AM
Thanks for all the tips. I finally had enough of insisting on older driver versions. Windows automatically updated my driver to 311 and I had to uninstall it every time I switched on. In the end I found out that the fault was mine. Sometimes the application tried to update a uniform that did not exist for the shader currently selected. Previous driver versions tolerated this, >=310.xx do not. It was much more difficult to find than to fix, so thankfully it is alright now. Thanks once again.

This is actually a driver bug; it shouldn't crash, it should just set an error: http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml


If location is a value other than
-1 and it does not represent a valid uniform variable location
in the current program object, an error will be generated, and
no changes will be made to the uniform variable storage of the
current program object. If location is
equal to -1, the data passed in will be silently ignored and the
specified uniform variable will not be changed.

thokra
05-06-2013, 11:24 AM
Windows automatically updated my driver to 311 and I had to uninstall it every time I switched on.

Ehm, yeah ... O_O

Or, you could switch to manual updates (i.e. be notified but install yourself) and just don't give a damn about what Windows tells you (don't know about Win8 though). You can also hide the update so it won't show up.

aronsatie
05-07-2013, 04:54 AM
Which is what I did in the end. Still not much fun, particularly when you have to ask your customers as well to switch off windows update.

aronsatie
05-07-2013, 04:58 AM
This is actually a driver bug; it shouldn't crash, it should just set an error: http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml

Thanks, good to know. It would be interesting to know how something like handling an error can vanish from one driver version to the next.

thokra
05-07-2013, 05:01 AM
to switch off windows update.

But you don't. You just move away from automatic updates.

mhagain
05-07-2013, 08:05 AM
But you don't. You just move away from automatic updates.

It's still something you can't tell customers to do. Customers hate being told to do this kind of thing - they may have their own requirements to have automatic updates enabled, and now your program has just conflicted with those requirements. So you've potentially lost a sale. Telling customers to switch off automatic updates is an overly-simplistic non-solution.