Taicoon
05-06-2010, 12:56 AM
I have an application which has a number of threads all working with the same context. Some threads create and stream video textures, some receive commands over network and deal with them and one is the main application calling other render commands and swapping.
Currently I am having a special class which lets threads aquire a context and later release it by using a mutex. This does sort of work, but it gives me quite a few locks here and there and I am tired of debugging it.
What would be "the right way" of dealing with this?
I see a few possible ways, none of which is truely like
1: wrap all opengl calls in methods which start with blocking on a mutex , aquiring a context and end by releasing it. Much like what I have now
2: invoke method calls on a single context owning thread which essentially makes the opengl part single threaded (ok, since I have no long running blocking opengl calls)
3: create a context for each thread and share their resources (textures). I have no experience with that.
Currently I am having a special class which lets threads aquire a context and later release it by using a mutex. This does sort of work, but it gives me quite a few locks here and there and I am tired of debugging it.
What would be "the right way" of dealing with this?
I see a few possible ways, none of which is truely like
1: wrap all opengl calls in methods which start with blocking on a mutex , aquiring a context and end by releasing it. Much like what I have now
2: invoke method calls on a single context owning thread which essentially makes the opengl part single threaded (ok, since I have no long running blocking opengl calls)
3: create a context for each thread and share their resources (textures). I have no experience with that.