Michael Leahy spoke on AnDevCon’13 about OpenCL on Android. Enjoy the overview!
Subjects (globally):
- What is OpenCL
- 13 dwarfs
- RenderScript
- Demo
Mr.Leahy is quite critical about Google’s recent decisions to try to block OpenCL in favour of their own proprietary RenderScript Compute (now mostly referred to as just “RenderScript” as they failed on pushing twin “RenderScript Graphics”, now replaced with OpenGL).
Around March ’13 I submitted a proposal to speak about OpenCL on Android at AnDevCon in November shortly after the “hidden” OpenCL driver was found on the N4 / N10. This was the first time I covered this material, so I didn’t have a complete idea on how long it would take, but the AnDevCon limit was ~70 mins. This talk was supposed to be 50 minutes, but I spoke for 80 minutes. Since this was the last presentation of the conference and those in attendance were interested enough in the material I was lucky to captivate the audience that long!
I was a little concerned about taking a critical opinion toward Google given how many folks think they can create nothing but gold. Afterward I recall some folks from the audience mentioning I bashed Google a bit, but this really is justified in the case of suppression of OpenCL, a widely supported open standard, on Android. In particular last week I eventually got into a little discussion on G+ with Stephen Hines of the Renderscript team who is behind most of the FUD being publicly spread by Google regarding OpenCL. One can see that this misinformation continues to be spread toward the end of this recent G+ post where he commented and then failed to follow up after I posted my perspective: https://plus.google.com/+MichaelLeahy/posts/2p9msM8qzJm
And that’s how I got in contact with Micheal: we both are irritated by Google’s actions against our favourite open standards. Microsoft has long learned that you should not block, only favour. But Google lacks the experience and believes they’re above the rules of survival.
Apparently he can dish out FUD, but can’t be bothered to answer challenges to the misinformation presented. Mr. Hines is also the one behind shutting down commentary on the Android issue tracker regarding the larger developer communities ability to express their interest in OpenCL on Android.
Regarding a correction. At the time of the presentation given the information at the time I mentioned that Renderscript is using OpenCL for GPU compute aspects. This was true for the Nexus 4 and 10 for Android 4.2 and likely 4.3; in particular the Nexus 10 using the Mali GPU from Arm. The N4 & N10 were initially using OpenCL for GPU compute aspects for Renderscript. Since then Google has been getting various GPU manufacturers to make a Renderscript driver that doesn’t utilize OpenCL for GPU compute aspects.
I hope you like the video and also understand why it remains important we keep the discussion on Google + OpenCL active. We must remain focused on the long-term and not simply accept on what others decide for us.
Vincent thanks for the nod!
A few quick points. You mentioned above: “as they failed on pushing twin “RenderScript Graphics”, now replaced with OpenGL”
OpenGL ES 1.x was always available on Android since version 1.0 and I started porting my J2SE desktop Java framework + OpenGL work from day one when the G1 hit my hands in Oct ’08.
The first OpenGL ES 2.x device was the original Droid released ~Nov ’09. Back then one had to create their own Java binding to get access to it and this is what the libgdx creator did and it was quite handy. An example of Google messing up a Java binding which is also a good indication of why it’s a good thing for Google just to get out of the way when it comes to managing a potential OpenCL Java binding is that the “official” OpenGL ES 2.x Java binding released with Android 2.2 was flawed because it wasn’t tested and the automatic binding generator apparently used didn’t properly associate some of the finer Java NIO buffer details in method signatures thus limiting dynamic VBO abilities. This wasn’t fixed in the official Android Java OpenGL ES 2.x bindings until Android 2.3 thus anyone wanting to support 2.2 needed to use a custom GL binding.
Since Google has shown to not take proper engineering care of things they don’t use themselves it’s really best for them to just get out of the way and let 3rd parties create bindings as long as the drivers, in this case OpenCL, are accessible. One of the talking points from Google is how difficult and time consuming it will be to offer Java bindings and what not to OpenCL. The actual reality is that the best solution is for Google to get out of the way and let 3rd parties develop and maintain bindings.
Getting back to the early Renderscript graphics foray which Google shut down this wasn’t the initial accelerated graphics option on Android. OpenGL ES 1.x / 2.x being available from the get go and already widely used of course from the get go certainly would have caused a major uproar if it was removed in favor of Renderscript graphics. It’s much easier to suppress an open standard and spread FUD before it’s widely used / available.
As an aside for current Renderscript functionality It should be noted that one can send a Renderscript allocation to an OpenGL texture, so there is some interop there. I’m not sure without digging around about reading back / performance concerns from GL to Renderscript. Of course it should be noted that there are mechanisms with OpenCL to use GL textures as buffer / data without the need for transfers. This leads to my next point.
I haven’t touched upon this next point yet, but will do so in the coming weeks in another G+ post is that one of the more frustrating aspects of OpenCL not being introduced together with OpenGL ES 3.x on Android is that in many respects this really minimizes some of the functionality of OpenGL ES 3.x. IMHO OpenGL ES 3.x and OpenCL 1.1+ are made for each other and it’s no surprise that all mobile GPU manufacturers have full CL driver implementation. One of the really compelling reasons to move to OpenGL ES 3.x is the new standardized thread synchronization primitives which allow a more fine grained and performant solution for multi-threading with the GL pipeline. It saddens me greatly because one of the major usages for these thread sync APIs is for use along with OpenCL interop.
While not specifically a GL / CL interop example a nice tutorial from ARM on thread sync options in ES 3.x (one can easily extrapolate on how this can be used w/ CL) is available below:
http://malideveloper.arm.com/downloads/deved/tutorial/SDK/android/thread_sync.html
Well, let’s keep fighting the good fight and getting the word out that open standards are the future to GPU computation!