LINUX.ORG.RU

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

 , , ,


3

4

На сайте OpenCores обновилась информация о графическом ускорителе, который уже успешно работает в OpenRISC System-on-Chip. Пока в FPGA. Демо на YouTube:

По данным Phoronix, проект разработан шведскими студентами Антоном Фосселиусом (Fosselius, Anton) и Пером Ленандером (Lenander, Per) в рамках магистерской диссертации.

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

  • Рисовать отрезки.
  • Рисовать прямоугольники с заливкой и текстурами.
  • Рисовать треугольники с заливкой, текстурами и интерполяцией.
  • Рисовать квадратичные кривые Безье.
  • Печатать текст растровыми и векторными шрифтами.
  • Использовать при рисовании альфа-сопряжение.
  • Использовать при рисовании цветовые ключи.
  • Рисовать 3-мерные сетки с поддержкой буфера глубины (Z-буфера).
  • Масштабировать и вращать треугольники и векторные шрифты.

Пока поддерживаются следующие графические форматы:

  • Шрифты .TTF.
  • 3-мерные сетки .OBJ.
  • Все растровые изображения, поддерживаемые SDL_image: .BMP, .PNG, .JPG...

Непосредственно для работы с дисплеем CRT или LCD необходим контроллер VGA. Авторы рекомендуют Enhanced LCD/VGA Driver core с того же OpenCores.

OpenGL не поддерживается. В данный момент авторы заняты написанием полноценного драйвера DirectFB под Линукс. И будут признательны, если им помогут сделать DRM/KMS драйвер.

>>> Страница проекта на OpenCores

★★★★★

Проверено: tazhate ()

Ответ на: комментарий от x0r

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

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

Yampp ()

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

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от ifred

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

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

Yampp ()
Ответ на: комментарий от O02eg

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

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

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

Yampp ()

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

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от Yampp

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

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

ktulhu666 ☆☆☆ ()
Ответ на: комментарий от ktulhu666

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

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

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

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

question4 ★★★★★ ()
Ответ на: комментарий от question4

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

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

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

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

glibych ★★ ()
Ответ на: комментарий от glibych

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

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

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

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

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

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

question4 ★★★★★ ()
Ответ на: комментарий от glibych

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

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

atrus ★★★★★ ()
Ответ на: комментарий от Yampp

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

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

anonymous ()

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

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

devl547 ★★★★★ ()
Ответ на: комментарий от question4

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

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

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

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

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

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

glibych ★★ ()
Ответ на: комментарий от anonymous

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

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

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

Yampp ()
Ответ на: комментарий от I-Love-Microsoft

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от glibych

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

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

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

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

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

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

question4 ★★★★★ ()

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от question4

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

glibych ★★ ()
Ответ на: комментарий от question4

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

question4 ★★★★★ ()
Ответ на: комментарий от glibych

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

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

question4 ★★★★★ ()
Ответ на: комментарий от question4

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

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

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

dikiy ★★☆☆☆ ()
Ответ на: комментарий от I-Love-Microsoft

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от question4

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

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

anonymous ()
Ответ на: комментарий от question4

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

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

glibych ★★ ()
Ответ на: комментарий от Yampp

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

Думаю, что задача оптимизации произвольного говнокода на 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 и в процессе достижения этой цели они сломали синтез. Поскольку заинтересованных в синтезе не нашлось, то он до сих пор и находится (вроде бы) в сломанном состоянии.

anonymous ()
Ответ на: комментарий от farafonoff

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

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от Yampp

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

farafonoff ★★ ()
Ответ на: комментарий от ZenitharChampion

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

farafonoff ★★ ()
Ответ на: комментарий от dikiy

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

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

question4 ★★★★★ ()
Ответ на: комментарий от glibych

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

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

question4 ★★★★★ ()
Ответ на: комментарий от question4

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

farafonoff ★★ ()
Ответ на: комментарий от farafonoff

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

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

question4 ★★★★★ ()
Ответ на: комментарий от anonymous

Вообщем, мысль моя следующая: на сегодняшний день слова «если какой-то код на 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 как раз так работает.

Yampp ()
Ответ на: комментарий от ZenitharChampion

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

farafonoff ★★ ()
Ответ на: комментарий от farafonoff

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

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

Yampp ()
Ответ на: комментарий от anonymous

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

facepalm.tar

dikiy ★★☆☆☆ ()
Ответ на: комментарий от farafonoff

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

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от glibych

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

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

question4 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.