Незамеченной на хабре прошла новость о появлении OpenCL 2.0 драйверов от AMD и Intel.
Многим кажется, что подобный API просто очередной маркетинговый buzzword. Отчасти это так, потому что почти все современные аппаратные продукты выходят с пунктом «OpenCL» в списке поддерживаемых технологий и рекламе: последние CPU, GPU, APU (CPU+GPU), FPGA, CPU+FPGA. И многим из области разработки enterprise ПО хочется откреститься от этих «модных» названий, но и это скоро станет невозможно стараниями Oracle и AMD.
Массовый параллелизм аппаратного обеспечения уже давно присутствует в серверах, пресональных компьютерах, телефонах и планшетах, специализированных аппаратных ускорителях. OpenCL в области FPGA рассматривается как способ упростить, удешевить и популяризовать разработку. При этом использование преимуществ, предоставляемых аппаратурой, пока требует от программиста использовать таких API как OpenCL, CUDA, OpenMP. Но появляются попытки скрыть эту сложность от прикладных программистов, например Project Sumatra и ScalaCL.
OpenCL уже позволил оптимизировать производительность графических редакторов Photoshop CC 2014 и GIMP 2.8 RC 1. Рендереры LuxRender и Cycles из проекта Blender также выигрывают от применения этого API. И даже офисный пакет LibreOffice использует OpenCL. Для меня было очень неожиданно узнать из новостей, что мой бывший работодатель отличился в оптимизации VP9 видео энкодера с помощью OpenCL.
OpenCL 2.0 был утвержден как стандарт почти год назад. Этот стандарт поддерживает технологии доступные в современном аппаратном обеспечении: Shared Virtual Memory позволяет избегать лишнего/явного копирования данных между областями памяти, nested parallelism позволяет планировать выполнение kernel функций на устройстве без превлечения host программы уменьшая задержки, pipe как дополнительный способ обмена данными между kernel функциями а также расширенную поддержку atomic операций.
Мне больше всего греет душу, что теперь не нужны «костыли» для реализации atomic операций с floating point данными в OpenCL. Как не странно, эта проблема с atomic cmpxchg volatile приводила очень много людей в мой блог и такой же подход использовали другие разработчики до появления этой возможности в последнем стандарте.
Можно продолжать игнорировать преимущества предоставляемые аппаратным обеспечением… Или попытаться задействовать с большей эффективностью современное аппаратное обеспечение и сделать proof of concept для вашего проекта, если есть возможность параллелизовать алгоритм и объем вычислений в проекте достаточно большой.
А что вы думаете про перспективы использования OpenCL в корпоративном программном обеспечении или вашем проекте?
Автор: igor_suhorukov
