just a basic question: is there any way to share a single opengl context between two threads besides using os-dependant functions (e.g. aglCreateContext on mac osx)? if there is, does it work for generating texture objects too? thanks in advance

Quote:Original post by ze moo
just a basic question:

is there any way to share a single opengl context between two threads besides
using os-dependant functions (e.g. aglCreateContext on mac osx)?
if there is, does it work for generating texture objects too?

thanks in advance

Not that I'm aware of. Windowing libraries such as SDL may have (I've never used it so I'm not sure) a wrapper function that simply calls the appropriate OS-dependent function for making the context current. There shouldn't be any problem with things like textures because they are specific to a context, so as long as that context is the current one you can use its textures (no matter which thread it's being used in).

There are ways to share textures and the like between contexts as well (wglShareLists on Windows) but they aren't needed if you're only using one context anyway.

unluckily sdl doesn't provide this kind of functionality (or i haven't found it yet)
calling any GL function outside the main thread owning the context won't work (as i expected) :(

Quote:Original post by ze moo
unluckily sdl doesn't provide this kind of functionality (or i haven't found it yet)
calling any GL function outside the main thread owning the context won't work (as i expected) :(

Yeah, the thread has to have a current rendering context for any rendering to work. Perhaps you can make your own function that wraps the different OS-dependent calls. For Windows, the function you need is wglMakeCurrent. I'm pretty sure you need to set the context so that it's not current before setting it current in another thread. Again for Windows, that is done by calling wglMakeCurrent with hglrc set to NULL.

With all that said, it's usually best to avoid rendering with the same context from multiple threads because the context switching is pretty expensive. So unless you really need to render from multiple threads, I suggest doing all your OpenGL calls in one thread and doing other things (like file-loading for example) in different threads.

Good luck!

i'm currently avoiding this by "dumping" the neccessary information to create
the texture object to the main rendering thread.
if the rendering thread happens to pass by and the semaphore is not locked, it's
"transferring" the data to gl (or dismisses the texture)

but somehow the whole thing feels a little bit shabby...

thanks anyway :)