I have a main thread with a render context and a worker thread without any context.
At some point the worker should create a context and use it to generate textures which are shared with the main threads context.
I have successfully created the new context in the worker thread, but when trying to share lists I have run into a problem.
In order for wglShareLists to work, the main thread must make its context non current since sharing does not work on current contexts as described in
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=167860
The worker thread should then somehow “ask” the main thread to give up on its context and pause for a while untill the sharing is complete and then make its context current again. That seems silly… should I really include a test for “someone wants me to let go of my context” in my main threads loop???
How should I proceed?
you can create the context for your worker at the same time as you created the main context. you then make it current in the worker thread once it is created.
I cannot precreate the context for the workr. It is the obvious solution, but not. I would then have to create a possibly large number of contexts in a pool which new workers could grab along the way.
I should probably have made the dynamic creation and deletion of my worker threads(s) more clear. Sorry about that.
should I really include a test for “someone wants me to let go of my context” in my main threads loop???
Yes, with criticalsections or mutexes/whatever.
I am asking about theese things not because I am unable to hack a solution together, but because I am new to opengl and still do not quite know what the API supports in itself and what needs to be made to fit.
Let me be sure I understand the method then…
I have a main thread rendering with a context.
I spawn a worker thread (a worker object actually) which creates its own context. The worker then signals the renderer to release its context and wait for a shared mutex to become free again. The worker naturally also has to wait for a mutex signal indicating that the renderer has actually let go of the context. While the context is free, the worker shares lists with it and then signals the renderer to grab its context again and keep on rendering.
Is the the proper opengl solution?
It seems doable. Including a test for workers wanting to share lists and pausing briefly is acceptable. If this is done every frame, then the workers will not have to wait for long either.
The next question is then is there is a (low) limit on the number of contexts one can create. Would it be an (opengl) problem if I had 500, just to pick a number, contexts, one bound to each of 500 worker threads? I do realize that thread switching has its overhead, but is there a limit on the number of contexts?
I do not think it is a wise idea to constantly create and destroy rendercontexts, consider them as precious and heavy things. Why not have a small pool of workerthread-objects that you create once and then re-use whenever you want to assign them a new job?
Additionally, you could create the rendercontext in the main thread and pass it into the construction of the worker thread. This way the context is fully existant before the worker thread is spawned - no complicated messaging needed anymore.
Would it be an (opengl) problem if I had 500, just to pick a number, contexts, one bound to each of 500 worker threads?
That is totally insane. You only have one or two gfx card(s) and maybe up to 8 CPUs… how do you expect 500 workers to do anything useful except stepping on each others feet?