I know that开发者_如何学C sharing a single context between threads is bad news. I know that I can safely create and use a context with an offscreen framebuffer on a secondary thread when nothing is happening with GL on the main thread.
I haven't yet been able to find a definitive answer to the question of whether I can safely create two contexts on two different threads (say, a main thread drawing to the screen, and a secondary thread doing offscreen drawing work) and have them both making GL function calls simultaneously.
In other words, as long as the contexts are different, can two threads "share" the C API and thus the GPU? Or is that inherently something that is unshareable? Or is this implementation-specific?
Asking specifically for OpenGL ES on iOS, but it's probably a general GL question.
Yes, you need to use one context for each thread you want to use OpenGL with, also you can share objects between the contexts. This is the way to go :)
Option 1: If you don't use the context by two threads simultaneously, one context is enough.
Option 2: If you need to use OpenGL by several threads simultaneously, you need more than one context. Then, if the contexts share their Sharegroup, they share their OpenGL content like textures. This way you can load textures or do heavy framebuffer processing on a background thread.
Have a look at the last section about Sharegroups here: http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/WorkingwithOpenGLESContexts/WorkingwithOpenGLESContexts.html
Option 3: GLKit provides some built-in background processing, for example asynchronous texture loading via GLKTextureLoader
s - textureWithContentsOfFile
. I don't know all the options, but it definitely simplifies some of uses cases of asynchronous OpenGL.
精彩评论