NVidia driver crash with FBO

[Devdept2]

Hi,

I have an NVidia Geforce 8600M GS with driver 301.42.

I get a crash of the openGL driver in my application (Win 7 pops up a dialog saying "the hardware configuration does not have the minimum specifications needed to run the application. The application must close. Error code 6".

The crash happens when I call

int status = gl.CheckFramebufferStatusEXT(gl.FRAMEBUFFER_EXT);

after that I have created 2 FBO with size 4096x 4096, renderbuffer of type DEPTH_COMPONENT and with depth texture attached.

The gl.MAX_RENDERBUFFER_SIZE_EXT gives 8192.

Why is the driver crashing so badly?
Am i using too much video ram?

The previous driver that I had (285.62) crashed the same.

[thokra]

What language are you doing this in? Why are you using the EXT versions of the functions? They have been core for a long time now. You should just use glCheckFramebufferStatus().

[V-man]

Are you allocating other resources before that FBO? Any VBO, any textures?
Try to create a smaller buffer if you think it is a memory problem. 512 x 512.

Obviously a GL driver should not crash and you should get a gl error such as GL_OUT_OF_MEMORY
http://www.opengl.org/wiki/GL_Error_Codes

A crash means bad programming.

[Dark Photon]

...NVidia Geforce 8600M GS ...I get a crash of the openGL driver in my application (Win 7..."the hardware configuration does not have the minimum specifications needed to run the application..."....2 FBO with size 4096x 4096, renderbuffer of type DEPTH_COMPONENT and with depth texture attached. ... Why is the driver crashing so badly? Am i using too much video ram?

I can tell you one case where I've seen something very similar if not identical with the NVidia driver: Insufficient stack space.

App was creating a GL context in a background pthread created with a stack size of 256KB (legacy size set ages ago), resulting in core dumps on startup, usually in some FBO setup call. NVidia drivers circa 280.x or so started needing more stack space, enough to break the camel's back. Bumped the stack size to 8MB and problem was gone.

A valgrind looking for memory problems actually quit said that it was out of stack size, but assumed that was due to the extra stack space imposed by profiling so it didn't "click" immediately that that might be the problem with the original uninstrumented app code. Sure enough, that was it.

[Devdept2]

What language are you doing this in? Why are you using the EXT versions of the functions? They have been core for a long time now. You should just use glCheckFramebufferStatus().

I'm in C# and we wrapped all gl calls, that's why there's "gl." before each function name.

Does it make any difference calling the "Ext" method or the core one?

[Devdept2]

I can tell you one case where I've seen something very similar if not identical with the NVidia driver: Insufficient stack space.

App was creating a GL context in a background pthread created with a stack size of 256KB (legacy size set ages ago), resulting in core dumps on startup, usually in some FBO setup call. NVidia drivers circa 280.x or so started needing more stack space, enough to break the camel's back. Bumped the stack size to 8MB and problem was gone.

A valgrind looking for memory problems actually quit said that it was out of stack size, but assumed that was due to the extra stack space imposed by profiling so it didn't "click" immediately that that might be the problem with the original uninstrumented app code. Sure enough, that was it.

Hi,

I'm not really sure I understand
Supposing it's a problem related to stack size, how do you "bump" it?
I changed my code so I avoid creating the second FBO, but I'm a little perplexed since I didn't really "fix" the problem...

[thokra]

Does it make any difference calling the "Ext" method or the core one?

It can make a difference. ARB extensions (the ones promoted to core - otherwise they don't loose the ARB suffix) aren't necessarily equal to EXT extensions so they might behave a little differently. Aside, from a coding standpoint not mixing EXTs/ARBs which have become core and other core functions is simply cleaner.

A crash means bad programming.

If the thread starter were programming in C/C++ using some library which in turn uses {wgl/glX}GetProcAddress I'd check for function pointer validity first. However, I don't know how the C# binding handles it.

Up until now I never saw a crash on the GF8600M GS and I used it alot myself.

[V-man]

Hi,

I'm not really sure I understand
Supposing it's a problem related to stack size, how do you "bump" it?
I changed my code so I avoid creating the second FBO, but I'm a little perplexed since I didn't really "fix" the problem...

I doubt that it is a stack size problem. Dark Photon was talking about an old app that created a thread with a stack size of 256 K, a ridiculously small size. The main thread, IIRC, gets 1 MB by default. That is a decent amount for everything and I'm sure nVidia is aware of it.
To increase the stack size of a c# program, I don't know. Try some weeb searches or ask some Microsoft Visual c# people. If you are using some other IDE, then you would just track down some forum specific to that.

I know that for VC++, you would do it with your linker, LINK.EXE /STACK:1000000.

[Dark Photon]

Supposing it's a problem related to stack size, how do you "bump" it?
I changed my code so I avoid creating the second FBO, but I'm a little perplexed since I didn't really "fix" the problem...

With C/C++ and pthreads, pthread_create()'s 2nd arg is pthread_attr_t which contains thread creation attributes. One of these is stack size, which you set via pthread_attr_setstacksize().

...with C#? No clue.

Would run your app under a memory profiler and/or debugger to see if you can get any clues as to why its core dumping. Could be any one of a number of things, including mem corruption.