Организация HSA Foundation, учреждённая компаниями AMD, ARM, Samsung, Qualcomm, Texas Instruments, Imagination и MediaTek, представила (http://www.hsafoundation.com/hsa-foundation-launches-new-era.../) спецификацию HSA 1.0 (http://www.hsafoundation.com/html/HSA_Library.htm) (Heterogenous System Architecture), определяющую архитектуру, набор runtime-компонентов и программные интерфейсы гетерогенных вычислительных систем. Архитектура HSA определяет работу оборудования. Программные интерфейсы предназначены для разработчиков ПО, инструментариев и компиляторов. Сецификация на runtime, определяет как приложения должны взаимодействовать с платформами HSA.HSA позволяет наладить совместную работу CPU, GPU и различных DSP-процессоров, и организовать гибридные вычисления, в которых подходящее вычислительное устройство выбирается в прозрачном режиме в зависимости от задачи. HSA позиционируется как единая оптимизированная платформа, поверх которой может функционировать OpenCL и OpenMP. Особенностью HSA является то, что CPU и GPU имеют доступ к единым областям памяти, что упрощает организацию работы гибридных приложений и минимизирует число операций по копированию памяти. В основе HSA лежит специальный промежуточный язык HSAIL (Heterogeneous System Architecture Intermediate Language) и виртуальная машина, обеспечивающая его трансляцию в машинный код, специфичный для разного оборудования. Компоненты для использования HSA реализованы для различных высокоуровневых языков программирования, в том числе для
C++, Java и Python.<center><a href="http://www.hsafoundation.com/html/Content/SysArch/Images/Dia... src="http://www.opennet.me/opennews/pics_base/0_1426617481.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Связанные с платформой наработки, в том числе симулятор (https://github.com/HSAFoundation/HSAIL-Instruction-Set-Simul...) набора инструкций HSAIL, эталонный runtime (https://github.com/HSAFoundation/HSA-Runtime-Reference-Source) и runtime для APU AMD (https://github.com/HSAFoundation/HSA-Runtime-AMD), основанный на LLVM компилятор (https://github.com/HSAFoundation/HSAIL-HLC-Stable) в HSAIL, компилятор OpenCL в HSAIL (https://github.com/HSAFoundation/CLOC), инструментарий (https://github.com/HSAFoundation/HSAIL-Tools) для разбора, ассемблирования и дизасемблирования HSAIL опубликованы (https://github.com/hsafoundation) под свободными лицензиями на GitHub. Драйвер "AMD KFD (https://github.com/HSAFoundation/HSA-Drivers-Linux-AMD)", предоставляющий интерфейс HSA для использования вычислительных возможностей графических процессоров и APU AMD, уже включен в состав ядра Linux 3.19.
URL: http://www.hsafoundation.com/hsa-foundation-launches-new-era.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41864
А это видеокарты умеют или только встроенные в процессор видеоядра?
может хоть BIOS/EFI для ARM стандартизируют..
Пусть берут Coreboot лучше и допиливают при необходимости под все доступные варианты ARMов.
> Пусть берут Coreboot лучше и допиливают при необходимости под все доступные варианты ARMов.U-boot сто лет как есть под большинство SoC. Даже допиливать ничего не надо особо.
> может хоть BIOS/EFI для ARM стандартизируют..Соскучился по проприетарной сpaни с троянами и забагованными win-only интерфейсами, которые работают по принципу "винда вроде грузится"?
Windows это стандарт, и от него никуда не деться.
P.S. Windows откуда угодно загрузится, в отличии от кое-каких некторых других ОС;-)
> Windows откуда угодно загрузится, в отличии от кое-каких некторых других ОС;-)Даже оттуда, где DeviceTree вместо ACPI?
> Windows это стандартВы искренне заблуждаетесь сами и вводите в заблуждение других, распространяя мифы. Операционная система Windows не стандартизована. В отличие от Windows операционная система Linux стандартизована по стандарту ISO/IEC 23360-1:2006.
Стандарт LSB критикуют за то, что он не принимает предложения проектов, в особенности Debian, находящихся за пределами круга его членов.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
К примеру, LSB предписывает поставлять программные пакеты (packages) в формате RPM, который был разработан гораздо позже формата deb, однако разработчики Debian не собираются менять свой формат, так как считают его лучше RPM.
Стандарт не навязывает операционным системам, какой формат им использовать для собственных пакетов. Он лишь говорит, какой формат совместимые системы должны поддерживать для установки приложений сторонних разработчиков.
Проблема? Alien Вам в помощь.
>Windows откуда угодно загрузится, в отличии от кое-каких некторых других ОС;-)Ты только не говори это разработчикам NetBSD, а то помереть со смеху могут...
Петруччо, Linux запускается на 95% всех устройств в мире (в том числе всякие MIPS'ы), в отличие от Win, который работает на очень узком наборе оборудования. Подтягивай матчасть.
На MIPS роутере с 32мб озу загрузится?
С RasberiPI загрузится? Ведь ARM оно поддерживает...
EFI открыт.
> EFI открыт.Что Вы имеете в виду под EFI? Путаете технологию и наименование системы/программы. Есть BIOS, нет никакого EFI - посмотрите, что пишет Ваш компьютер при загрузке.
>> может хоть BIOS/EFI для ARM стандартизируют..
> Соскучился по проприетарной сpaни с троянами и забагованными win-only интерфейсами,Тёплые волны отмены и ломки захлестнули его. В новости по HSA/AMD/ARM. Странно, что невидию не вытащил и не помахал перед толпой. //Впрочем, да, квалком, имаджинейшн, медиатек. С такими друзьями, можно невидию и не вспоминать.
>Впрочем, да, квалком, имаджинейшн, медиатек. С такими друзьями, можно невидию и не вспоминать.Да уж, с такими друзьями - враги отдыхают.
Qualcomm inside. Одобряю
Подобные вещи BeOS уже умела в далеком 1995... если не ошибаюсь.
Ошибаешься
> Ошибаешьсяhttp://comhelp.narod.ru/main/beosnew.htm
до перехода на PowerPC - BeOS кроме основного процессора использовала DSP процессоры в том числе для вывода звука и графики - чем не гетерогенная система?
Ты и на линукса можешь подключать внешние dsp-шки (аля тот же майнинг на ранней стадии). HSA же это общая платформа для n типов устройств (сейчас насколько я понял cpu,gpu,dsp) для решения "generic" задач (смотри: "в которых подходящее вычислительное устройство выбирается в прозрачном режиме в зависимости от задачи."). В случае BeOS, он(dsp) как бы выполнял ряд узкоспециализированных задач, тогда как HSA больше похоже на след. шаг после OpenCL. (аля собираем устройства в контекст, пишем код (там задаем __kernel бла-бла-бла для точки входа) (объекты, очереди, и прочее опускаю). Так вот, описанное ядро(написанный CL код) можно одинаково выполнить как на CPU так и на GPU). Так вот, если в OpenCL ты задаешь на каком устройстве код будет выполняться, то hsa это уже все берет на себя сама (можешь загуглить например hsa bolt library).
Например ты написать на hsail код для cpu, потом на том же hsail написать вертексный шейдер и.т.д.
Надеюсь я понятно написал, сам себя понял, понимаю данный топик...
>[оверквотинг удален]
> задач, тогда как HSA больше похоже на след. шаг после OpenCL.
> (аля собираем устройства в контекст, пишем код (там задаем __kernel бла-бла-бла
> для точки входа) (объекты, очереди, и прочее опускаю). Так вот, описанное
> ядро(написанный CL код) можно одинаково выполнить как на CPU так и
> на GPU). Так вот, если в OpenCL ты задаешь на каком
> устройстве код будет выполняться, то hsa это уже все берет на
> себя сама (можешь загуглить например hsa bolt library).
> Например ты написать на hsail код для cpu, потом на том же
> hsail написать вертексный шейдер и.т.д.
> Надеюсь я понятно написал, сам себя понял, понимаю данный топик...на линуксе это с какого года стало возможным? я именно подчеркнул год, когда это уже использовалось.
например http://qube.ru/news/beos_jubilej_10 OR http://www.osnews.com/story/7265:
"Это единственный известным мне скриншот версии “shark” BeOS, 0.99–EXP (1994) на машине H0bb1t (в ней использовались 6–7 AT&T DSP–процессоров вместо обычных CPU)."
"Here is the only known screenshot of the "shark" version of BeOS, 0.99-EXP from 1994 running on a H0bb1t machine (which used 6-7 AT&T DSPs instead of regular CPUs)."DSP - вместо CPU - это разве узкоспециализированные задачи? понятия GPU тогда еще в природе не было.
BeOS как раз и брала на себя функцию выбирать на каком из них что делать.
Но для этого от программиста не нужно знать никаких специфических для этого языков программирования - ОСь сама этим всем занималась. + ни под какие другие сущности не нужно было переписывать и адаптировать код.
"на линуксе это с какого года стало возможным? я именно подчеркнул год, когда это уже использовалось."насчет OpenCL/CUDA то давно уже через блоб (2010-2011 год, где то так). HSA: "Драйвер "AMD KFD", предоставляющий интерфейс HSA для использования вычислительных возможностей графических процессоров и APU AMD, уже включен в состав ядра Linux 3.19." Но там требования конечно. CPU с ядром kaveri. GPU: GCN. На счет остального не знаю.
"Это единственный известным мне скриншот версии “shark” BeOS, 0.99–EXP (1994) на машине H0bb1t (в ней использовались 6–7 AT&T DSP–процессоров вместо обычных CPU). " - окей, что насчет расширяемости. Если добавить туда еще десяток другой вычислительных устройств (я понимаю что это хардварно не возможно для того времени, но мы абстрагируемся). Сможет ли BeOS работать правильно без изменения кода, и оптимизировать все под различные устройства?
>[оверквотинг удален]
> насчет OpenCL/CUDA то давно уже через блоб (2010-2011 год, где то так).
> HSA: "Драйвер "AMD KFD", предоставляющий интерфейс HSA для использования вычислительных
> возможностей графических процессоров и APU AMD, уже включен в состав ядра
> Linux 3.19." Но там требования конечно. CPU с ядром kaveri. GPU:
> GCN. На счет остального не знаю.
> "Это единственный известным мне скриншот версии “shark” BeOS, 0.99–EXP
> (1994) на машине H0bb1t (в ней использовались 6–7 AT&T DSP–процессоров вместо
> обычных CPU). " - окей, что насчет расширяемости. Если добавить туда
> еще десяток другой вычислительных устройств (я понимаю что это хардварно не
> возможно для того времени, но мы абстрагируемся).расширяемость это уже другой вопрос. в топике с расширяемостью тоже не все очевидно и понятно.
> Сможет ли BeOS работать
> правильно без изменения кода, и оптимизировать все под различные устройства?я этого знать не могу - исходников не видел и не знаю как спроектирована архитектура ядра.
вероятнее всего что под каждую специфику железа писалось что-то на подобие драйвера или модуля.
знаю точно что работала BeOS на полноценных, в теперешнем понимании, гетерогенных системах, значит либо все было спроектировано с учетом такого использования, либо дописывалось по мере необходимости, ведь они одни из первых занимались портированием своего ядра под другие архитектуры.
Какого уровня это виртуализация? Это - не гипервизор, насколько я понимаю?
> Какого уровня это виртуализация? Это - не гипервизор, насколько я понимаю?--Я свидетель! А где здесь "виртуализация"?
Кагбэ, если программная прослойка выполняет функции упрощения работы пользовательского(?) ПО с железом, то это, на мой взгляд, виртуализация оборудования. Вопрос: топик - это гипервизор, в котором можно запустить ядро ОС, или фреймворк для разработки пользовательского ПО?
Фреймворк. И виртуализация (т.е. предоставление приложению "псевдо-устройства") там и рядом не лежала
> Фреймворк. И виртуализация (т.е. предоставление приложению "псевдо-устройства") там
> и рядом не лежалаТо есть, в коде приложения будет вызов вида HSA.math("2 * 2"), а реализация HSA выберет физическое устройство для вычисления результата самостоятельно?