Threading configuration

[nathan ramsey]

Is there any documentation on the threading configuration set up by Apportable? E.g. does the iOS main thread equate to the Android UI thread?

I am trying to cross-compile an iOS based OpenGL library which renders from background threads, but running up against EGL context constraints. I am wondering, however, if I can just treat the iOS main thread *as* a background thread, if perhaps the Android UI thread is a separate thread. I am not sure though. On what thread with the EGL surface be created when using CAEAGLLayer? Related SO question of mine here: http://stackoverflow.com/questions/18990366/apportable-how-do-i-run-opengl-on-a-background-thread

[Philippe Hausler]

Our threading setup is a bit non-standard to the common Android threading model. This is mainly due to the fact that iOS runs OpenGL in it's main thread. The thread that your application is started on is the same thread that the initial OpenGL surface is created on. The interesting ramification to this is that our Android based views are created and managed in the GL thread as well (by some clever manipulations of the Looper/MessageQueue and Dialog constructs). As long as the first OpenGL context that you reference in Objective-C is on the main thread; most things for shared contexts should work as expected. However if this is not the case things could devolve very quickly. Ideally you should create shared contexts to swap to background threads based off of the primary context created from the main thread.

tl;dr:

Create the CAEAGLLayer and EAGLContext on the main thread

Create shared contexts to be used for background threads via the share group markers from the primary context

make those shared contexts current on the background threads

be VERY careful about using libdispatch and contexts (ideally you should use the NSThread methods for running things on the main thread)

On Tuesday, September 24, 2013 at 12:36 PM, nathan ramsey wrote:

Is there any documentation on the threading configuration set up by Apportable? E.g. does the iOS main thread equate to the Android UI thread?

I am trying to cross-compile an iOS based OpenGL library which renders from background threads, but running up against EGL context constraints. I am wondering, however, if I can just treat the iOS main thread *as* a background thread, if perhaps the Android UI thread is a separate thread. I am not sure though. On what thread with the EGL surface be created when using CAEAGLLayer? Related SO question of mine here: http://stackoverflow.com/questions/18990366/apportable-how-do-i-run-opengl-on-a-background-thread

--
You received this message because you are subscribed to the Google Groups "Apportable discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apportable-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[nathan ramsey]

If I create a CAEAGLContext on the main iOS thread, then create a share context on a background thread using the shareContext: argument, would I be able to use the CAEAGLLayer created on the main iOS thread from the background thread? Maybe just don't bind it to a buffer in the main thread's context?

To unsubscribe from this group and stop receiving emails from it, send an email to apportable-discuss+unsub...@googlegroups.com.

[Philippe Hausler]

That sounds reasonable, however without some experimentation I could not say for sure. Just keep in mind the presentRenderbuffer: call must be invoked from the main thread: (under the hood this invokes eglSwapBuffers which requires the primary context bound to the surface to work.

To unsubscribe from this group and stop receiving emails from it, send an email to apportable-disc...@googlegroups.com.

[nathan ramsey]

As defined in section 2.4 of the EGL spec, "OpenGL ES contexts may share texture objects, shader and program objects, and vertex buffer objects." That does not include render buffers, AFAIK.

So I think that I wouldn't be able to call presentRenderBuffer from the main thread's context (because it won't share the bg thread's render buffer.) I'm starting to think that I have to alter the library I'm trying to port to render into a texture on the BG thread, instead of rendering into a render buffer.

[nathan ramsey]

be VERY careful about using libdispatch and contexts (ideally you should use the NSThread methods for running things on the main thread)

Can you elaborate on this? Calling dispatch_async(dispatch_get_main_queue(), ...) should post a block back to the main iOS thread (== the Android GL thread), what kinds of problems are you hinting at?

I have a two-context, two-thread (main and bg) version of the EAGLView sample working on iOS, which renders to a texture in the BG thread and then renders the texture to a render buffer (backed by the EAGLDrawable layer) in the main thread. Works on iOS but I am seeing an error from EGL:

09-27 12:03:27.477  12407-12452/com.apportable.Spin I/NSLog﹕ initing background renderer
09-27 12:03:27.477  12407-12452/com.apportable.Spin E/libEGL﹕ validate_display:251 error 3008 (EGL_BAD_DISPLAY)
09-27 12:03:27.477  12407-12452/com.apportable.Spin I/NSLog﹕ renderer: <ES2Renderer:0x748fc080>
09-27 12:03:27.487  12407-12439/com.apportable.Spin W/HardwareRenderer﹕ Attempting to initialize hardware acceleration outside of the main thread, aborting
09-27 12:03:27.527  12407-12452/com.apportable.Spin A/libc﹕ /Users/nathan/iphone-code/apportable/Spin/Tectonic/EAGL/Classes/ES2Renderer.m:412: __31-[ES2Renderer resizeFromLayer:]_block_invoke: assertion "glCheckFramebufferStatus(GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE" failed

(More complete ADB crash log here: https://gist.github.com/nmr8acme/6733850) 

[Philippe Hausler]

https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/c/func/dispatch_sync

note the comment: "As an optimization, this function invokes the block on the current thread when possible."

This applies to running on Android as well (since we use Apple's open source libdispatch). So dispatching to a queue on both iOS and Android via Apportable will potentially not be on the thread you think it is on; whereas using NSThread to perform a selector on a given thread will run on the thread you expect.

[nathan ramsey]

I've been learning more about EAGL and EGL and I have a concern about my current approach (two EAGLContexts on two separate threads.)

EAGLContexts are linked by a context's sharegroup property, and EGL contexts are linked by another EGL context.

My concern is that the EAGLContext <-> EGL context translation layer doesn't translate that particular aspect of the mechanism.

When I initialize an EAGLContext I see non-null sharegroups on iOS, but on Android I see null sharegroups. That leads me to suspect that the context sharing system isn't translated.

Two questions:

- Should my EAGLContexts sharegroup property be null when run on Android? / Is the sharegroup property supposed to work?

- Is the code for the EAGLContext <-> EGL context translation layer open source, or is that part of your secret sauce?

[nathan ramsey]

I'm guessing that the EGL <-> EAGL binding is closed source? And it doesn't translate sharegroups into shared contexts?

[Philippe Hausler]

The share groups and contexts do translate. For example: we have worked with many apps that load textures in the background using a shared context. That being said there are some minor requirements that we have in order to make the EAGLContext concept to work properly: #1) the primary context should be created on the main thread (which is VERY common usage) and #2 presenting render buffers needs to occur on the main thread (iirc IOS technically has this requirement as well) and #3) when background threads make contexts current they should do this in a manner that is safe for thread local storage (e.g. using performSelectorOnThread) doing it else wise can create problems for certain devices like the Nexus 7 is susceptible to context problems. But other than those minor restrictions it works very much like the way iOS handles EAGLContexts.

On Tuesday, October 1, 2013 at 10:04 AM, nathan ramsey wrote:

I'm guessing that the EGL <-> EAGL binding is closed source? And it doesn't translate sharegroups into shared contexts?

--