Почему Google выбрал RenderScript вместо OpenCL

Мне было интересно, можно ли использовать OpenCL для Android, узнать, что это невозможно, и вообще отбросил тему. Но благодаря сообщению в блоге от 14 января в официальном блоге разработчиков Android (http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html), я обнаружил, что возможно параллельное программирование начиная с Android 4.0, благодаря RenderScript! API, который имеет довольно много общих функций с OpenCL.

Теперь мне интересно: почему Google решил реализовать это новое решение вместо того, чтобы нажимать OpenCL forward (открытая спецификация теперь обрабатывается группой Khronos).

Я имею в виду, я знаю, это не очень сложно конвертировать из одного в другое, но все же...

В любом случае, если кто-то как реальное объяснение, пожалуйста, дайте мне знать!

Ответ 1

Ответ: потребности Android сильно отличаются от того, что предлагает OpenCL.

OpenCL использует модель исполнения, впервые введенную в CUDA. В этой модели ядро состоит из одной или многих групп рабочих, и каждая группа имеет быструю разделяемую память и примитивы синхронизации внутри этой группы. Это означает, что описание алгоритма должно быть смешано с тем, как этот алгоритм должен планироваться на определенной архитектуре (потому что вы определяете размер группы и когда синхронизировать внутри этой группы).

Это замечательно, когда вы пишете для одной архитектуры и хотите абсолютную максимальную производительность, но она получает максимальную производительность за счет производительности. Возможно, на вашей архитектуре у вас достаточно регистров и разделяемой памяти для запуска 256 сотрудников в группе для достижения максимальной производительности, но в другой архитектуре вы получите массивную регистрацию разливов с чем-то более 128 сотрудников на группу, что приведет к 80% -ной регрессии производительности, Между тем, поскольку ваш код явно написан для 256 сотрудников на группу, среда выполнения не может ничего сделать, чтобы попытаться улучшить ситуацию на другой архитектуре - она должна подчиняться тому, что вы написали. Такая ситуация распространена при переходе от архитектуры к архитектуре на компьютере/HPC-стороне вычисления графического процессора.

На мобильном телефоне Android требуется переносимость производительности между множеством разных производителей графических процессоров и процессоров с очень разными архитектурами. Если Android будет полагаться на модель исполнения в стиле CUDA, было бы практически невозможно написать одно ядро и запустить его на разных устройствах.

Рефераты RenderScript контролируют планирование от разработчика за счет некоторой максимальной производительности; однако мы постоянно закрываем пробел с точки зрения того, что возможно с помощью RenderScript. Например, ScriptGroup, API, представленный в Android 4.2, является большой частью наших планов по дальнейшему улучшению генерации кода графического процессора. Появилось много новых улучшений, которые также упрощают работу с быстрым кодом.

Ответ 2

Apple имеет товарный знак на OpenCL. Google конкурирует с Apple. Возможно, это действительно так просто.

Мы работали над OpenCL с Android (см. здесь) и рады видеть, что он продвигается вперед благодаря работе Intel, Воображение и другие производители чипов. Google скоро обернется.