9. If Android becomes a desktop OS, it should be able to access desktop GPUs and mobile GPUs. OpenCL has broad support on both platforms.

8. Aparapi makes it easy to launch OpenCL kernels from Java. It's open-source and GSS Mahadevan has successfully used it on Android.

7. In addition to CPUs and GPUs, OpenCL kernels can be executed on DSPs and FPGAs. Future high-performance devices will be more likely to support OpenCL than any other language.

6. When OpenCL devices are added to a context, they can work together to execute kernels. With OpenCL, embedded devices have the potential of accessing more powerful systems to crunch data.

5. One of OpenCL's chief advantages is OpenCL-OpenGL interoperability, which allows OpenCL kernels to process OpenGL buffer data before rendering starts. It would take a lot of work to add a similar capability for Renderscript.

4. Currently, native Android developers need to learn x86 and ARM/NEON instructions to ensure high-performance. Intel and ARM are both strong supporters of OpenCL, so if Android adopted OpenCL, native developers would only have to learn one language.

3. Google has put aside O3D in favor of WebGL and the Renderscript graphics engine in favor of OpenGL. If history is any guide, Google will choose OpenCL over Renderscript computation.

2. The general-purpose GPU (GPGPU) community is small and fragmented. It's unlikely that a new, OS-specific language will attract a developer base large enough to justify its existence.

1. If iOS supports OpenCL and Android doesn't, GPU-accelerated apps will run faster on iOS. High-performance mobile computing isn't a big deal yet, but there's no telling what the future may bring.

I'm working on quantum mechanics simulations on home hardware, including Android devices. Google claims that OpenCL programs are locked into how they're designed around group size; my kernels aren't. I wrote my kernels to scale based on a parameter for group size specified at compile time. If you're writing OpenCL, this is part of the programmer's job where scaling considerations are applicable.

Renderscript is kind of a nightmare, as I try to shoe-horn my OpenCL into a Renderscript program and back-door to get group size control back. There's practically zip documentation on Renderscript, and the organization of the workspace is haphazard from my POV as an OpenCL developer. I use Android; I love Android; but Google is making it really hard for me by assuming that I can't be bothered to handle low-level organization when I specifically want to push the hardware with computationally intensive code. If we ask for OpenCL, it's because we want the control it implies. We're big girls and boys; we can handle the manual control, and we'll use high-level parts of the SDK anyway when computation capacity isn't taxed.

What would you think about an Android-Tab with a multi-core epiphany processor on board? In a few weeks the first creditcard-size boards will be shipped to the first backers from the kickstarter project. This will be the first platform to develop OpenCL-based Apps for Android, and make it a 90 GFLOP system with 5W power-consumption.