Hello everyone,
I have a strange problem. I have an application (3d viewer) which uses OpenGl in 2 threads but has only 1 opengl context. It switches the context between the threads via wglMakeCurrent(HDC, HGLRC) and wglMakeCurrent(nullptr, nullptr). In general this works. But with one special dataset in a special situation wglMakeCurrent(HDC, HGLRC) returns TRUE but after that every OpenGL call is ignored (even the ones directly after wglMakeCurrent).
- GetLastError() returns 0 before and after the call.

- OpenGLDebug context does not give a hint (which is expected since the context seems to be out of order).
- GetCurrentContext returns expected values.
- glGetError returns 0

For debug purposes I do

int i = 0;
glGetIntegerv(GL_MAX_DRAW_BUFFERS, &i);
ASSERT(i != 0);

after the context is out of order this assert fails.
I also logged the context switches and they seem to be correct, the context is bound to zero or one thread (which will do the next calls to OpenGL) at a time.
I have no clue what I could try next, what could be the reason for this behavior.
I use a Quadro K2000 with a 354.13 driver.

Every hint is appreciated.

Thanks

Marc

Thanks for the reply and I am aware that this design is not optimal. I maintain the the OpenGL part of the application, in general the context switches work fine (at least 20 persons use the software on a daily base).
OpenGL parts are saved with locks, so your example should not be possible. But I understand what you are saying and I think you are right. I would love to understand why it only happens in the one (relatively big) dataset, that might be a hint that it might be something on myside. And what I really dont understand is, that wglMakeCurrent returns TRUE and directly afterwards the OpenGL call is ignored, and this scope is completely saved with locks.
But yeah I am aware that this is a very special case and hard? to say something with out in depth analyzing the code. I just thought maybe someone has an idea what I could try to find the reason for this behavior.
thanks again!

Okay, I could figure out that this happens if the ram and the video ram are both full and then a context switch happens. If everything runs in one thread its slow but OpenGL reacts fine. I think this is a driver "bug" more or less ( there should be some kind of error/exception what ever in my opinion), either the memory managment in the threading context or the context switch are involved too.
I dont have a solution to this, but maybe if someone has the same problem this helps a bit.