Android 4.3 update for Nexus 10 and 4 removes unofficial OpenCL drivers

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.