OpenGL wglMakeCurrent returns TRUE but seems to fail

This topic is 1065 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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

Share on other sites

I just want to say that what you're doing is like playing with fire: it's asking for trouble.

GL applications rarely stress this part of the driver (frequently switching a context between threads), so I wouldn't be surprised if there are driver bugs. Not to mention that there just could be a bug on your side (e.g. thread B calls wglMakeCurrent; then thread A calls wglMakeCurrent; then thread B performs an OpenGL call, which is now invalid)

Share on other sites

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!

Share on other sites

I just thought maybe someone has an idea what I could try to find the reason for this behavior.

Other than a race condition on your end or a driver bug, no, I have no idea.
You must try with different vendors to rule out driver bugs (e.g. try AMD, NVIDIA and Intel to check it bugs in all three vendors or at least two of them)

Share on other sites

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.

Share on other sites

Im not sure if two contexts can share the same control (the window you are displaying on), by the way

it switches wglMakeCurrent(HDC, HGLRC) and wglMakeCurrent(nullptr, nullptr)

thats wrong you define device contex and rendering context for both, not only for one

Edited by WiredCat

Share on other sites
The device context and render context must have the same pixel format.
Try to assure that they are both with the same format.

1. 1
2. 2
Rutin
25
3. 3
4. 4
5. 5

• 10
• 13
• 19
• 14
• 9
• Forum Statistics

• Total Topics
632942
• Total Posts
3009342
• Who's Online (See full list)

There are no registered users currently online

×