If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Hello, I am experimenting with the thread sample provided and I ran into an issue that I can't seem to figure out. Basically the creation of an openGL display list executed in the thread entry code is invalid, issuing a generic "invalid OpenGL error 1282".
Here is how I modified the code to test this:
To note that the display list generates (and display successfully) if I create it for example in the MyThread *MyFrame::CreateThread(int ID) routine.
Any idea of what could be wrong? Thanks
Right so best course of action is to move to VBO so that I can run threads to prepare and collect vertex data and later l, when threads have ran off, or bind the buffer?
OpenGL was not designed with multithread on sight. Internally the hardware will split the task into several "paths". But externally only a thread can use gl-commands in a current gl-context
So, if you want your thread to execute some gl-stuff then call wxGLCanvas::SetCurrent() or wxGLContext::SetCurrent() from within the thread.
But this is not enough. If thread A calls SetCurrent and start sending gl-commands to the GPU and in the while thread B does the same, then some commands in thread A are sent with a not-current context. Disaster. You must prevent it with some condition/semafore/atomic/whatever way.
A way to avoid the crash is using shared contexts. You set current context 1 from thread A, and shared context 2 from thread B. Good news is that shared context share most data (buffers, textures, etc).
A good advise is to use only one context in one thread (normally the main one). You can have several threads preparing data, and let the main thread to update it to the GPU and use the rest of gl-commands.
Manolo wrote:OpenGL was not designed with multithread on sight. Internally the hardware will split the task into several "paths". But externally only a thread can use gl-commands in a current gl-context
So, if you want your thread to execute some gl-stuff then call wxGLCanvas::SetCurrent() or wxGLContext::SetCurrent() from within the thread.
But this is not enough. If thread A calls SetCurrent and start sending gl-commands to the GPU and in the while thread B does the same, then some commands in thread A are sent with a not-current context. Disaster. You must prevent it with some condition/semafore/atomic/whatever way.
A way to avoid the crash is using shared contexts. You set current context 1 from thread A, and shared context 2 from thread B. Good news is that shared context share most data (buffers, textures, etc).
A good advise is to use only one context in one thread (normally the main one). You can have several threads preparing data, and let the main thread to update it to the GPU and use the rest of gl-commands.
Thank you very much for the detailed explanation and suggestion, yes I will go with your last advise, prepare data in the threads and then feed that to the GPU at once from the main thread.