Re: multi-threaded IOS OpenGL

Ben, we devoted half of a WWDC session (in 2011? Best Practices for OpenGL ES on iOS?) to asynchronous resource loading on iOS. You should have access to the video.
On Dec 5, 2012, at 11:59 AM, Ben Supnik <email@hidden> wrote:
> Hi Ben,
>
> Okay - first the short part: using a share group does exactly what I want, is advertised as having the same functionality more or less as the desktop GL, and I have confirmed it works on an ipad 2.
>
> (A long time ago we were advised by an Apple employee that context sharing was not possible; based on the IOS version dates on the APIs, my best guess is that he misunderstood what we were trying to do. I have been coding incorrectly on that advice for a while now, but it was moot since IOS devices for our first-gen product were single-core.)
>
> To answer the other questions, for what it's worth, there's a few reasons why we are ignoring GCD:
>
> 1. Our code base is cross-platform all over the place including Android and Windows. In theory we could compile libgcd everywhere but...
>
> 2. Our threading code predates GCD, so we have our 'rolled our own' thread-pool that already works and...
>
> 3. Our task chunks are big enough that the lower overhead in GCD vs. our code isn't useful and...
>
> 4. We really want to run the gl uploads _on_ other threads, so that we aren't interrupting the main rendering loop. I don't know of a way to efficiently set up async GL contexts on GCD without a lot of overhead because we never know _which_ GCD thread is going to call us, or whether GCD is going to make more threads because it can. I think by the time we solve this problem, we will have destroyed any perf advantage CD has over our home-rolled gunk.
>
> Why do we want to do the GL work on async threads?
>
> - To reduce latency - the "compute on worker, call GL on main thread" idiom introduces inter-thread latency.
> - In this model, the main thread either has to take very small sips of GL work or the main render loop stutters. The result can be a back-log of worker thread work waiting for the main thread to get through its "chore" list slowly, particularly if the CPU and GL calls are highly interleaved (e.g. build a DL, upload it, build a DL, upload it - but this interleaving keeps memory from ballooning).
> - If the device is multi-core, the driver work for the GL uploads, etc. can be on a worker thread, which is a win.
>
> If there's an executive summary here, it's that being able to TRULY run loader tasks 100% on a single worker thread is both simpler code and can provide better concurrency, so that is our preferred design everywhere.
>
> cheers
> ben
>
>
> On 12/5/12 12:51 PM, Ben Syverson wrote:
>> Ben,
>>
>> I think if you use a separate thread, it needs to do *all* of the GL
>> calls for that context. For example, you can't delegate just texture
>> uploading to a separate thread. Since GL is a state machine, it makes
>> sense that it's unsafe for threading.
>>
>> Any reason why your async work can't be handled by GCD? It appears that
>> you aren't restricted to the main queue (but you are restricted from
>> running queues concurrently). But you'd get the benefit of asynchronous
>> execution without the headache of threads.
>>
>> Of course you've read this, but for others who may stumble upon this thread:
>> http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ConcurrencyandOpenGLES/ConcurrencyandOpenGLES.html
>>
>> Ben
>>
>> On Dec 5, 2012, at 11:05 , Ben Supnik <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>>> Hi Ben,
>>>
>>> Thanks, but we want to push it a step further - actually _doing_ the
>>> GL call on the worker thread.
>>>
>>> Our desktop code used to be structured like your code, albeit without
>>> GCD, a long time ago when we first started 'threading'...since then we
>>> moved to an entirely async process. We simply considered that process
>>> non-portable on the iphone in older IOS versions.
>>>
>>> cheers
>>> Ben
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Mac-opengl mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
> --
> Scenery Home Page: http://scenery.x-plane.com/
> Scenery blog: http://www.x-plane.com/blog/
> Plugin SDK: http://www.xsquawkbox.net/xpsdk/
> X-Plane Wiki: http://wiki.x-plane.com/
> Scenery mailing list: email@hidden
> Developer mailing list: email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Mac-opengl mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

Apple Footer

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.
Apple