Android 4.3 update for Nexus 10 and 4 removes unofficial OpenCL driversby Rahul Garg on August 1, 2013 6:15 PM EST
We had previously reported that Android 4.2 firmwares for Nexus 10 and Nexus 4 were found to contain OpenCL drivers. The drivers were an internal implementation detail and not officially supported for use by developers, and we had mentioned that the drivers may be removed in future updates. Android 4.3 is now rolling out to these devices and OpenCL drivers are no longer present in the new update.
OpenCL is an API for parallel and heterogeneous computing defined by Khronos, the same group that also stewards OpenGL. On the desktop and server side, AMD, Intel and Nvidia (and some others, such as Altera) support OpenCL on Windows and Linux. Apple in particular heavily pushes OpenCL on OSX and is providing drivers for latest version of OpenCL (1.2) in OSX Mavericks for all shipping Macs. Mobile hardware vendors including Qualcomm, ARM and Imagination Technologies tout OpenCL readiness for their hardware, but without shipping drivers on commercial devices, it is not possible to use OpenCL. Google is pushing their own proprietary solution called Renderscript on Android.
At a very high level, Renderscript is to OpenCL as Java is to C+Assembly. Renderscript is meant to be portable to any Android device irrespective of underlying hardware and does not expose lower level details of the hardware to the programmer. For example, Renderscript does not allow the programmer to choose whether a particular piece of code should run on the CPU, GPU or DSP etc. Such decisions are taken automatically by the Renderscript driver provided on the Android device. Renderscript's approach promotes portability and ease of use but there maybe a (potentially large) performance cost compared to well-optimized code in a lower-level language. Renderscript Compute has some other shortcomings such as lack of interoperability with graphics and lack of support in the Android NDK. The lack of programmer control, associated potential performance costs and other limitations make it unsuitable for some applications such as high performance game engines. Renderscript should be fine for some applications such as some of the simpler image processing filter applications and indeed Google is promoting Filterscript, a subset of Renderscript, which particularly targets image processing type applications.
OpenCL and Renderscript are largely complementary. OpenCL exposes more of the details of the hardware and can be a powerful tool in the hands of experienced programmers, but more power requires more responsibility on the part of the programmer. For example, OpenCL allows one to get really close to the hardware and it is possible to obtain close to peak performance if the programmer invests the effort in optimizing for the platform. However, code that is heavily optimized for one vendor's hardware may perform poorly on hardware from other vendors. Experienced developers typically therefore write multiple code versions with each optimized for different architectures, and provide a fallback code for platforms they do not know well.
According to some unofficial comments from Google engineers, which I will clarify is not an official statement, Google's concern is that inexperienced developers may not use OpenCL's power properly. For example, developers may test and optimize code for only one hardware, and may not realize that the code performs poorly on others. Given the diversity of hardware in the Android world, Google is preferring Renderscript over OpenCL. I think Google would prefer consistent performance everywhere, even if it means not reaching the peak on any platform.
My understanding is that the drivers were removed at Google's request, to promote Renderscript over OpenCL, though that is speculation and not an official word. It is a little unfortunate that Google appears uninterested in even providing OpenCL as an option, at least on Nexus devices where it (presumably) controls the firmware and the drivers shipped with the firmware.
It remains to be seen whether Google will provide access to any low-level heterogeneous computing API in Android in the standard SDKs. I also wonder how Google will react to NVIDIA's quest to bring technologies like CUDA to the Android world given that Google appears to be entirely uninterested in allowing any parallel compute API except Renderscript. It is perfectly possible that device makers will ship OpenCL or alternate low-level solutions (like CUDA) as a differentiating factor on non-Nexus devices as hardware vendors often provide additional SDKs specific to their devices.
Renderscript joins the ranks of existing parallel and heterogeneous computing technologies such as CUDA, OpenCL, C++ AMP, DirectCompute, OpenGL compute shaders, OpenACC and OpenMP 4.0 as yet another option for heterogeneous computing. Ultimately, each of the APIs has its own strengths and weaknesses. And much like other technical domains, such as programming languages, browser standards and graphics APIs, various parallel computing APIs are being driven by a mix of technical and business interests. Ultimately, there will be a consolidation but it is difficult currently to guess which APIs will remain in end. We will continue to watch how this space evolves.
Post Your CommentPlease log in or sign up to comment.
View All Comments
SetiroN - Thursday, August 1, 2013 - linkThat's a shame... I was really looking forward to apps leveraging OpenCL for certain specific tasks, such as video and picture editing.
ltcommanderdata - Thursday, August 1, 2013 - linkThe OpenCL 2.0 spec specifically adds an extension for Android so presumably support is coming sooner or later. Seemingly later in this case.
Gokhan Avkarogullari: "No OpenCL driver. SGX does not natively support OpenCL."
Since you bring up Imagination and Apple do you have any details on why Gokhan Avkarogullari from the iOS GPU driver team is saying that the PowerVR SGX does not natively support OpenCL? Imagination has demoed OpenCL running on SGX devices before. Was this done via some sort of emulation or are there certain limitations in the implementation? Or is Apple just not convinced of the usefulness of Embedded Profile? Current mobile GPUs may check the OpenCL support checkbox, but perhaps there are still limitations in hardware that make Apple and Google reluctant to enable support at this time.
rahulgarg - Thursday, August 1, 2013 - linkMy hypothesis (not based on actual data) is that the PowerVR 5XT performance on OpenCL is not that great. 5XT was designed before OpenCL was even ratified. Likely Apple will introduce OpenCL on iOS once Series 6 based iOS devices start shipping.
xdrol - Thursday, August 1, 2013 - link"At a very high level, Renderscript is to OpenCL as Java is to C+Assembly"
I rather say, as Java 2 from 1998 is to a modern C/C++ from 2011.
A lot of news about the OpenCL 2.0 announcement had a few words about an "Installable Client Driver for Android", but there is zero information available about that. I hope it is what it sounds to be...
djscrew - Friday, August 2, 2013 - linkApple, who (corporations as people) doesn't need to worry about hardware variation can simply adopt a very strong hardware solution say... a Nvidia GPU+ARM big.LITTLE SOC that's somehow HUMA enabled and natively optimize the hell out of the code. Such a solution seems like it would pee and poo all over the Renderscript alternative from a generic Android device. I would like to be able to livestream 4K video from my smartphone in the next 5 years or less please, thx tech industry.
R3MF - Friday, August 2, 2013 - linkhopefully SoC vendors like Qualcomm will continue to ship OpenCL capability in their Android drivers, for even if Google isn't interested there are other platforms that can use Android SoC drivers via libhybis, like Jolla and Ubuntu, and possibly even Tizen.
roberto.tomas - Sunday, August 4, 2013 - linkthere is coverage of this over at CHW.net, where they are claiming that Google not only removed openCL from 4.3, but changed LLVM so that software like drivers can't be written to leverage openCL and include it on their own, leaving some GPU manufacturers without this tool to differentiate their product.
rahulgarg - Sunday, August 4, 2013 - linkTo clarify, the clang frontend has been disabled but that does not affect non-Nexus devices in any way. Whether or not to ship proper OpenCL drivers with the full frontend enabled is still up to the device vendor.
rahulgarg - Sunday, August 4, 2013 - linkI meant to say, clang frontend has been disabled *on Nexus 10*, but that does not affect non-Nexus devices in any way.
twtech - Monday, August 5, 2013 - linkThe net effect is probably that most developers end up using neither.
A performance-oriented library only accessible through java? Really?