Открытый графический ускоритель ORSoC Graphics Accelerator

А зачем он нужен без унифицированного апи? Ну хотябы OpenGL ES.

API предоставляется драйвером, например Gallium 3D. Драйвер преобразует команды OpenGL (ES) в последовательность команд для процессора(ов) карты (обычно он(и) VLIW). От карты требуется достаточно полный и хорошо документированный набор команд, не более. Команды могут быть почти любыми.

Я не понимаю, в чем смысл реализовывать непосредственно всякие графические фичи.

Почему нельзя реализовать OpenCL для него, и уже поверх него делать OpenGL?

Вопрос в том, на какой частоте оно потом сможет работать. Здесь размер и свойства логических элементов, а так же топология чипа играют немалую роль.

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

А насколько реально подобные «тёмные» дела вести в том же i2p?

Нереально. Это масштабные МАТЕМАТИЧЕСКИЕ проекты, ими занимаются в основном аспиранты и магистранты в таких местах, как Berkeley, на этом пишутся диссертации. Обычно все выглядит так: пишется код, защищается диссертация, часть кода открывается. Остальной код либо никому не показывают, кроме научрука, либо он идет во всякие Xilinx ISE и Synplify.

Открытого кода довольно много, но он «исследовательского» типа - для сферической FPGA в вакууме. Можно моделировать, но нельзя залить в реальную железку. Для ASIC в принципе тоже можно использовать, но это погоды не делает.

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

Эм... Без API, прозрачно интегрирующего его с Xorg/GTK3/Qt4 оно бесполезно. А с такой производительностью это тянет только на студенческий проект.

API предоставляется драйвером, например Gallium 3D. Драйвер преобразует команды OpenGL (ES) в последовательность команд для процессора(ов) карты (обычно он(и) VLIW). От карты требуется достаточно полный и хорошо документированный набор команд, не более. Команды могут быть почти любыми.

Хороший пост.

Без API, прозрачно интегрирующего его с Xorg/GTK3/Qt4 оно бесполезно.

Какое нужно API? Драйвера DRI достаточно? В отдалённых планах. Оно ориентировано на плату для встраиваемых систем, поэтому пока фреймбуфер.

А с такой производительностью это тянет только на студенческий проект.

А из этих видео вообще нельзя оценивать производительность.

Взгляд со стороны.

Качество конечно, да, не иначе месяц, а то и больше просчитывались эти впечатляющие, трогающие за душу сцены. Может я чего-то не понимаю конечно, но даже на 8-битных процессорах в недалеком прошлом работало не медленнее.. Наверняка найдутся те, кто помнит простые игры типа трехмерного танка (8-битные компьютеры) и первого меч вариорс (правда уже на 286-х). Причем во второй когда-то рубились также как в цивилизацию ибо сюжет присутствовал.

Давайте будем откровенны. Речь не об ускорителе, а о принципиальном освоении начальных представлений о графике конкретной группой студентов. Это все равно, что любой из вас будет хвалится, что прочитал еще пару глав какой-нибудь научной хрени и на коленке за полчасика сваял модельку чего-то там, чтобы просто посмотреть как оно.

В общем большая новость - целый проект, осиленый не больше не меньше двумя шведскими студентами. Будь то наши ребята - все молчали бы в тряпочку ибо стыдобища такое показывать.

Качество конечно, да, не иначе месяц, а то и больше просчитывались эти впечатляющие, трогающие за душу сцены.

Да, демки слеплены наспех. Но новость не о роликах, а о железке, которая их выводит на экран.

Речь не об ускорителе, а о принципиальном освоении начальных представлений о графике конкретной группой студентов.

Нет. Речь всё-таки об ускорителе :)

Будь то наши ребята - все молчали бы в тряпочку ибо стыдобища такое показывать.

Покажи проекты ваших ребят.

Может я чего-то не понимаю конечно, но даже на 8-битных процессорах в недалеком прошлом работало не медленнее..

Камменты не читай @ быстрее отвечай.

Код на HDL достаточно высокоуровневый. Разумеется, непосредственно перед синтезом можно какие-нибудь мелочи подоптимизировать под конкретный компилятор.

Код-то высокоуровневый, только оптимальный код существенно зависит, например, от конструкции ячейки FPGA: если там 4-входовые LUT'ы, а надо комбинационную схему с 6 входами, то лучше использовать конвейеризованный вариант, если это возможно, а если 6-входовые LUT'ы, то никакого конвейера не надо. У меня большие сомнения, что синтезаторы когда-нибудь научатся эффективно конвееризовывать схемы. Как показывает мой личный опыт, если делать без учета особенностей FPGA можно получить 100-150 МГц на Xilinx Spartan-3E, если учитывать, то 250-300 МГц (разумеется, приведенные числа ориентировочные, для одного из моих проектов). Но это все касается FPGA, и возможно, в какой-то степени для ASIC (тех, что имеют набор готовых блоков, заказчик только меняет трассировку соединений).

Ускоритель уже умеет

Еще пару лет и до Amiga OCS доберется.

Да, демки слеплены наспех. Но новость не о роликах, а о железке, которая их выводит на экран.

Я так и не понял чем выдающимся отличается данная железка.

Нет. Речь всё-таки об ускорителе :)

Ускоритель должен ускорять. Или я не прав? А тут две фамилии неосиляторов.

Покажи проекты ваших ребят.

Хороший вопрос - в точку. Моих ребят нет, есть Вы, я и остальные посетители лора, и многие еще в детстве наэкспериментировались с математикой. А бедные отечественные студенты, как известно, решают молча серьезные задачи, чтобы им галочки поставили в зачетках, коли денег нет на проплату сессий;) Или Вы с других краев и не в курсе?))

Код-то высокоуровневый, только оптимальный код существенно зависит, например, от конструкции ячейки FPGA: если там 4-входовые LUT'ы, а надо комбинационную схему с 6 входами, то лучше использовать конвейеризованный вариант, если это возможно, а если 6-входовые LUT'ы, то никакого конвейера не надо. У меня большие сомнения, что синтезаторы когда-нибудь научатся эффективно конвееризовывать схемы.

Не далее как вчера находил статейки на эту тему. Вкратце: наработки, в том числе и по конвейеризации - есть, но их внедрению мешает отсутствие возможности (патентной в первую очередь) создания доступной для редактирования математиками инфраструктуры кремниевых компиляторов. Фактически, все, что опубликовано - это SIS, ABC, ну и VPR, а все остальное в статьях упоминалось, но не релизилось. Тот же qFlow/tFlow - очень серьезная разработка на эту тему, но рискует заглохнуть.

Icarus Verilog уже глохнет - с версии 0.9 оторвали синтез, сделали чистый симулятор. А смысл синтезировать, если база данных на чипы в закрытом формате, и синтез возможен только под вымышленную FPGA?

Ну не обязательно OpenCL. Достаточно просто умения запускать произвольную программу в много потоков параллельно.

Дай поерничать спокойно над шведами)

Я так и не понял чем выдающимся отличается данная железка.

Единственный на сегодня живой проект открыто-свободного видеочипа.

Ускоритель должен ускорять.

Тему всё-таки стоит прочитать. По этим демкам невозможно оценивать скорость. Автор обещает снять нормальную, как только допишет диплом. А заодно портировать Jump'n'Bump.

бедные отечественные студенты ... решают молча серьёзные задачи

Я просил примеры. Где примеры?

Нормальная разработка, на уровне какого-нибудь SSD1928. Это не для крузисов, а для маломощных встраиваемых SoC, чтобы процессор не напрягать отрисовыванием каждой точки интерфейса в промышленных контроллерах, бытовых приборах и т.п.

По поводу темы в курсе, просто все в таком зачаточном состоянии до сих пор, что жуть берет. И абсолютно не верится, что из этого может что-нибудь получится. А примеры лучше в институтах и университетах поспрашать;)

даже в самых убогих AT91 есть акселерация 2D, которую поддерживают иксы если не ошибаюсь

50 mhz выдавал первый вуду (1996 год), которого хватало для прорисовки третьей кваки. а что сможет это, хотя бы в ближайшие 3 года?

50 mhz выдавал первый вуду (1996 год),

Выше вроде бы объясняют, что никаких ограничений на частоту нет. Какой FPGA возьмёшь, столько и будет.

которого хватало для прорисовки третьей кваки. а что сможет это, хотя бы в ближайшие 3 года?

Посмотрим. Если будет развиваться — наверняка и Квейки будут. По крайней мере, для прикола попробуют запустить :)

А примеры лучше в институтах и университетах поспрашать

То есть примеров не знаешь :)

По поводу темы в курсе, просто все в таком зачаточном состоянии до сих пор, что жуть берет.

Проект на OpenCores создан в марте.

Их в комментариях спрашивают, предельная ли это скорость. Пока не ответили.

они ответили прямо под видео. Разуй галаза:

«The lags is due to delays in test application». Как-то так.

Думаю, да, если прикрутить субж к микроблейзу и залить в плис, то что-то вроде ат91 и получится. Поддержка иксами - вопрос к иксам.

Выше вроде бы объясняют, что никаких ограничений на частоту нет. Какой FPGA возьмёшь, столько и будет.

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

Значит состарится точно не успели. А разве других попыток не было?

То есть примеров не знаешь :)

Я еще не настолько стар, чтобы выдавать страшные тайны))

Не далее как вчера находил статейки на эту тему. Вкратце: наработки, в том числе и по конвейеризации - есть, но их внедрению мешает отсутствие возможности (патентной в первую очередь) создания доступной для редактирования математиками инфраструктуры кремниевых компиляторов.

Думаю, что задача оптимизации произвольного говнокода на Verilog не разрешима принципиально. Точно так же, как неразрешима задача оптимизации произвольного говнокода на C. Под оптимизацией я понимаю истинную оптимизацию, то есть построение, например, самой быстрой программы, эквивалентной данной. То что сейчас называется оптимизацией --- это некоторый «улучшайзинг», не более. Да люди работают, и многие методы этого «улучшайзинга» весьма и весьма сложны, но тем не менее это всего лишь «улучшайзинг». Время от времени я слышу восторженные возгласы: сегодня компиляторы все сделают за вас, не думайте особо, пишите говнокод. Но ни один существующий компилятор не превратит пузырьковую сортировку в быструю. Ты скажешь: так ведь это же различные алгоритмы! А где формальная граница между «другим алгоритмом» и «оптимизированной программой»? Безусловно, я могу ошибаться, и когда-нибудь мы увидим истинно оптимизирующие компиляторы.

Вообщем, мысль моя следующая: на сегодняшний день слова «если какой-то код на Verilog синтезируется в плохую схему --- это значит, что компилятор говно» выглядят как громкий лозунг; если хочется выжать из кристалла почти все, а не просто заставить схему работать абы-как, придется напрячь мозги и написать код с учетом особенностей целевого кристалла.

Icarus Verilog уже глохнет - с версии 0.9 оторвали синтез, сделали чистый симулятор. А смысл синтезировать, если база данных на чипы в закрытом формате, и синтез возможен только под вымышленную FPGA?

Что касается именно синтеза, а не размещения/трассировки, то соответствующие инструменты из Xilinx ISE, например, могут считать нетлист созданный другим синтезатором, и одним из входных форматов является EDIF, который вполне открыт. На крайний случай можно генерить на выходе структурный Verilog c примитивами FPGA (такими как LUT и FF) и скармливать его xst, в этом случае xst будет играть роль простого конвертера форматов. Внутренняя структура ячейки FPGA не является тайной и вполне подробно описана у того же Xilinx'a. Структура внутренних межсоединений действительно не специфицирована (все характеристики межсоединений описаны в закрытом формате), что препятствует созданию открытых инструментов трассировки (но не синтеза!). Проблема с Icarus Verilog, насколько я понимаю, связана вовсе не с невозможностью синтеза для реальных FPGA, а в том, что у них сейчас приоритет сделать поддержку Verilog-2001 и в процессе достижения этой цели они сломали синтез. Поскольку заинтересованных в синтезе не нашлось, то он до сих пор и находится (вроде бы) в сломанном состоянии.

Боюсь сказать, но Geforce GT440 стоит $100, и выдает плавную картинку.

Я про другое - новый стандарт без оглядки на совменстимость со старыми технологиями, а только на последние разработки. Это бы сэкономило место на чипсете (однако после того что написал мне Yampp насчёт низкоуровневых инструкция, я сомневаюсь, что сильно) и позволило рисовать графику нового уровня, который ближе к фотореалистичности, чем OpenGL и Direct3D. У меня и NVIDIA GeForce 2 выдаёт плавную картинку, на играх 2001 года.

Вот только отладка технологии в кремнии очень сложна и дорога, требует изготовления нескольких тестовых партий, чтобы хотя бы просто работало. Особенно аналоговые схемы (GSM). Кроме того, серийные чипы оптимизируются вручную, чтобы сэкономить на кремнии для их выпуска.

http://2.bp.blogspot.com/-vROXfddSoI0/TzesAtYSOuI/AAAAAAAAB1A/Vrai5Z8J5QA/s16... Архитектура современного GPU. Он весь состоит из шейдерных процессоров и кэшей, остальное занимает совсем мало места. Шейдерные процессоры нужны для современных игр и CUDA/OpenCL

Частота современного жефорса - 900mhz. Разница всего в 18 раз. Так что не в частоте дело :)

они ответили прямо под видео

Ага, уже нашёл. А под другим видео пообещали снять нормальный ролик, из которого будет видно реальную скорость. Когда допишут магистерскую диссертацию.

А разве других попыток не было?

См. выше. Из тех, что я нашёл, 2 — Project VGA и Open Graphics Project — даже сумели выпустить кое-какое железо. Но сайт Project VGA давно исчез, а карты по словам автора были нерабочие. Главная же страница сайта Open Graphics не обновлялась с осени 2010-го, а в их вики сейчас пишут только спамеры. По ссылке на Фороникс есть ссылка на их недавний «некролог»: http://www.phoronix.com/scan.php?page=news_item&px=MTEwNTQ .

Фирма считает, что пара сотрудников, которые знают какой стороной ПЛИС вставляется в программатор им не повредит.

Фирма считает, что пара сотрудников, которые знают какой стороной ПЛИС вставляется в программатор им не повредит.

Возможно. А возможно им нужны люди, которые будут пилить графику в продаваемой ими SoC.

Ну так и я про тож. Этот проект чем хуже после того как эти студенты защитят дипломы?

Вообщем, мысль моя следующая: на сегодняшний день слова «если какой-то код на Verilog синтезируется в плохую схему --- это значит, что компилятор говно»

Тут правильнее сказать так: «Если код на Verilog, написанный в хорошем стиле, с правильным использованием конструкций, но при этом без привязки к какой-либо конкретной архитектуре, каким-то определенным компилятором синтезируется в плохую схему - значит, компилятор говно.» Тут обязательно надо рассматривать всю связку синтез+map+par как целое. Неважно, какой там в середине получается EDIF, если в конечном итоге получается хорошая/плохая схема.

Я видел вполне конкретную проблему Quartus на MAX7000 (из-за которой в итоге ушел к конкурентам): сначала он рассовывает схему по макроблокам, а потом удивляется, что на их соединение приходится тратить еще вдвое больше макроблоков. Конечно, CPLD - не FPGA, но нельзя же так тупить. На Xilinx такой проблемы не было, а у Lattice MachXO2 вообще не CPLD, а FPGA со встроенным флешом на самом деле. По электрическим характеристикам выбрал Lattice.

Что касается именно синтеза, а не размещения/трассировки, то соответствующие инструменты из Xilinx ISE, например, могут считать нетлист созданный другим синтезатором, и одним из входных форматов является EDIF, который вполне открыт.

Вот тут и начинается проблема. Ключевой момент оптимизации - как раз момент генерации EDIF. Современные FPGA имеют неоднородную структуру, в них 2-3 вида LUT и куча вспомогательных блоков. «Свернуть» обратно в такие блоки произвольный EDIF в общем случае очень тяжело, это NP-полная задача. Поэтому все синтезаторы всегда в курсе архитектуры, под которую EDIF делается.

Размещение, строго говоря, задача, неотделимая от синтеза. На стадии синтеза делается значительная ее часть. Ну а трассировка потом - довольно тривиальная вещь, если размещение сделано нормально. Последние наработки используют обратную связь - по результатам готовой трассировки переделывают часть синтеза, tFlow как раз так работает.

Между прочим, от каких старых технологий вы хотите отказаться? OpenGL весь цельный, DirectX тоже достаточно цельный. Или вы хотите выкинуть растровую 2д графику?

Да - если создатели игр поддержат, продажи пойдут. В настоящий момент они даже OpenGL не поддерживают - кроме Unigine Heaven и Rage не знаю игр, которые его используют.

Поскольку заинтересованных в синтезе не нашлось, то он до сих пор и находится (вроде бы) в сломанном состоянии.

Заинтересованные там на рассылках ругаются. Автор ответил: «Поддержки 2001 и более новых стандартов нам до конца жизни хватит, сами свой синтез пишите».

Автору уже присылали даже патчи, чинящие синтез. Не отреагировал никак.

Я в этом отношении больше на ODIN II смотрю, но он что-то пока какой-то тупой сильно. Хотя вроде бы не структурный верилог ему нужен, но даже элементарное inout не берет. Как-то грустно совсем.

И да, все опенсорсное - оно про Xilinx. Потому что у них чип чуть-чуть больше документирован. Чего я совершенно не понимаю - так это почему опенсорсный bitgen до сих пор не сделали. Там же совершенно очевидно во фрейме 1 бит за 1 соединение отвечает, и много раз уже определяли, какой за какое, но потом всегда проекты из инета пропадали. Тот же debit - где он? Я так и не смог скачать его исходники, нету его больше в инете. А он ведь опенсорсный.

Ты скажешь: так ведь это же различные алгоритмы! А где формальная граница между «другим алгоритмом» и «оптимизированной программой»?

facepalm.tar

это лишь примерная схема, я бы на нее не ориентировался

но на месте студентов я бы пилил именно один такой блочек вычислительный, пусть он будет уметь только пару действий выполнять, но это уже шаг

Этот проект чем хуже после того как эти студенты защитят дипломы?

Вопрос в том, будут ли его развивать, или нет. Вроде, собираются продолжать. В отличии от предыдущих проектов, которым приходилось всё делать с нуля, у этого уже есть готовые разработки ORSoC. Значит успеют сделать больше именно по графике, пока энтузиазм не кончился. А там посмотрим, взлетит, или нет.

В настоящий момент они даже OpenGL не поддерживают

Игр использующих OpenGL полный аппстор и гуглплей.

Неполная цитата: я про OpenGL 4.