All right, here goes the (evil) question: what is safe to do in openGL via threads and what is not? I ask becuase straight from Apple we have: "The Mac OS X OpenGL implementation is not thread-safe but you can still split your processing onto multiple threads. It is extremely important for developers not to issue OpenGL commands for a single context from multiple threads without proper thread synchronization." from http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html maybe my question is a touch too broad... lets start with a (few) examples: 1) loading geomerty (i.e. VBO) and texture data to the card. Can this be done in a thread if the textures and geomerty being loaded are not at all used by any other threads while the loading thread is alive? my concern is that the driver may have some funky logic in it to decide when to send the data to the card, so if you are in thread A drawing stuff (but not using the VBO's and textures affected by thread B) and thread B starts it's loading thing and the driver may decided to move some stuff from card to memory or vica-versa which thread A is playing with, and then thread A might get trashed (i.e. a draw command is issues by thread A when the stuff is (say) in card memory, but when the card actaully does the command it has gotten moved back to system memory) Typical example of doing this is "nicer loading screens" and possible some "load stuff while playing scenarios" 2) FBO's and a simple windowing system: idea: each window renders to a texture .. now admittedly a fixed window may play with the openGL stte alot, so I am not saying do the drawing of each window in it's own thread, but, for each windows there is a Do() and Draw() function. The Do() function does stuff that _should_ not affect the openGL state that touches other windows, i.e. it can do things like change VBOs ann textures it owns, but it does not do any openGL state stuff (i.e. drawing, glMatrix*, ect). So the windowing system does the Do() in threads but the Draw()'s one at a time... would that be safe at all even? Best Regards -kRogue

The long and short of the story is, don't make gl* calls, wgl* calls, glx* calls, or anything else of the sort from more than one thread. It doesn't matter what the usage patterns are. Just don't do it.

so, therefore, the idea of doing this with threads is just begging for trouble:

threadA:
Draw a bar via openGL of % stuff loaded.

threadB:
actually load the stuff from disk and put then into openGL

or what I'd really like to do:

while game is running:
threadA:
the game, if a needed resource is not loaded then pause game and wait.

threadB:
checks if there are resources needed now or soon that have not been loaded yet, and loads them to openGL,

so this would be bad ;(

but this should be ok then:
threadA:
conceptionally owns the openGL

threadB:
checks if there are resources needed now or soon that have not been loaded yet, and loads them to memory, when a resource is ready in memory "send a message to threadA" saying to move the data from memory to openGL...