Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: NVidia driver crash with FBO

  1. #1
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    81

    NVidia driver crash with FBO

    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

    Code :
    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.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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().

  3. #3
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264
    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.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,191
    Quote Originally Posted by Devdept2 View Post
    ...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.

  5. #5
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    81
    Quote Originally Posted by thokra View Post
    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?

  6. #6
    Intern Contributor
    Join Date
    Nov 2010
    Posts
    81
    Quote Originally Posted by Dark Photon View Post
    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...

  7. #7
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by Devdept2
    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.

    Quote Originally Posted by V-man
    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.

  8. #8
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264
    Quote Originally Posted by Devdept2 View Post
    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.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  9. #9
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,191
    Quote Originally Posted by Devdept2 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •