NVidia 270.x+ tip/question - stack size

[Dark Photon]

A while back some of us were talking about problems we were having with the NVidia 270.x drivers (link: Problematic 270.61 driver). Been swamped with customer work, so had frozen on 260.19.44 since then, and just now beat my head against this to figure out what's going on.

This crash/instability issue correlates with the following:

1. Doing your GL calls (including creating a GL context) in a background pthread, AND
2. pthread stack size being 256KB.

Results in a crash deep down in the initial glXCreateContext*() or often in some startup GL FBO creation call.

Either crank up the stack size a ways (e.g. a couple MB), OR do your GL mucking in the foreground thread, and NVidia GL seems to avoid this crash and works well like 260.x did. Apparently, something changed recently (possibly in 270.x) that required more stack space in the GL thread.

So, questions:

• what are folks using for stack size on their GL background threads?
• And does NVidia have any guidance for the stack size to use? Didn't find anything in /usr/share/doc/NVIDIA_GLX-1.0/README.txt on this.

Thanks!

[malexander]

It seems that Nvidia has at least added a workaround for the issue in the beta 290.03 drivers:

Added support for limiting heap allocations in the OpenGL driver through the use of the __GL_HEAP_ALLOC_LIMIT environment variable. See the README for further details.

Unfortunately, it's a environment variable and not something you can set through an extension; but I suppose you could have a startup script set it for you before executing your app.

Full link

[Dark Photon]

It seems that Nvidia has at least added a workaround for the issue in the beta 290.03 drivers:

Added support for limiting heap allocations in the OpenGL driver through the use of the __GL_HEAP_ALLOC_LIMIT environment variable. See the README for further details.

Thanks for the pointer, but stack and heap are in distinctly different segments of memory.

[malexander]

Ah right -- computer term dyslexia, I guess Thinking about it a bit further, I would imagine it'd be pretty hard for them to limit stack usage, unless they allocate chunks off the stack via alloca(). Then they might be able to switch to malloc() if an environment variable was set.

In response to your question on pthread stack size, we use an 8MB stack for any "heavy" working threads and a 1MB stack for "light" monitoring threads. Haven't had any issues with driver versions 270, 275 or 280 with the 8MB stack size. We generally don't have too many heavy threads kicking about at once.

[Dark Photon]

In response to your question on pthread stack size, we use an 8MB stack for any "heavy" working threads and a 1MB stack for "light" monitoring threads. Haven't had any issues with driver versions 270, 275 or 280 with the 8MB stack size. We generally don't have too many heavy threads kicking about at once.

Interesting. Thanks!

Thinking about it a bit further, I would imagine it'd be pretty hard for them to limit stack usage...

Possibly, but should be a function of call depth and bytes call (args, auto locals, saved regs), so if NV determined a conservative max for each, that should be a good upper bound.