Состоялся (http://portablecl.org/pocl-1.1.html) релиз проекта PoCL 1.1 (http://portablecl.org/) (Portable Computing Language OpenCL), развивающего реализацию стандарта OpenCL, независимую от производителей графических ускорителей и позволяющую использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров. Код проекта распространяется (https://github.com/pocl/pocl/) под лицензией MIT. Поддерживается работа на платформах X86_64, MIPS32, ARM v7, AMD HSA APUs и различных специализированных TTA-процессорах (Transport Triggered Architecture (https://ru.wikipedia.org/wiki/Transport_triggered_architectu... c архитектурой VLIW (https://ru.wikipedia.org/wiki/VLIW).Реализация компилятора ядер OpenCL построена на базе LLVM, а в качестве фронтэнда для OpenCL C используется Clang. Для обеспечения должной переносимости и производительности компилятор ядер OpenCL может генерировать комбинированные функции, которые могут использовать различные аппаратные ресурсы для распараллеливания выполнения кода, такие как VLIW, суперскалярность, SIMD, SIMT, многоядерность и многопоточность. Имеется поддержка ICD-драйверов
(Installable Client Driver). Присутствуют бэкенды для обеспечения работы через CPU, ASIP (TCE/TTA), GPU на базе архитектуры HSA (https://en.wikipedia.org/wiki/Heterogeneous_System_Architect... и GPU NVIDIA (CUDA).В новой версии (https://github.com/pocl/pocl/releases/tag/v1.1) добавлена поддержка выпусков LLVM/Clang 6.0 и 5.0. Обеспечена экспериментальная поддержка промежуточных представлений кода SPIR (https://www.khronos.org/registry/spir) и SPIR-V (https://www.khronos.org/registry/spir-v/) (используется в API Vulkan), которые могут применяться как для представления шейдеров для графики, так и для параллельных вычислений. Поддержка SPIR/SPIR-V основана на коде SPIRV-LLVM (https://github.com/KhronosGroup/SPIRV-LLVM). Проведена работа по сокращению времени компиляции ядер OpenCL, которая позволила в разы сократить время сборки Luxmark и на 30-50% ускорить прохождения внутренних тестов. Проведён рефакторинг работы кэша. Улучшена поддержка архитектур ARM и ARM64 (системы с CPU Cortex-A53 и Cortex-A15 теперь проходят все внутренние тесты).
URL: http://portablecl.org/pocl-1.1.html
Новость: https://www.opennet.me/opennews/art.shtml?num=48242
И что, тоже от Шланга зависит?
Ждём GnuCL.
Теперь бесполезный Эльбрус сможет в OpenCL?
Может быть эту новость можно читать как "теперь под эльбрус можно канпелировать линукс не только проприетарщиной"
> Может быть эту новость можно читать как "теперь под эльбрус можно канпелировать
> линукс не только проприетарщиной".
.
.
Новости-то про эльбрус давно кончились, а раненых всё везут и везут.
Новость не читай, сразу отвечай. Там же vliw упомянут, а кроме эльбруса его уже небось нигде больше и не осталось.
> его уже небось нигде больше и не осталось.Нет.(C)
Там не тот VLIW, от слова "совсем"
Да ладно. AMD'шные GPU на VLIW пашут. Плюс есть всякие специализированные процессоры к криптографии да к обработке сигналов. VLIW превращается в тыкву, когда зависимости между последовательными командами неустранимы, но есть задачи, на которых зависимости хорошо устраняются, и под эти задачи вполне себе делают VLIW'ы.
устаревшие, возможно даже, что уже отпахались
Вылезайте из криокамеры, AMD уже 7 лет как открестилась от VLIW и перешла на RISC.
> Да ладно. AMD'шные GPU на VLIW пашут.Ну вообще-то они перелезли на GCN, который таки сделали несколько более похожим на более обычные CPU, с аргументом что в GPGPU вычислениях VLIW - "не очень". Геморно програмить и оптимизация кода хромает. Стандартная VLIWопроблема, убившая даже итаник.
> бесполезный ЭльбрусЗвучит как "мокрая вода".
> Теперь бесполезный Эльбрус сможет в OpenCL?Неа, не сможет. Он понимаешь ли системный CPU а не акселератор. Без нормального компилера на системном проце нечего ловить. Даже если забыть о стоимости этой штуки и желании фирмы нормально работать.
OpenCL на e2k и так есть, а вот llvm там пока нет.
Интересно, изобретут когда-нибудь бэкэнд к OpenCL, работающий на JavaScript в браузере через HTTP... Вот было бы круто: просто открыл страничку в браузере на компе и он уже часть кластера, который можно использовать удалённо через стандартные библиотеки...
Посмотретите, может есть порт boinc на js? :D:D:D
> Интересно, изобретут когда-нибудь бэкэнд к OpenCL, работающий на JavaScript в браузере через HTTP... Вот было бы круто: просто открыл страничку в браузере на компе и он уже часть кластера, который можно использовать удалённо через стандартные библиотеки...Криптомайнинг выйдет на новый уровень
ElectronCL ?
Да был уже; вот спека https://www.khronos.org/webcl/, а нокия даже дополнение к браузеру сделала. Не взлетел, в том числе из-за проблем с безопасностью и не нужностью, хотя работал очень неплохо, была демка с рейтрейсингом.
> Да был уже; вот спека https://www.khronos.org/webcl/, а нокия даже дополнение к браузеру
> сделала. Не взлетел, в том числе из-за проблем с безопасностью и
> не нужностью, хотя работал очень неплохо, была демка с рейтрейсингом.Да они просто не в тренде. Надо было майнер XMR давать как референсный код. Ща бы апи рулило и педалило, гугл бы встроил опмитизированный вариант апи прямо в хром. Конечно же не просто так а за процент с намайненого получаемый от сайтиков которые любят монетизацию.
Ничё не понял, опенкл же и есть открытый и исполняющийся на цпу. Эксперты опеннета, поясните! :)
Стандарт - открытый. Реализации для конкретного железа - где как.
И исполняется как правило на GPU/APU.
Как правило ;-)
> Ничё не понял, опенкл же и есть открытый и исполняющийся на цпу.
> Эксперты опеннета, поясните! :)Объясняю. Фигня этот опенсиэл. Потому что всё равно прихозится затачивать под платформу. То есть на процессоре интел нужен код оптимизированный под процессор интел, на видюхе амд - под видюху амд, на нвидии вообще надо юзать куду, для мали - под мали, для fpga intel-altera - под этот fpga, для TPU - под TPU. Это если вам нужно выжать из железки всё, если вам нужна максимальная производительность. Если же не нужно, зачем вы вообще полезли сюда, в мир аппаратных ускорителей? Короче, как была фрагментация жуткая - так и осталась, и возиться с этим зоопарком сущий ад, хорошо что хоть язык и апи общее. За примерами идите в hashcat, там для каждой карты своё ядро. Всё усугубляется неудобным интерфейсом и закидонами каждой конкретной железки, например ядро из юзерленда в виртуалке может обрушить или даже хакнуть хост потому, что на старой карте нет mmu.
> например ядро из юзерленда в виртуалке может обрушить или даже хакнуть
> хост потому, что на старой карте нет mmu.Ващет IOMMU обычно в чипсете. И если его нет - до хака дело обычно не доходит: когда ничего не подозревающий драйвер програмит GPU как обычно, GPU со всеми его DMA и проч идет и делает то что попросили. Проблема в том что драйвер в виртуалке оперировал адресами которые он видит в этой своей виртуалке. А вот GPU пойдет и сделает что попросили по адресам хоста, если IOMMU не вмешается. В виртуалку это не попадет. Вместо этого GPU вынесет что-нибудь в памяти системы. В этот момент система обычно ловит клин, потому что ядро хоста убито наповал. А хакерствовать в заклиненой системе несколько неудобно :)
>Фигня этот опенсиэл. Потому что всё равно прихозится затачивать под платформуСпасибо, интересно. Хотя ситуация 1в1 с "asm vs c" и как известно, победил си. А то и жабопыхи всякие, ещё более высокоуровневые.
Можно закaпывать. Все диплёрнеры юзают и будут юзать куду, так как куда на картах нвидия даёт большую производительность, а сами карты нвидия дают производительность больше, чем карты AMD. Даже если АМД станет на 20% круче нвидии, проще и дешевле (с учётом альтернативной стоимости и того, что за ресёрчеров платит государство, а карта стоит копейки по сравнению с затратами на зп) докупить пару топовых карт нвидиа чем перепиливать тензорфлоу или кафэ. Так что нвидию никто не потеснит, чтобы потеснить нвидид надо запилить куду поверх вулкана, чтобы работала на амудэ. АМД лично этим заниматься не будет, ибо юристы нвидии иск впаяют.
> с затратами на зп) докупить пару топовых карт нвидиа чем перепиливать
> тензорфлоу или кафэ. Так что нвидию никто не потеснит, чтобы потеснитьСтоп-стоп-стоп, а почему не рассматривается вариант - tensorflow будет работать не через куду, а какую-нибудь эффективную прослойку для карт AMD? Собственно не факт, что вычисления на nvidia мощнее, просто компания выпустила хорошие API, которые удобно использовать, а AMD нет.
Собственно, пишет же интел tensorflow для xeon phi. И все обещают, что вот-вот выпустят (года два как минимум).
Ты отдаещь себе отчёт, что для этого придётся все инструменты портировать на новый стек, а нафиг это нужно, если уже есть куда? Гораздо проще запилить куду, работающую на амд и получить весь стек рабочий автоматом. Есть правда нюанс - стек оптимизирован под карты нвидия, но почувствуй разницу "производительность "просела на 50%, но это работает, уже полдела сделано, можно начать играться и попутно оптимизировать" и "не работает ничего, мне придётся переписать весь проект на opencl/vulkan".
> Можно закaпывать. Все диплёрнеры юзают и будут юзать куду, так как куда
> на картах нвидия даёт большую производительность,...а все майнеры выносят полки с AMDшными видяхами и довольны по уши OpenCL. И их зело побольше этих дипперплов. Потому что с этого перпла поди еще получи профит, а с майнинга профит очевиден любому болвану.
>а с майнинга профит очевиден любому болвануЭто когда болван живёт у мамки и не платит за электричество :) и видюху с компом тоже выклянчил у папки.
Хлорид полония?
> Хлорид полония?Британские спецслужбы зело годуют.
...одновалентного, ага.
Вот здорово! Для Фуксии... нет правда все что связано с поддержкой api Vulkan здорово... для Фуксии и новый Open GL и новый Open CL /Embedding OpenCL который для встроенных систем!