OpenGL ES multithreading and EAGLSharegroup
发布日期:2021-10-24 16:04:24 浏览次数:1 分类:技术文章

本文共 3093 字,大约阅读时间需要 10 分钟。

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 contextcontextA. 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, andcontextA 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 BglFlush(); // 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 .

版权声明:本文为博主原创文章,未经博主允许不得转载。

转载于:https://www.cnblogs.com/zsw-1993/archive/2013/02/20/4880385.html

转载地址:https://blog.csdn.net/weixin_30802171/article/details/98174482 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:跟我一起写 Makefile
下一篇:objc_getAssociatedObject, objc_setAssociatedObject

发表评论

最新留言

能坚持,总会有不一样的收获!
[***.219.124.196]2024年03月08日 22时49分13秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章