Компания AMD представила (http://www.amd.com/en-us/press-releases/Pages/boltzmann-init... инициативу Boltzmann, в рамках которой ведётся разработка средств для организации гибридных вычислений с привлечением CPU и GPU. В частности, в рамках инициативы развивается универсальный компилятор HСC (Heterogeneous Compute Compiler), способный генерировать код для CPU и GPU на основании исходных текстов на языке C++, а также транслятор, преобразующий исходные тексты с расширениями CUDA (https://ru.wikipedia.org/wiki/CUDA). Одновременно компания AMD представила новую линейку серверных GPU FirePro S (http://www.amd.com/en-us/products/graphics/server), которые в свете предоставления возможности использования приложений на базе технологии CUDA могут составить конкуренцию компании NVIDIA в области построения высокопроизводительных вычислительных систем.Компилятор HCC продолжает развитие ранее представленного компилятора HSA (https://www.opennet.dev/opennews/art.shtml?num=41864), основанного на наработках проекта LLVM/Clang. В HCC компания AMD попыталась устранить основной барьер, мешающий продвижению развиваемых в AMD технологий гибридных вычислений, - излишняя усложнённость предложенного решения. HCC даёт разработчикам более высокоуровневые средства разработки, позволяя использовать язык C++, вместо низкоуровневой разработки на Си с применением OpenCL.
В опубликованной на днях спецификации OpenCL 2.1 (https://www.khronos.org/news/press/khronos-releases-opencl-2... привязка к языку была преодолена благодаря появлению ядра OpenCL C++ и средств для использования расширений для языка C++, но OpenCL всё равно остаётся слишком низкоуровневым API, а также весьма неохотно внедряется в продуктах NVIDIA (NVIDIA ограничивается поддержкой OpenCL 1.2), что приводит к его непопулярности в среде разработчиков высокопроизводительных приложений. Компания AMD, которая продолжает верить в будущее OpenCL как единого стандарта, в компиляторе HCC попыталась найти разумный выход: разработчик получил возможность применения одного компилятора и одной кодовой базы на C++ с интегрированными расширениями HIP (Heterogeneous-compute Interface) для организации работы на CPU и GPU, без выделения в отдельные файлы компонентов, выполняемых на стороне GPU.
Параллелизм в HIP реализуется через введение специальных параллельных операций, таких как parallel_for_each, для определения выполняемых параллельно сегментов кода и методов взаимодействия с остальным кодом программы, или через использование высокоуровневого Parallel STL (Standard Template Library), развиваемого в рамках спецификаций C++ 17 и определяющего ряд стандартных функций, выполняемых на стороне GPU. Для решения проблем с совместимостью AMD разработал инструментарий для трансляции кода с расширениями CUDA, позволяющий преобразовывать CUDA-проекты в HIP для из последующей компиляции для GPU AMD и, наоборот, транслировать HIP в CUDA для GPU NVIDIA. Также представлен инструментарий HIPify для автоматического портирования исходных текстов CUDA-проектов на HIP. Таким образом удалось добиться полной совместимости с CUDA и предоставить разработчикам возможность использования уже имеющихся CUDA-программ на GPU AMD.
<center><a href="http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia... src="https://www.opennet.dev/opennews/pics_base/0_1447862069.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Компания AMD также развивает специализированный 64-разрядных драйвер для Linux, ориентированный на оснащение узлов вычислительных кластеров и запуск приложений в окружении HSA+, примечательном использованием единого для CPU и GPU унифицированного адресного пространства (GPU и CPU могут напрямую обращаться к общим блокам памяти), что существенно упрощает программирование и приближает доступные для GPU AMD средства к возможностям технологии CUDA, используемой компанией NVIDIA. HSA+ дополняет стандартное окружение HSA (https://www.opennet.dev/opennews/art.shtml?num=41864) (Heterogeneous System Architecture) расширениями, обеспечивающими поддержку дискретных GPU (HSA сосредоточен на APU).
URL: http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...
Новость: http://www.opennet.dev/opennews/art.shtml?num=43336
Интересно, на Xeon PHI будет доступна поддержка OpenCL C++?
Ну раз amd64 используют с кросслицензированием, то почему бы не нет.
думаете NVIDIA нужно будет это от AMD, который догоняет? :)
Думаете большинству линуксоидов интересно, нужно ли это NVIDIA ?
https://www.youtube.com/watch?v=_36yNWw_07g
Думаете, существует большинство линуксоидов?
Думаете, среди линуксоидов только меньшинства?
> Думаете, среди линуксоидов только меньшинства?Те, кого здесь называют "альтернативно одарёнными", перекладывая со своей больной головы на здоровую.
Да оно существует, это объективная реальность. Не представляю корпоративную инфраструктуру без Linux.
Думаете нам нужна мерзкая проприетарщина NVIDIA CUDA? Если да, то вы ошиблись ресурсом, проприетарастам здесь не рады.
> Думаете нам нужна мерзкая проприетарщина NVIDIA CUDA? Если да, то вы ошиблись
> ресурсом, проприетарастам здесь не рады.К сожалению, аналогов, которые способны соперничать с вычислительными сопроцессорами Nvidia, пока нет.
Из реальных конкурентов есть Intel Xeon Phi, но пока производительность на реальных задачах пониже. В приукрашенном Nvidia варианте это выглядит так:
http://www.nvidia.com/object/justthefacts.html
По факту не совсем, но близко.А создание универсальных компиляторов тут вообще притом, что задачу хорошо бы запускать на всех вычислительных ресурсах кластера, а не только на сопроцессорах и не писать для этого вторую реализацию для CPU, третью для Xeon Phi и тп. Здорово, что хоть кто-то этим занимается, а не пилит свои vendor locked реализации.
Ну так новость о какой железке?
> К сожалению, аналогов, которые способны соперничать с вычислительными сопроцессорами
> Nvidia, пока нет.Это, конечно, аргумент, но истинно преданный идее СПО человек всё равно не станет пользоваться проприетарщиной. Например, именно поэтому Ричард Столлман до сих пор работает на древнем ноутбуке, хотя, другой на его месте мог бы сказать "ну, раз современные ноуты все сплошь несвободные, придётся пользоваться несвободным, раз свободных аналогов нет".
Серверные GPU! Теперь поиграем...
Я понимаю зачем они, но всё равно дико как-то...
Унифицированный вычислительный модуль, давно уже не просто GPU, да и без видео вывода они в серверах - просто чип на плате.
Ну какбе в мощные модели серверов от IBM на архитектуре power8 опционально ставятся видеокарты (естественно не те, что для вывода графики, а вычислительные сопроцессоры). И на них запускается java-машина, и работает по обещаниям IBM довольно шустро.Интересная ссылка по теме:
http://devblogs.nvidia.com/parallelforall/next-wave-enterpri.../
Прогнулись...
Кто? Кронос под АМД? Вряд ли, это обоюдная любовь...
хорошая инициатива под названием Bolt :D
Используются ли данные наработки в приставках на Ягуаре?
Здорово, ничего не надо подключать, проверять, не нужны драйвера и т.п., скомпилировалось -> будет работать. Вообще эту несправедливую систему с драйверами для видеокарт давно надо было ликвидировать, все взаимодействия с оборудованием с повышенными требованиями к производительности просто обязаны производиться прямыми вызовами инструкций, как в случае с ЦП.
Лучше бы сразу поставили ЦП и разъем памяти на видеокарту в едином корпусе.Сейчас комп состоит из нескольких радиаторов (4-х: ЦП, минимум один на матери, видеокарте, в БП), за каждым из которых надо следить чтобы не перегрелся, свое питание, все это образует островки железа и кучу соплей в большом корпусе.
Вместо одного радиатора, на который привинчены все грелки, к которым пристыкована плата, все это размером с кирпич при тех же пиковых 500 ваттах.
"Лучше бы сразу поставили ЦП и разъем памяти на видеокарту в едином корпусе."гуглим hsa ииии....
"Heterogeneous System Architecture (HSA) is a computer processor architecture that integrates central processing units and graphics processors on the same bus, with shared memory and tasks."
> все это размером с кирпич при тех же пиковых 500 ваттах.Пока ещё не дошли до того что всех устраивает однотипный модуль, каждый вендор свои наборы городит.
Больцман в гробу вращается. Вместе в Вейерштрассом.
Или это не тот Больцман, а какой-то АМДшный программист?
> Больцман в гробу вращается. Вместе в Вейерштрассом.
> Или это не тот Больцман, а какой-то АМДшный программист?кто такой этот больцман? дядя ваш чтоли больцман?
тот, который вместе с вейерштрассом был больцано
просто поставь Intel
Это в том числе и для Intel Xeon PHI. Фанатики, учим мат.часть!
С исходниками на CUDA? Похоже что амбиционзый отказ от релиза почти готового ATi Stream был поспешным.
Пользуюсь карточкой NVIDIA. Для компиляции графической подсистемы DRI/Mesa теперь требуется LLVM/Clang 3.7 (в системе идёт версией ниже). Зачем оно нужно, спрашивается, если графические адаптеры AMD не задействуются, а весь 3D выполняется силами драйвера NVIDIA с АППАРАТНОЙ поддержкой более новой версии OpenGL, чем у полу-программной Mesa?
А это тебе лучше знать. Как это ты вообще умудрился поставить mesa совместно с проприетарными дровами? Они же конфликтуют.
> Как это ты вообще умудрился поставить mesa совместно с проприетарными дровами? Они же конфликтуют.Это у вас на старье конфликтуют. У меня всё работает.
% pkg info -x dri
dri-10.6.9,2
dri2proto-2.8
nvidia-driver-346.96
xorg-drivers-7.7_3% glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 750/PCIe/SSE2
OpenGL core profile version string: 4.4.0 NVIDIA 346.96
OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5.0 NVIDIA 346.96
OpenGL shading language version string: 4.50 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 NVIDIA 346.96
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
> Пользуюсь карточкой NVIDIA. Для компиляции графической подсистемы DRI/Mesa теперь требуется
> LLVM/Clang 3.7 (в системе идёт версией ниже). Зачем оно нужно, спрашивается,
> если графические адаптеры AMD не задействуются,Они над тобой издеваются! Не дали USE-флага сборки без llvmpipe-а или как там его и, хитро так подмигивая, предлагают подождать следующего релиза с лапочкой 3.7 в базе и новой месой, требующей ещё более нового эппле-прогрессора, да?
А, да, чуть не пропустил -- меса-то не в базе же, да? Тогда "всё норм"! Вона "не в базе" даже GPLv3 gcc -- и ничего, правда, именно так и надо?
>> Пользуюсь карточкой NVIDIA. Для компиляции графической подсистемы DRI/Mesa теперь требуется
>> LLVM/Clang 3.7 (в системе идёт версией ниже). Зачем оно нужно, спрашивается,
>> если графические адаптеры AMD не задействуются,
> Они над тобой издеваются! Не дали USE-флага сборки без llvmpipe-а или как
> там его и, хитро так подмигивая, предлагают подождать следующего релиза с
> лапочкой 3.7 в базе и новой месой, требующей ещё более нового
> эппле-прогрессора, да?Если точнее, то dri-10.6.9 на LLVM 3.6 завязан:
% portmaster -e llvm36-3.6.2_2
===>>> Warning: Ports with dependencies on llvm36-3.6.2_2:
libEGL-10.6.9
dri-10.6.9,2> А, да, чуть не пропустил -- меса-то не в базе же, да?
Догадливый!
> Тогда "всё норм"! Вона "не в базе"
> даже GPLv3 gcc -- и ничего, правда, именно так
> и надо?GCC вообще не нужен, если честно. Без него обходимся.
отлично живет без ллвм, не путайте. а кто как порт сделал - ссзб. про гцц без коментариев, ллвм ненужен
лучше бы они драйверами занялись, может быть тогда и на суперкомьютерах бы больше использовали
>> лучше бы они драйверами занялись, может быть тогда и на суперкомьютерах бы больше использовалиТак они ими и занимаются. С массивами ядер у них все хорошо, с дровами пока так себе.
