What was the real reason why Google is chosing RenderScript instead of OpenCL? -

the question has been asked before in different form, i'd know android-developers think what's behind google's decision , not google's official answer is.

opencl open standard , works on various devices, such cpus, desktop gpus, arm processors, fpgas , dsps. gives developers convenience of creating high performance software , libraries, works on devices.

renderscript higher level language, focuses on media-manipulation , runs on both cpu , gpu. works on new android phones , tablets, not on other operating systems. big difference opencl renderscript handles scheduling, , not software.

google's official answer factually incorrect on opencl, frustrated many in opencl-community , logically gave hefty reactions. please factual both renderscript , opencl - don't want question closed because nonsense being told.

first, let deal answer this question tim murray.

• he states opencl/cuda execution model tied various factors of execution model register counts, local memory , other such details. while may partly true, opencl execution model developed allow clever developer abstract these differences in way can still yield maximum performance.

• for example: deal differences in micro-architectures should kernel developer need know such details, opencl runtime api provides clgetdeviceinfo exposes plethora of information (note extension information can retrieved here).

• details of vector (simd-style) execution not spared. opencl implementation guides state kernels should written without explicit vectorization - implementation vectorize execution of adjacent work-items. model followed cuda (which not provide vector types anymore, different matter).

• coming point of work-items; indeed possible constrain work-dimension particular size. in practice, reqd_work_group_size attribute hardly ever used unless known dimension (for sake of calculation, not performance).

• also, opencl documentation clenqueuendrangekernel states

"local_work_size can null value in case opencl implementation determine how break global work-items appropriate work-group instances."

this true of intel , amd implementations.

let move onto points raised stephen hines on over android bug page on here.

• "opencl not fit needs of android developers" - don't believe there poll of sort. don't see stephen gets incontrovertible information. cannot debate this.
• "and actively contributes platform fragmentation" - developers @ google really going argue ndk contains no features hardware-specific? if warning listed on ndk homepage weren't enough.
• "opencl not fit needs/goals of android, not going ship google devices support it". if true, android devices not have shipped opencl support. cannot state better vincent on here.

"not google hardware vendors made drivers renderscript compute. arm chose build rsc-compiler on top of opencl, because chose opencl.

see - hardware vendors did not create drivers because google or khronos group asked them too, created them because wanted to. opengl , webcl of reasons, competition on new desktop."

in end, being developer has worked gpgpu since days of register combiners (on geforce 2), see no reason why opencl more disruptive android ecosystem or why should preferred this answer states

apple holds trademark on opencl. google competes apple. perhaps it's simple.

we've done work on opencl android (see here) , happy see moving forward work of intel, imagination, , other chip makers. google turn around enough.

perhaps simple.