The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз PoCL 1.6, независимой реализации стандарта OpenCL

22.12.2020 12:04

Представлен релиз проекта PoCL 1.6 (Portable Computing Language OpenCL), развивающего реализацию стандарта OpenCL, независимую от производителей графических ускорителей и позволяющую использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров. Код проекта распространяется под лицензией MIT. Поддерживается работа на платформах X86_64, MIPS32, ARM v7, AMD HSA APU и различных специализированных TTA-процессорах (Transport Triggered Architecture) c архитектурой VLIW.

Реализация компилятора ядер OpenCL построена на базе LLVM, а в качестве фронтэнда для OpenCL C используется Clang. Для обеспечения должной переносимости и производительности компилятор ядер OpenCL может генерировать комбинированные функции, которые могут использовать различные аппаратные ресурсы для распараллеливания выполнения кода, такие как VLIW, суперскалярность, SIMD, SIMT, многоядерность и многопоточность. Имеется поддержка ICD-драйверов (Installable Client Driver). Присутствуют бэкенды для обеспечения работы через CPU, ASIP (TCE/TTA), GPU на базе архитектуры HSA и GPU NVIDIA (CUDA).

В новой версии:

  • Добавлена поддержка LLVM 11.
  • Расширены возможности по отладке кода OpenCL при использовании драйвера CPU.
  • Добавлен сборочный параметр HARDENING_ENABLE для включения опций компилятора для генерации более защищённого варианта libpocl.so ценой снижения производительности.
  • Проведена оптимизации производительности бэкенда CUDA, позволившая заметно ускорить операции, связанные с использованием локальной памяти (FFT, GEMM). Производительность PoCL во многих тестах теперь близка к проприетарному драйверу OpenCL от компании NVIDIA.

  • Возвращена поддержка систем PowerPC 8/9, уровень реализации OpenCL для которых при использовании устройств pthread и CUDA соответствует уровню CUDA на системах x86_64.
  • Добавлена возможность компиляции PoCL с драйверами устройств, включёнными во время сборки - доступность устройств будет проверена при запуске (ранее системы, на которых собирается и выполняется PoCL, должны были иметь идентичную поддержку драйверов). Реализована возможность применения пакетного менеджера conda для распространения бинарных пакетов PoCL с поддержкой CUDA для систем Linux-x86_64 и Linux-ppc64le.
  • Изменён ABI для ядер CUDA, в которых используются блоки __local. После обновления пользователям необходимо удалить кэш pocl.
  • Прекращена поддержка сборочной опции SINGLE_LLVM_LIB, вместо которой для определения библиотек для связывания задействованы STATIC_LLVM и llvm-config.


  1. Главная ссылка к новости (https://www.khronos.org/news/a...)
  2. OpenNews: Опубликованы финальные спецификации OpenCL 3.0
  3. OpenNews: Collabora развивает надстройку для работы OpenCL и OpenGL поверх DirectX
  4. OpenNews: Релиз PoCL 1.4, независимой реализации стандарта OpenCL
  5. OpenNews: Компания Apple перевела OpenGL и OpenCL в разряд устаревших технологий
  6. OpenNews: Релиз набора компиляторов LLVM 11.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54299-opencl
Ключевые слова: opencl, pocl
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (40) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, InuYasha (??), 12:11, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Эм... т.е. библиотека стандарта OpenCL, призванного решить проблему железозависимости (как та же CUDA), оказалось, таки, зависимой и пришлось создавать тру-независимую реализацию? o_O
     
     
  • 2.5, wapmobil (ok), 12:42, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Мужики решают проблему связанную с нежеланием производителей реализовывать OpenCL в своих драйверах
     

  • 1.2, Арагорн (?), 12:16, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Релиз PoCL 1.6, !!сильной!! и независимой реализации стандарта OpenCL

    а если серьезно, то нафиг, если для куды я буду использовать куду, а на центральных процах (с сопроцами) стандартные потоки/процессы

    вообще, реализация не зависит от графических вендоров, но зависит от разных бэкендов?.. хм, не шило ли на мыло выходит

     
     
  • 2.3, Nuzhny (?), 12:26, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    1. Иногда код, написанный на OpenCL для CPU может работать быстрее, чем код написанный на С для CPU. Почему? потому что на OpenCL накладывается намного больше ограничений и его проще автоматически транслировать в векторные инструкции.
    2. Отладка. На CPU намного просто отлаживать код, чем на GPU.
    3. Всё таки один и тот же код можно выполнять на разных устройствах - это путь к настоящей кроссплатформенности.

    Но тут следом Intel со своим oneAPI. Посмотрим, что будет дальше.

     
     
  • 3.7, Riddick (?), 12:42, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Посмотрим, как Intel выжмут скоро с рынка потребительской электроники. Останутся решения для серверов. Apple идет своим путем, MS начинает свои чипы делать. Intel - стагнирующий динозавр
     
     
  • 4.9, Аноним (9), 12:51, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Интол будет другом всего отрытого железа и не огороженных рабочих станций. Возможность поменять железки это всё же крутая фича, понятно что производителю куда выгоднее когда покупают новое и старое отправляют на свалку.
     
     
  • 5.10, Аноним (9), 12:53, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя с другой стороны никто не запрещает интолу заняться ровно тем же самым, что он уже делает сегодня. Пока что по производительности на ватт и поддержке ПО он на десятилетия впереди, дальше будет видно.
     
     
  • 6.16, Riddick (?), 13:54, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хотя с другой стороны никто не запрещает интолу заняться ровно тем же
    > самым, что он уже делает сегодня. Пока что по производительности на
    > ватт и поддержке ПО он на десятилетия впереди, дальше будет видно.

    В том-то и дело. Рядовому "юзверю" не нужна производительность, как показывает практика. Браузеры и так работают. А вот где реально нужна производительность - это узкая сфера профессионалов и большого бизнеса

     
     
  • 7.18, Аноним (9), 14:33, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Игрушечки нас спасут, если киберпанки окончательно не закопают индустрию.
     
     
  • 8.20, InuYasha (??), 14:36, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Игрушечкам пока больше нужно ГПУ, а, вот, браузерам как раз ЦПУ - и его не всегд... текст свёрнут, показать
     
     
  • 9.21, Аноним (9), 14:38, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Процессоры тоже нужны, чтобы кормить ту же видеокарту Сколько там ядер киберпан... текст свёрнут, показать
     
  • 9.42, asdasd (?), 09:21, 25/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поверьте, GPU без CPU ничето и часто COU как раз тоже не хватает, причем зачасту... текст свёрнут, показать
     
  • 8.23, Anonimous (?), 14:58, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так самый быстрый проц для игр уже тоже не интел по последним тестам в сравнении... текст свёрнут, показать
     
  • 7.25, Lex (??), 15:16, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну дык интол владеет Альтерой или к слову о ПЛИС и их подобиях + тоннами выкупает стартапы и конторы, занимающиеся нейросетевыми технологиями( в т.ч всевозможными нейрочипами и «умной» электроникой )
     
  • 5.27, VladSh (?), 15:51, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Интол будет другом всего отрытого железа и не огороженных рабочих станций. Возможность поменять железки это всё же крутая фича

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

     
     
  • 6.28, Аноним (9), 16:11, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Во-первых не каждый год, наверное около 3-5 лет (зависит от линейки) и куча процессоров из которых можно выбрать, во-вторых, память например не распаяна и её можно поменять как на более быструю, так и на большего объёма. Иногда замена сокета действительна оправдана, у амд то же самое: без замены сокета ты обретёшь и потеряешь часть возможностей, хотя время поддержки побольше (незначительно). У конкурентов камни вообще распаяны.
     
     
  • 7.29, Аноним (9), 16:12, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    обретёшь проблемы*
     
  • 7.33, VladSh (?), 18:58, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    AMD при прочих равных добавляет новые фичи быстрее. Вот сейчас это, к примеру, PCIe 4.0.
    Те "конкуренты" вообще не в счёт.
     
  • 5.37, Аноним (37), 00:01, 23/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >другом всего отрытого железа
    >ME
    >FSP
    >TVP
    >SGX

    С такими друзьями и врагов не надо.

     
  • 2.4, Аноним (4), 12:28, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Дополнительная прослойка, которая никогда не позволит выжать максимум из конкретной платформы за счёт стандартизации и обобщения. Это как ORM не позволяет использовать БД на максимум возможностей.
     
     
  • 3.6, Аноним (6), 12:42, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я отлично знаю SQL, но не прекращаю использовать ORM, тык что пример так себе.
     
     
  • 4.11, Аноним (9), 12:56, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я тут лет 5 назад хотел использовать sqlite without rowid из питона, у меня по-моему не получилось сделать это из орм-обёрток. Главная проблема конечно очень низкая производительность, но удобно.
     
     
  • 5.19, Аноним (9), 14:36, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Просадка в 100000 раз из-за орм это  достаточная мотивация перейти на голые запросы. Та же алхимия в принципе позволяет использовать себя без орм), так что прослойки прослойкам рознь.
     
  • 4.13, имя_ (?), 13:06, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так он и не писал, что использующие орм - это неосиляторы sql.

    ОРМ накладывает свои ограничения для кроссплатформенности. Всегда, конечно, можно сделать что-то типа raw query, но тогда какой смысл в лишней прослойке в виде орма?

     
  • 3.26, _hide_ (ok), 15:22, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> как кривая ORM не позволяет использовать БД на максимум возможностей

    Спасибо можете не говорить

     
  • 2.8, wapmobil (ok), 12:47, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ага и ты потратишь кучу времени на реализацию своего алгоритма под разные платформы, а в итоге он (внезапно!) будет работать медленнее чем тот который напишу я на OpenCL сразу на всё, особенно на CPU, потому что у меня будет проще код и проще его оптимизировать. А тебе чтобы хоть немного сравняться по производительности на CPU необходимо будет использовать AVX, MXX и ассемблерные вставки, и причём ещё разные под каждую модель процессора... удачи короче!
     
     
  • 3.14, Аноним (9), 13:15, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. ты зависишь от вендора, на который возлагается задача по оптимизации под различные платформы и их ревизии. И сравниваешься себя с человеком, который будет сам реализовывать поддержку без прослоек. Что мешает ему тоже взять определённое качественное middleware и ни в чём себя не ограничивать? Ведь как ты говоришь, ты себя ограничиваешь во всём из-за отсутствия у тебя возможности использовать железо на полный спектр возможностей.
     
  • 2.34, Ordu (ok), 19:26, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > реализация не зависит от графических вендоров, но зависит от разных бэкендов?.. хм, не шило ли на мыло выходит

    Не. Глянь на mesa, которая реализует OpenGL. Не зависит от вендоров, но зависит от бекендов.

     

  • 1.12, Аноним (12), 13:00, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    лучше бы независимую куду запилили. Опенкл используют полтора землекопа - даже во всяких питонячьих либах для машинного обучения, поддержка сабжа в зайчаточном состоянии и написана двумя индусами для личного пользования. Как итог - отставание производительности (opencl vs cuda) в несколько раз
     
     
  • 2.17, Аноним (17), 14:27, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Лучше бы ты делом занимался, вместо нытья. Например, пилил независимую куду
     

  • 1.15, Аноним (15), 13:16, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >http://portablecl.org/downloads/CHANGES
    >http://

    Не нужно.

     
  • 1.22, Аноним (22), 14:47, 22/12/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     
  • 1.24, Аноним (-), 15:11, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >Реализация компилятора ядер OpenCL построена на базе LLVM, а в качестве фронтэнда для OpenCL C используется Clang

    Пацаны нас обманули! Они как раз таки зависят от производителей. Проприетарщики выбирают продукты с БЗДуноподобной лицензией. Да название какое-то подозрительное не Free, а Open.

    Только копилефт, только истинная свобода!

     
     
  • 2.32, Аноним (32), 18:31, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Назови навскидку пару *стандартов*, которые free, а не open. И поясни заодно, чем они отличаются.
     
     
  • 3.38, Аноним (-), 07:25, 23/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не переводи разговор в другое русло. Тут речь идёт о конкретной реализации.
     

  • 1.31, Аноним (31), 16:32, 22/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ответьте мне, пожалуйста, как новичку: PoCL можно использовать вместе с Blender, например? Чтобы не возиться с проприетарными дровами AMD-Pro?
     
     
  • 2.35, Аноним (35), 19:40, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользователям Blender карточка nVidia не имеет аналогов
     
     
  • 3.36, n242name (?), 22:36, 22/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почему?

    Какой смысл открытости амд дров тогда?

     

  • 1.40, Аноним (40), 08:55, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что ещё за Полоний-Хлор (PoCl)?
     
     
  • 2.41, Химик (?), 14:20, 24/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Что ещё за Полоний-Хлор (PoCl)?

    Последняя буква L -большая. А в Cl - хлор, последняя буква l - маленькая.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру