Представлена открытая реализация OpenCL, базирующаяся на использовании LLVM

20.10.2011 12:59

В списке рассылки разработчиков LLVM представлен проект Portable OpenCL, в рамках которого ведётся разработка полностью открытой и независимой реализации стандарта OpenCL, который определяет API и расширения языка Си для параллельного программирования с использованием как многоядерных CPU, так и GPU видеокарт.

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

Также стало известно о появлении проекта по работе над открытой OpenCL-библиотекой, который имеет сходные цели, но гораздо меньшие масштабы. В рамках проекта libclc идет работа только над интерфейсом языка Си, описанном в стандарте, без реализации уровней OpenCL Platform и OpenCL Runtime. Для связи библиотеки с конкретной реализацией OpenCL от производителя используется простое переопределение функций. Цель проекта: позволить разработчикам использовать стандартные открытые средства разработки приложений вместо инструментов, предоставляемых производителями графических ускорителей.

Для генерации OpenCL-кода обе реализации используют инструментарий LLVM. Дополнительно можно отметить ещё один открытый проект FreeOCL, в рамках которого создаётся реализация спецификации OpenCL 1.1, нацеленная на использование CPU (x86, x86_64, ARM, PPC64). FreeOCL написан на языке С++ с задействованием некоторых нововведений стандарта C++11. Вместо специального или встроенного компилятора, FreeOCL полагается на использовании внешних компиляторов, такие как GCC 4.4, ICC 11.0, LLVM 2.8 и armcc.

Дополнение: Готовится к открытию под лицензией BSD ещё одна реализация OpenCL для многоядерных CPU. Компилятор проекта основан на использовании LLVM/Clang. Главной целью проекта является обеспечение максимально возможной производительности, полнота реализации OpenCL API ставится на второе место. По заявлению разработчиков в коде для обеспечения параллелизма активно используются инструкции SIMD (SSE и AVX), что позволило заметно увеличить производительность, которая в настоящее время опережает реализации OpenCL драйверов для CPU из состава AMD Stream SDK и Intel OpenCL SDK.

исправить +18 +/–

Автор новости: Evgeny Zobnin

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/32092-opencl

Ключевые слова: opencl, llvm

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (12)

1.1, anonymous (??), 13:45, 20/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	+3 +/–
Зашевелились, и это хорошо. Даже steckdenis обновил свой проект после долгой паузы http://cgit.freedesktop.org/~steckdenis/clover/commit/?id=c377dd4e18c7321db6f

1.2, Zenittur (?), 13:52, 20/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
На ЛОРе в обсуждении новости кто-то высказал интересную мысль. Благодаря свободной реализации OpenCL во всех дистрибутивах будет библиотека OpenCL сразу. Как сейчас /usr/lib/libGL.so.1: во всех дистрибутивах свободная Mesa, которую сразу все удаляют, заменяя на проприетарную версию. Программы затем имеют зависимость от libGL.so.1 и работают во всех дистрибутивах, даже где проприетарных видеодрайверов нет. А с Portable OpenCL программа запустится без nvidia cuda tooltit или amd stream sdk, имея необязательную использованную опцию OpenCL. А моё мнение: будет что привязывать к открытому драйверу radeon.

2.3, Zenittur (?), 13:55, 20/10/2011 [^] [^^] [^^^] [ответить]	+/–
Необязательно используемую

1.4, Nickolaev (?), 13:56, 20/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
http://code.google.com/p/freeocl/

1.5, Аноним (-), 14:02, 20/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
"Задача проекта - создать единую реализацию ... которая позволила бы разработчикам не задумываться о ... применении специфических техник оптимизации" Спасибо. Вот чего не хватало, так это создания проектов по продвижению неоптимизированных кодов. Хотя после IM на гиг я уже ничему не удивляюсь.

2.6, Аноним (-), 15:32, 20/10/2011 [^] [^^] [^^^] [ответить]	+/–
> создания проектов по продвижению неоптимизированных кодов Вообще-то речь как раз о том, чтобы не дублировать одни и те же оптимизации для каждой отдельной реализации. А то, понимешь, наизобретали велосипедов.

3.10, Аноним (-), 11:15, 21/10/2011 [^] [^^] [^^^] [ответить]	+/–
2.9

1.8, eugenyn (ok), 04:47, 21/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	+/–
NVidia не так давно тоже заявляла нечто подобное, только для именно CUDA. - Чтобы с каждой новой реализацией ее видеокарт становились не нужны особые оптимизационные техники. Что видно, в принципе, даже уже давно, по версиям Compute Capability - в более новых версиях отпадает необходимость в части оптимизаций.

2.9, Аноним (-), 10:22, 21/10/2011 [^] [^^] [^^^] [ответить]	+/–
Я бы сказал иначе: рост производительности техники сокращает разницу выполнения оптимального и неоптимального кода на незагруженной аппаратуре. Проще купить проц следующего поколения чем потратить полчаса на оптимизацию. Особенно это становится явным при использовании модульного подхода, когда задачей многих становится собрать из кубиков-модулей своё мега-творение и продать его, при этом не неся ответственности ни за один из компонентов.

3.11, eugenyn (ok), 11:29, 21/10/2011 [^] [^^] [^^^] [ответить]	+/–
В случае с CUDA не учет расположения банков памяти на GPU влечет замедление работы в разы. Практически такая же картина при любых техниках/технологиях работы с многопоточностью - не учет факторов, влияющих на оптимизацию выполнения - замедляет работу программы иногда и в десятки раз (а в случае блокировок программа вообще никогда нормально не завершится). :) Неудача Висты была вызвана как раз неправильными какими-то вещами в работе многопоточного кода, я подробности не помню, но когда вышла 7-ая виндовс - была информация от разработчиков, с переводом в Рунете, что реально повлияло на неудачу Висты.

1.12, Аноним (-), 19:57, 25/10/2011 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Они там что, прикалываются?! Кому opencl на x86 сдался? Програминг opencl напоминает полную йогу и имеет смысл в ровно 1 случае: скорость любой ценой. Даже ценой йоги, нужной лишь потому что gpu - не cpu, полновесный си с очень параллельными simd равсширениями в него втолкать тяжко. А такое урезанное и специализированное - запросто. Программить в таком виде х86? Зачем???

2.13, anonymous (??), 17:16, 27/10/2011 [^] [^^] [^^^] [ответить]	+/–
Для отладки. Одно дело теория, а другое дело просто поменать ключик компилятора или выбрать в выппадающем списке программы другой драйвер в ревлтайме и погладеть как оно на самом деле работает. А то написать "наша программа (или очередная железка)за $10000 в 30 раз быстрее CPU" может каждый, а тут клик клик - и сравниваем реально.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: