The OpenNET Project / Index page

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

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

12.03.2018 12:11

Состоялся релиз проекта PoCL 1.1 (Portable Computing Language OpenCL), развивающего реализацию стандарта OpenCL, независимую от производителей графических ускорителей и позволяющую использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров. Код проекта распространяется под лицензией MIT. Поддерживается работа на платформах X86_64, MIPS32, ARM v7, AMD HSA APUs и различных специализированных 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/Clang 6.0 и 5.0. Обеспечена экспериментальная поддержка промежуточных представлений кода SPIR и SPIR-V (используется в API Vulkan), которые могут применяться как для представления шейдеров для графики, так и для параллельных вычислений. Поддержка SPIR/SPIR-V основана на коде SPIRV-LLVM. Проведена работа по сокращению времени компиляции ядер OpenCL, которая позволила в разы сократить время сборки Luxmark и на 30-50% ускорить прохождения внутренних тестов. Проведён рефакторинг работы кэша. Улучшена поддержка архитектур ARM и ARM64 (системы с CPU Cortex-A53 и Cortex-A15 теперь проходят все внутренние тесты).

  1. Главная ссылка к новости (http://portablecl.org/pocl-1.1...)
  2. OpenNews: Опубликован графический стандарт Vulkan 1.1
  3. OpenNews: В LibreOffice добавлена поддержка ускорения вычислений с использованием OpenCL
  4. OpenNews: В Fedora 21 предложено обеспечить "из коробки" поддержку OpenCL на основе открытых технологий
  5. OpenNews: Доступны спецификации OpenCL 2.0 и OpenVX 1.0. AMD развивает альтернативу OpenGL
  6. OpenNews: Релиз набора компиляторов LLVM 6.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48242-pocl
Ключевые слова: pocl, opencl, llvm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 13:09, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    И что, тоже от Шланга зависит?
    Ждём GnuCL.
     
  • 1.2, Вареник (?), 14:42, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Теперь бесполезный Эльбрус сможет в OpenCL?
     
     
  • 2.3, Аноним (-), 15:04, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Может быть эту новость можно читать как "теперь под эльбрус можно канпелировать линукс не только проприетарщиной"
     
     
  • 3.4, Andrey Mitrofanov (?), 16:13, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Может быть эту новость можно читать как "теперь под эльбрус можно канпелировать
    > линукс не только проприетарщиной"

    .
    .
    .
    Новости-то про эльбрус давно кончились, а раненых всё везут и везут.

     
     
  • 4.6, Аноним (-), 17:13, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Новость не читай, сразу отвечай. Там же vliw упомянут, а кроме эльбруса его уже небось нигде больше и не осталось.
     
     
  • 5.8, Andrey Mitrofanov (?), 17:38, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > его уже небось нигде больше и не осталось.

    Нет.(C)

     
  • 5.13, Crazy Alex (ok), 19:12, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там не тот VLIW, от слова "совсем"
     
  • 5.15, Ordu (ok), 19:36, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ладно. AMD'шные GPU на VLIW пашут. Плюс есть всякие специализированные процессоры к криптографии да к обработке сигналов. VLIW превращается в тыкву, когда зависимости между последовательными командами неустранимы, но есть задачи, на которых зависимости хорошо устраняются, и под эти задачи вполне себе делают VLIW'ы.
     
     
  • 6.18, мимонагироскутере (?), 21:30, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    устаревшие, возможно даже, что уже отпахались
     
  • 6.24, Stax (ok), 23:42, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вылезайте из криокамеры, AMD уже 7 лет как открестилась от VLIW и перешла на RISC.
     
  • 6.30, Аноним (-), 00:24, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да ладно. AMD'шные GPU на VLIW пашут.

    Ну вообще-то они перелезли на GCN, который таки сделали несколько более похожим на более обычные CPU, с аргументом что в GPGPU вычислениях VLIW - "не очень". Геморно програмить и оптимизация кода хромает. Стандартная VLIWопроблема, убившая даже итаник.

     
  • 2.7, Аноним (-), 17:25, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > бесполезный Эльбрус

    Звучит как "мокрая вода".

     
  • 2.23, Аноним (-), 23:25, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Теперь бесполезный Эльбрус сможет в OpenCL?

    Неа, не сможет. Он понимаешь ли системный CPU а не акселератор. Без нормального компилера на системном проце нечего ловить. Даже если забыть о стоимости этой штуки и желании фирмы нормально работать.

     
  • 2.37, Michael Shigorin (ok), 20:40, 27/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    OpenCL на e2k и так есть, а вот llvm там пока нет.
     

  • 1.9, Онаним (?), 18:01, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, изобретут когда-нибудь бэкэнд к OpenCL, работающий на JavaScript в браузере через HTTP... Вот было бы круто: просто открыл страничку в браузере на компе и он уже часть кластера, который можно использовать удалённо через стандартные библиотеки...
     
     
  • 2.10, Аноним (-), 18:10, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотретите, может есть порт boinc на js? :D:D:D
     
  • 2.11, Anonim (??), 18:39, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Интересно, изобретут когда-нибудь бэкэнд к OpenCL, работающий на JavaScript в браузере через HTTP... Вот было бы круто: просто открыл страничку в браузере на компе и он уже часть кластера, который можно использовать удалённо через стандартные библиотеки...

    Криптомайнинг выйдет на новый уровень

     
  • 2.17, Аноним (-), 19:50, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ElectronCL ?
     
  • 2.20, Аноним (-), 22:33, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да был уже; вот спека https://www.khronos.org/webcl/, а нокия даже дополнение к браузеру сделала. Не взлетел, в том числе из-за проблем с безопасностью и не нужностью, хотя работал очень неплохо, была демка с рейтрейсингом.
     
     
  • 3.26, Аноним (-), 00:12, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Да был уже; вот спека https://www.khronos.org/webcl/, а нокия даже дополнение к браузеру
    > сделала. Не взлетел, в том числе из-за проблем с безопасностью и
    > не нужностью, хотя работал очень неплохо, была демка с рейтрейсингом.

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

     

  • 1.12, лютый жабист__ (?), 19:03, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ничё не понял, опенкл же и есть открытый и исполняющийся на цпу. Эксперты опеннета, поясните! :)
     
     
  • 2.14, Crazy Alex (ok), 19:13, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Стандарт - открытый. Реализации для конкретного железа - где как.
     
     
  • 3.16, Аноним (-), 19:50, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И исполняется как правило на GPU/APU.
     
     
  • 4.19, Crazy Alex (ok), 21:55, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как правило ;-)
     
  • 2.22, Аноним (-), 22:53, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ничё не понял, опенкл же и есть открытый и исполняющийся на цпу.
    > Эксперты опеннета, поясните! :)

    Объясняю. Фигня этот опенсиэл. Потому что всё равно прихозится затачивать под платформу. То есть на процессоре интел нужен код оптимизированный под процессор интел, на видюхе амд - под видюху амд, на нвидии вообще надо юзать куду, для мали - под мали, для fpga intel-altera - под этот fpga, для TPU - под TPU. Это если вам нужно выжать из железки всё, если вам нужна максимальная производительность. Если же не нужно, зачем вы вообще полезли сюда, в мир аппаратных ускорителей? Короче, как была фрагментация жуткая - так и осталась, и возиться с этим зоопарком сущий ад, хорошо что хоть язык и апи общее. За примерами идите в hashcat, там для каждой карты своё ядро. Всё усугубляется неудобным интерфейсом и закидонами каждой конкретной железки, например ядро из юзерленда в виртуалке может обрушить или даже хакнуть хост потому, что на старой карте нет mmu.

     
     
  • 3.29, Аноним (-), 00:19, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > например ядро из юзерленда в виртуалке может обрушить или даже хакнуть
    > хост потому, что на старой карте нет mmu.

    Ващет IOMMU обычно в чипсете. И если его нет - до хака дело обычно не доходит: когда ничего не подозревающий драйвер програмит GPU как обычно, GPU со всеми его DMA и проч идет и делает то что попросили. Проблема в том что драйвер в виртуалке оперировал адресами которые он видит в этой своей виртуалке. А вот GPU пойдет и сделает что попросили по адресам хоста, если IOMMU не вмешается. В виртуалку это не попадет. Вместо этого GPU вынесет что-нибудь в памяти системы. В этот момент система обычно ловит клин, потому что ядро хоста убито наповал. А хакерствовать в заклиненой системе несколько неудобно :)

     
  • 3.32, лютый жабист__ (?), 06:53, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Фигня этот опенсиэл. Потому что всё равно прихозится затачивать под платформу

    Спасибо, интересно. Хотя ситуация 1в1 с "asm vs c" и как известно, победил си. А то и жабопыхи всякие, ещё более высокоуровневые.

     

  • 1.21, Аноним (-), 22:42, 12/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Можно закaпывать. Все диплёрнеры юзают и будут юзать куду, так как куда на картах нвидия даёт большую производительность, а сами карты нвидия дают производительность больше, чем карты AMD. Даже если АМД станет на 20% круче нвидии, проще и дешевле (с учётом альтернативной стоимости и того, что за ресёрчеров платит государство, а карта стоит копейки по сравнению с затратами на зп) докупить пару топовых карт нвидиа чем перепиливать тензорфлоу или кафэ. Так что нвидию никто не потеснит, чтобы потеснить нвидид надо запилить куду поверх вулкана, чтобы работала на амудэ. АМД лично этим заниматься не будет, ибо юристы нвидии иск впаяют.
     
     
  • 2.25, Stax (ok), 23:48, 12/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > с затратами на зп) докупить пару топовых карт нвидиа чем перепиливать
    > тензорфлоу или кафэ. Так что нвидию никто не потеснит, чтобы потеснить

    Стоп-стоп-стоп, а почему не рассматривается вариант - tensorflow будет работать не через куду, а какую-нибудь эффективную прослойку для карт AMD? Собственно не факт, что вычисления на nvidia мощнее, просто компания выпустила хорошие API, которые удобно использовать, а AMD нет.

    Собственно, пишет же интел tensorflow для xeon phi. И все обещают, что вот-вот выпустят (года два как минимум).

     
     
  • 3.36, Аноним (-), 00:10, 14/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты отдаещь себе отчёт, что для этого придётся все инструменты портировать на новый стек, а нафиг это нужно, если уже есть куда? Гораздо проще запилить куду, работающую на амд и получить весь стек рабочий автоматом. Есть правда нюанс - стек оптимизирован под карты нвидия, но почувствуй разницу "производительность "просела на 50%, но это работает, уже полдела сделано, можно начать играться и попутно оптимизировать" и "не работает ничего, мне придётся переписать весь проект на opencl/vulkan".
     
  • 2.27, Аноним (-), 00:14, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Можно закaпывать. Все диплёрнеры юзают и будут юзать куду, так как куда
    > на картах нвидия даёт большую производительность,

    ...а все майнеры выносят полки с AMDшными видяхами и довольны по уши OpenCL. И их зело побольше этих дипперплов. Потому что с этого перпла поди еще получи профит, а с майнинга профит очевиден любому болвану.

     
     
  • 3.31, лютый жабист__ (?), 06:30, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >а с майнинга профит очевиден любому болвану

    Это когда болван живёт у мамки и не платит за электричество :) и видюху с компом тоже выклянчил у папки.

     

  • 1.28, YetAnotherOnanym (ok), 00:16, 13/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хлорид полония?
     
     
  • 2.33, Аноним (-), 09:27, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Хлорид полония?

    Британские спецслужбы зело годуют.

     
  • 2.38, Michael Shigorin (ok), 20:43, 27/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ...одновалентного, ага.
     

  • 1.35, papa Ken (?), 21:07, 13/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот здорово! Для Фуксии... нет правда все что связано с поддержкой api Vulkan здорово... для Фуксии и новый Open GL и новый Open CL /Embedding OpenCL который для встроенных систем!
     

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



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

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