Какова была настоящая причина, по которой Google использует RenderScript вместо OpenCL?

Вопрос был задан до в несколько иной форме, но я хотел бы знать, что Android-разработчики считают, что действительно стоит за решением Google, а не тем, что Google официальный ответ.

OpenCL является открытым стандартом и работает на различных устройствах, таких как процессоры, настольные графические процессоры, процессоры ARM, FPGA и DSP. Это дает нам разработчикам удобство создания высокопроизводительного программного обеспечения и библиотек, которое работает на всех устройствах.

RenderScript - это язык более высокого уровня, который фокусируется главным образом на медиа-манипуляции и работает как на процессоре, так и на графическом процессоре. Он работает на всех новых телефонах и планшетах Android, но не на других операционных системах. Большая разница с OpenCL заключается в том, что RenderScript всегда обрабатывает планирование, а не программное обеспечение.

Официальный ответ Google на самом деле был неверным на OpenCL, что разочаровало многих в сообществе OpenCL и логически дало некоторые сложные реакции. Поэтому, пожалуйста, будьте откровенны как с RenderScript, так и с OpenCL - я не хочу, чтобы этот вопрос был закрыт, потому что говорят о бессмыслице.

Ответ 1

Во-первых, давайте рассмотрим ответ на этот вопрос Тима Мюррея.

Он утверждает, что модель исполнения OpenCL/CUDA связана с различными факторами их модели исполнения, такими как количество регистров, локальная память и другие подобные детали. Хотя это может быть отчасти верно, модель исполнения OpenCL была специально разработана, чтобы позволить умному разработчику абстрагировать эти различия таким образом, который еще может обеспечить максимальную производительность.
Например: чтобы разобраться с различиями в микро-архитектурах, если разработчику ядра необходимо знать такие детали, API-интерфейс OpenCL обеспечивает clGetDeviceInfo, который предоставляет множество информации (обратите внимание, что здесь также можно получить информацию о расширении).
Детали выполнения векторного (SIMD-стиля) также не сохраняются. Большинство руководств по внедрению OpenCL state, что ядра должны быть написаны без явной векторизации - реализация будет векторизовать выполнение смежных рабочих элементов. Это также модель, за которой следует CUDA (которая даже не предоставляет типы векторов, но это другое дело).
Приближается к деталям работы; действительно возможно сжимать рабочий размер до определенного размера. Однако на практике атрибут reqd_work_group_size вряд ли когда-либо используется, если он не является некоторым известным измерением (ради расчета, а не производительности).
Кроме того, в документации OpenCL для clEnqueueNDRangeKernel четко указано, что

"local_work_size также может быть значением NULL, в этом случае OpenCL реализация определит, как разбить глобальные рабочие элементы в соответствующие экземпляры рабочей группы."

Это относится к Intel и реализациям AMD.

Перейдем теперь к точкам, поднятым Стивеном Хайнсом, на странице с ошибкой Android над здесь.

"OpenCL не соответствует потребностям разработчиков Android" - я не думаю, что был опрос любого рода. Я не вижу, где Стивен получает эту неопровержимую информацию. Я не могу обсуждать это.
"и активно участвует в фрагментации платформы" - разработчики в Google действительно будут утверждать, что NDK не содержит функций, конкретный? Как будто предупреждение, перечисленное на главной странице NDK, было недостаточно.
"OpenCL не соответствует потребностям/целям Android, поэтому мы не собираемся отправлять устройства Google с поддержкой". Если бы это было так, эти устройства Android не были бы отправлены с поддержкой OpenCL. Я не могу утверждать, что это лучше, чем Винсент над здесь.

"Не Google, а производители оборудования сделали драйверы для RenderScript Compute. ARM решил построить RSC-компилятор поверх OpenCL, потому что они уже выбрали OpenCL.

См. - поставщики оборудования не создали драйверы, потому что Группа Google или Khronos Group тоже спросили их, они создали их, потому что они хотеть. OpenGL и WebCL - вот некоторые из причин, но конкуренция за новый рабочий стол ".

В конце концов, будучи разработчиком, который работал с GPGPU со времени объединения регистраторов (на GeForce 2), я не вижу причин, по которым OpenCL более разрушительна для экосистемы Android или почему это должно быть предпочтительнее, чем этот ответ, который гласит

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

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

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