OpenGL ES multithreading and EAGLSharegroup

OpenGL ES multithreading and EAGLSharegroup

http://developer.apple.com/library/ios/#qa/qa1612/_index.html

Technical Q&A QA1612

OpenGL ES multithreading and EAGLSharegroup

Q:  In my multithreading OpenGL ES application, I load textures (or vertices) on a secondary thread then draw them onto screen on the main thread. Occasionally I see blank images or application freezes. What could be causing this?

A: In my multithreading OpenGL ES application, I load textures (or vertices) on a secondary thread then draw them onto screen on the main thread. Occasionally I see blank images or application freezes. What could be causing this?

It is very likely that the main and background threads are accessing the same OpenGL ES context simultaneously.

OpenGL ES commands for a specific context are not reentrant. You should never have more than one thread accessing a single context at the same time. It is highly recommended that you use only one thread per context.

Listing 1 demonstrates how to create and make current a context contextB using the sharegroup property (an EAGLSharegroup object) obtained from another already-allocated context contextA. Such contexts that belong to the same sharegroup can share resources, for example, textures, FBOs, etc. So you may use contextB on the secondary thread to create textures, and contextA on the main thread to draw the textures onto screen.

Listing 1  Creating a context belonging to the same sharegroup

contextB = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1      
                             sharegroup:contextA.sharegroup]; 
if (!contextB || ![EAGLContext setCurrentContext:contextB]) 
{       
  //  Handle errors here 
}

 

Important: The only way to get a valid EAGLSharegroup object is to query it from an existing EAGLContext object. Any other method, such as explicitly creating it, will result in crashes or undefined behavior.

When you want to modify a resource on one context, you must first make sure it is not currently in use on another, even if you are accessing them from different threads. Once you modify it, its state is undefined until flushing and binding the object have been completed. You should never use an undefined object, whether you access it from a different context or not.

Take a texture as an example. Listing 2 shows the correct way to deal with multiple contexts. Any other ordering will not ensure consistent and correct behavior. It may result in data corruption, leaks, or crashes otherwise.

Listing 2  Modifying a texture on context B prior to using it on context A

//  1. Ensure context A is not bound to the texture
 [EAGLContext setCurrentContext:contextA];
 glBindTexture(GL_TEXTURE_2D, 0);  

//  2. Call flush on context A  
glFlush();   

//  3. Modify the texture on context B 
[EAGLContext setCurrentContext:contextB]; 
glBindTexture(GL_TEXTURE_2D, texId); 

  //
 Modify the texture data here
  //

//  4. Call flush on context B 
glFlush();  
 
//  5. Rebind the texture on context A 
[EAGLContext setCurrentContext:contextA];
 glBindTexture(GL_TEXTURE_2D, texId); 

//  6. Use the texture as normal on context A

 

For more information on the EAGLContext/-initWithAPI:sharegroup: API and the sharegroup property, see the EAGLContext Class Reference.