We have an application that couples a CUDA simulation with geospatial rendering of the results in OpenGL. Due to the size of the data, we often reach the video memory limit, which is 2 GB for the GTX 680 cards we currently use. The major problem we have with this is that we have almost no possibility to react to this situation.
The system will run out of memory when resizing or creating a texture or buffer object, which we do fairly frequently. When running out of video memory, one of four things will happen:
- The OpenGL call reports GL_OUT_OF_MEMORY which we receive synchronously through the GL_KHR_debug callback. In this case, we can throw an exception and handle the situation in a satisfying way.
- The driver pops a message: “Request for more GPU memory than is available”, the application will crash hard without any way to safely exit with pending changes etc.
- Nothing happens at first, the allocation fails silently and the context dies. Next time any object of the context is used, arbitrary OpenGL error messages are reported, such as framebuffer incomplete, texture has size 0 etc.
- The application freezes at the next OpenGL synchronization point such as glFinish or glMapBuffer.
The very, very bad thing is that option 1 will almost never occur. Unfortunately, the events here are sorted by increasing probability, with options 2 and 4 being a hard crash and an absolute no-go for an application.
Why is the handling of out of memory errors so inconsistent with the Nvidia driver? The driver must not overrule the OpenGL error reporting to instantly kill the entire application. And, well, considering events 3 and 4, the GL_OUT_OF_MEMORY error should be thrown at some point. What good is the error reporting callback if it dies with/before the context?
We use recent drivers (361.75) on Windows 8.1 Professional. The OpenGL context we request is 4.4 Core Profile, if that makes any difference.