Какова была настоящая причина, по которой 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 скоро обернется.

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