Please bear with me if this sounds like an overly obscure problem. I’m hoping that understanding what’s happening in this case will help us solve a more serious problem we’re seeing where our OpenGL application will die on pretty much any Nvidia GPU after creating/closing 60-100 MFC windows. At this point wglMakeCurrent will start failing and we start getting sporadic GL_OUT_OF_MEMORY errors. We haven’t been able to reproduce this behavior in a stand-alone test case, but we have been able to reproduce the following strange behavior.
We have a test program that does the following in a loop:
- Create a Win32 window
- On a worker thread create a WGL context, make it current, do a clear and swap buffers, then delete the context.
- When the worker thread returns, the main thread deletes the window and we loop back to 1.
When running this test on a laptop w/Quadro K2000M driver version 332.76 the memory usage for the application rises to about 1 GB after 30-50 iterations. At that point it seems to stabilize and stop increasing. If the window creation/destruction is also moved to the thread function then we don’t see this huge memory footprint (which is what we see on AMD and Intel regardless of where the window creation happens).
The test program (VS 2012 project) can be downloaded here https://dl.dropboxusercontent.com/u/69927239/nvidia_leak.zip
In our real application we similarly create windows on the main thread, and contexts on worker thread (each window has an associated worker thread that is where all OpenGL calls for that context are made). When we force everything to happen on the main thread we seem to be able to create more windows before things start failing but eventually we get to the same state where nothing works anymore. This has been verified on a GTX 760 w/driver 335.23. Both machines are running Windows 8 64 bit.