android - ¿Por qué Google eligió RenderScript en lugar de OpenCL
(2)
Me he estado preguntando si era posible usar OpenCL para Android, descubrir que no era posible y eliminar el tema por completo. Pero gracias a la publicación del blog del 14 de enero en el blog oficial de desarrolladores de Android (http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html), descubrí que la programación paralela era posible Desde Android 4.0, gracias a RenderScript! Una API que tiene algunas características comunes con OpenCL.
Lo que me pregunto ahora es: ¿por qué Google optó por implementar esta nueva solución, en lugar de impulsar OpenCL (una especificación abierta que ahora maneja el grupo Khronos)?
Quiero decir, lo sé, no es realmente difícil convertir de uno a otro, pero aún así ...
De todos modos, si hay alguien como la explicación real, por favor hágamelo saber!
Apple tiene la marca registrada en OpenCL. Google compite con Apple. Tal vez sea realmente tan simple.
Hemos trabajado en OpenCL con Android ( consulte aquí ) y estamos felices de verlo avanzar gracias al trabajo de Intel, Imagination y otros fabricantes de chips. Google se dará la vuelta lo suficientemente pronto.
La respuesta es que las necesidades de Android son muy diferentes de lo que OpenCL intenta proporcionar.
OpenCL usa el modelo de ejecución introducido por primera vez en CUDA. En este modelo, un kernel está formado por uno o varios grupos de trabajadores, y cada grupo tiene primitivas de sincronización y de memoria compartida rápida dentro de ese grupo. Lo que esto hace es hacer que la descripción de un algoritmo se mezcle con la forma en que se debe programar ese algoritmo en una arquitectura particular (porque usted está decidiendo el tamaño de un grupo y cuándo sincronizarlo dentro de ese grupo).
Eso es genial cuando escribe para una arquitectura y desea un rendimiento máximo absoluto, pero obtiene un rendimiento máximo a expensas de la portabilidad del rendimiento. Tal vez en su arquitectura, tenga suficientes registros y memoria compartida para ejecutar 256 trabajadores por grupo para obtener el mejor rendimiento, pero en otra arquitectura, terminaría con derrames masivos de registros con algo más de 128 trabajadores por grupo, lo que provocaría una regresión del rendimiento del 80% . Mientras tanto, debido a que su código está escrito explícitamente para 256 trabajadores por grupo, el tiempo de ejecución no puede hacer nada para tratar de mejorar la situación en otra arquitectura, tiene que obedecer lo que ha escrito. Este tipo de situación es común cuando se pasa de una arquitectura a otra en el lado de escritorio / HPC de la GPU.
En dispositivos móviles, Android necesita portabilidad de rendimiento entre diferentes proveedores de GPU y CPU con arquitecturas muy diferentes. Si Android dependiera de un modelo de ejecución estilo CUDA, sería casi imposible escribir un solo kernel y ejecutarlo de manera aceptable en una variedad de dispositivos.
RenderScript abstrae el control sobre la programación fuera del desarrollador a costa de un rendimiento máximo; sin embargo, estamos constantemente cerrando la brecha en términos de lo que es posible con RenderScript. Por ejemplo, ScriptGroup, una API introducida en Android 4.2, es una gran parte de nuestros planes para mejorar aún más la generación de código GPU. Hay muchas mejoras nuevas que vienen que hacen que escribir código rápido sea aún más fácil, también.