LINUX.ORG.RU

Свободная графика для RISC-V

 ,


3

5

Группа разработчиков обещает создать расширение RISC-V для работы с графикой. Анонс упоминает троих:

  • Атиф Зафар (Atif Zafar), директор компании Pixilica, выпускающей Arduino-совместимые платы FPGA для разработчиков RISC-V.
  • Грант Дженнингс (Grant Jennings), директор по международному маркетингу GOWIN Semiconductor, выпускающей неколько семейств FPGA (в том числе DSP и микроконтроллеры) и инструментарий для дизайна.
  • Тед Мэрина (Ted Marena), старший директор экосистемы RISC-V в Western Digital и временный директор CHIPS Alliance, разработчика и хостера проектов открытого аппаратного обеспечения.

План предусматривает:

  1. Завершить разработку набора векторных команд «V».
  2. Создать на его базе набор 32-битных инструкций «X» (RV32X) — для обработки изображений и 3-мерной графики, и с добавлением новых типов данных для графики.
  3. Выпустить эталонную реализацию RV32X (в FPGA).
  4. Масштабировать RV32X в 64 бита — RV64X.

Заявленные цели включают:

  • Экономное использование площади чипа.
  • Отсутствие конкуренции с коммерческими предложениями.
  • Ориентация на FPGA, ASIC, микроконтроллеры с низким энергопотреблением.
  • Соответствие DirectX Shader Model 5, OpenGL/ES и Vulkan.

Как видно из рисунка, возможны будут и маломощный процессор RISC-V с единственным графическим блоком, и использование множества таких процессоров в качестве шейдеров большого GPU параллельно с основным процессором RISC-V.

Согласно статье в EE Times будут использованы некоторые идеи Libre GPU.

>>> Презентация о планируемых инструкциях и типах данных

★★★★★

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

А авторах одни ПЛИСеры. Может они и не планируют реализацию в кремнии? Одни САПР для этого стоят как целый завод + куча PHY IP, чтобы хотябы PCIE был. Такие IP стоят как свечной заводик.

Мне кажется, они просто предложат набор комманд и драйверы, а кому надо будут сами себе ASIC или IP рисовать. Тоже неплохо, но не так весело.

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

А авторах одни ПЛИСеры. Может они и не планируют реализацию в кремнии? … Мне кажется, они просто предложат набор комманд и драйверы, а кому надо будут сами себе ASIC или IP рисовать.

Обещают именно для FPGA и ASIC. Но обкатывать всё, явно, будут на FPGA.

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

Как Эльбрусы, дорого и медленно, поэтому и неконкурентно

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

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

Ну в МК может и не нужен PCIE, а если рассматривать как конкурента дискрытным картам, то нужен PCIE или его анлог, а так же HDMI/Display Port и всякие PHY для работы с памятью.

Если что, CPU и GPU тоже скорее бывают SoC или SiP (Ryzen).

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

Зависит от вливаемых денег. Тут на самом деле совсем не важна производительность и фичастость, потому что если не будет крупных игроков - не будет распространённости за пределами узкой специализации. А если будут крупные игроки, то будет и фичастость и производительность и распространённость.

ixrws ★★★ ()

Круто, только вот нормальный fpga стоит как топовая видеокарточка. А производство асиков с такой начинкой будет стоить как завод intel в квадрате.

Нужны универсальные fpga платы из которых торчат 10500 тырточек которую можно прошить как видеокарту, от тырточек отвести пины прямо в vga/hdmi/иное и оно тупо работает. Вот такое было бы круто. А сейчас asic невозможен в адекватной мере, а fpga огороженное убожество оперпрайснутое до небес марса, нужное только там где софтовую задачу перекладывают на железо и экономят время и бабки, но при этом имеют из заранее что-бы вложить.

Идея хороша, реализация интересная, интеллектуальный опыт замечательный. Наработки будут полезны. Только вот с реальностью стыковаться это будет у отдельных людей которые могут себе позволит шиковать покупая fpga прошивая туда видеокарту и распаивая плату под это что-бы выводить на экран openglES2.0 + ещё нужны дрова под это всё.

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

ПЛИС это скучно, когда на них реализуют CPU или GPU. Они будут медленнее и прожорливее в плане тока в сравнеии с ASIC. А идея неплохая, если это окажется жизнеспособным как и сам RISC-V. Тогда будет эталонная медленная реализация GPU на ПЛИС + универсальные драйвера, а производители уже смогут сделать свою быструю реализацию не тратя времени на написание дров. Ну или по крайней мере большей их части. Наверняка то, что касается задания режимов питания будет специфично для каждого производителя.

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

от тырточек отвести пины прямо в vga/hdmi/иное и

имхо это будет ошибкой, надо ставить универсальный быстродействующий порт, например SFP, а DAC и eDP держать на стороне монитора, тогда с одной стороны будет тот или иной универсальный вычислитель с быстрым комуникационным портом, а с другой стороны будет простинькая FPGA с DAC и подключенной по eDP матрице.

В принципе тут даже и особо придумывать не нужно, вычислитель это аналог xlib, а fpga с EDP аналог xorg.

То есть можно начать с того чтобы поселить xorg на удалённом компьютере.

То есть главное это даже не создание ускорителя, а создание быстрого порта для передачи изображения на удалённый xorg.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от anonymous

кстати а почему не существует opensource сапр для хотя бы дизайна?

верификацию вроде как везде требуют при отправке проекта но её можно возложить на какую-нибудь контору. как у нас KM211 например.

а сама разработка-то может идти «приближенным способом». ну там плюс-минут тепловыделение, плюс-минус задержки.

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

наверно надо с этого начать было.

salozar ()

План предусматривает:
Завершить разработку набора векторных команд «V».

зачем. причем зачем в квадрате.

Создать на его базе набор 32-битных инструкций «X» (RV32X) — для обработки изображений и 3-мерной графики, и с добавлением новых типов данных для графики.

зачем в кубе.

Масштабировать RV32X в 64 бита — RV64X.

Им нужно компактное ALU. Для начала. Новые типы данных - не нужны вообще, максимум FP16 и даже это я бы поставил под большой вопрос. Им надо по уму int + fp32 + mmx(16битный цвет в fixed point) + fp64 если получится. Но ума нет, поэтому начинается желание странного.

Распаковка и запаковка пикселей может делаться за пределами кэша(т.к. кэшировать прямо по 16 байт в распакованном виде rgba32i/rgba32f). Ну максимум в fixed point! А интерполяция один хрен делается шейдером, это давно уже у всех так ибо требование DX11. Если они сделают отдельный интерполятор, лучше им не станет, т.к. это по сути будет еще одно ALU, к которому потребуется очередь команд, кэш(ибо тексели надо кэшировать), MMU и короче может оказаться что проще 2 ядра поставить чем отдельный текстуроблок.

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

Могу одну из вероятных причин назвать. Возможно нет опенсорсных САПР потому что фабрики держат в секрете (ну, под NDA) PDK и цифровые библиотеки. Без них ты не сможешь отладить программу. Есть стандарты, но они полузакрытые. Т.е. на словах открытые, а на деле нужно платить членские взносы, чтобы получить к ним доступ (Один из комитетов si2 называется. Я оттуда скачал пару спек, но остальные под замком).

Я бы хотел реализовать свои хотелки в открытой САПР для проектирования ИС, но я не программист. А программисты не знают чего хочу я и пишут очередной фреймворк для других программистов. Не, я могу, конечно, попробовать, но не осилю, да и хрень получится.

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

то что PDK в секрете это вообще дичь.

кое как спасают FreePDK45 и FreePDK15. c ними в принципе и безмасочной литографией(когда уже?????) можно было мутить реально свободное оборудование, и послать нахер всю проприетарь.

а сапр-то можно и сделать. и даже нужно - я поиграл с каденсом 6.10 - за ЭТО разработчики должны доплачивать пользователю. просто сумасшедшее уродство визуально, и работать с этим невозможно никак. Это как если бы исчезли все IDE и программисты свои программы писали в под досом в борланде на CRT мониторах как в 90е.

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

а как нанокад сгодится для разработки асиков?

он DRC умеет проводить? нет. ERC, антенну считать умеет? тоже нет. в GDSII не умеет, в оазис не умеет. А без этого ваш чертеж можно только на стену повесить вместо обоев.

вроде как есть отечественная «симика», но я не тыкал в них.

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

Я работаю в кеденсе. Это реально жесть в плане качества. Глюкавое безумие в котором некоторые части между собой вообще не состыкуются. Т.е. частая ситуация, что GUI не успевает за симулятором и некоторые анализы нужно проводить через подключение нетлиста или прописывать опции симуляции чтобы они работали.

Бывает что его приходится несколько раз в день перезапускать, т.к. возникают всякие странные проблемы. Например иногда кеденс теряет связь между схемой и результатами и не позволяет выводить напряжение тыкая по цепям в схеме. Только недавно стало возможно сохранять параметры рабочей точки транзистора во всех анализах, но всё равно есть проблемы с тем, чтобы потом эти графики вывести для чего либо, кроме DC.

Но это качество, а насчёт удобства не согласен. В целом нормально. Я не работал в других САПР, но тут не вижу каких-то серьёзных проблем в UX. Наоборот очень удобно сделаны некоторые вещи, относительно САПР для приборостроения.

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

Чувак троллит просто. Посмотри его активность.

Симику я тыкал лет пять назад. Помню, что в тестовом проекте на их демонстрационной PDK она как-то странно посчитала токовое зеркало, так, что коэффициент умножения тока был вообще не связан с множителями транзисторов. Мне это не понравилось и на этом я ознакомление закончил.

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

можно было мутить реально свободное оборудование, и послать нахер всю проприетарь.

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

anonymous ()

Соответствие DirectX Shader Model 5, OpenGL/ES и Vulkan

Ого, и я так понимаю всё это будет с открытым исходным кодом или не? Если так, то замах на рубль, зачот, да еще такие API заявили!!! Разумеется, это не только с центральным ядром RISC-V можно использовать, наверняка кому надо отлепят от RISC-V где надо

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

Ого, и я так понимаю всё это будет с открытым исходным кодом или не?

Да.

Если так, то замах на рубль,

Ни разу не видел это словосочетание отдельно от «удар на копейку», явного или подразумеваемого :(

да еще такие API заявили!!!

В обсуждении на Оупеннете предположили, что реально сделают только Vulcan, а остальные — через него.

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

слишком медленная, чтобы pci-e что-то там ограничивал

дело не в медленности устройств - у pcie огромные задержки (десятки наносекунд) на сериализацию/десериализацию, это на порядок больше чем у DRAM, не говоря уже про кэш. Для быстрого интерконнекта в SoC ядра CPU и GPU объединяют на уровне кэшей L2

https://images.anandtech.com/doci/10375/4.%20Tech%20Day%20Bifrost%20FINAL-47.png

https://www.arm.com/products/silicon-ip-system/corelink-interconnect/cci-550

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

План предусматривает: Завершить разрку набора векторных команд «V».

зачем. причем зачем в квадрате

интересно, как ты собрался ускорять что-то без адаптированной для графики ISA. У ARM первые GPU были VLIW, последующие поколения как на десктопах перешли с ILP на TLP, исполняется 16 команд одновременно и для этого нужна своя ISA

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

Зачем пытаться из набора команд для цпу делать мутанта с расширением для обработки графики? Не проще ли отдельную систему команд, пускай и открытую, для этого изобрести?

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

Зачем пытаться из набора команд для цпу делать мутанта с расширением для обработки графики?

в интела так же думали. И проиграли в высокпроизводительных вычислениях всухую

https://www.top500.org/system/179807/

в Fujitsu разработали дополнительный набор инструкций для ARM

The A64FX is the world's first processor to implement Scalable Vector Extension (SVE), an extension of the Armv8.2-A instruction set architecture for supercomputers

https://www.fujitsu.com/global/products/computing/servers/supercomputer/a64fx/

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

Предлагаю быть точным до конца:

в Fujitsu разработали дополнительный набор инструкций для ARM

Не в фуджитсе разработали дополнительный набор инструкций, а ARM в рамках ARMv8-A разработала новое векторное расширение вместо Neon, а фуджитса его реализовала.

Scalable Vector Extension (SVE),

Есть некоторая разница между Vector Extension и набором команд для графики. Векторное расширение для риск5 буквально в конце прошлого года наконец приняли.

в интела так же думали. И проиграли в высокпроизводительных вычислениях всухую

Если мы говорим про векторные расширения, то интел с их широченным AVX, то они наверняка уделывают любые аналогичные решения по raw performance, но проигрывают по энергоэффективности.
Francois Piednoel давно еще году в 2017 говорил, что нет никакого смысла в каждый интеловский чип пихать этот AVX: в мобильном сегменте он совсем не нужен.
Кроме того предлагаю попробовать ответить на вопрос засчет чего в топ500 набиваются основные флопсы. Я бы предположил, что голые флопсы там идут из ГПУ, а вовсе не от ЦПУ. Тот же А21 от интела должен достигнуть экзафлопа исключительно благодаря PVC, а вовсе не фичам процессоров.

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

кстати а почему не существует opensource сапр для хотя бы дизайна?

Существует KLayout и наша контора даже предоставляет под него PDK. Но для цифровой разработки он не годится. Там максимум можно сделать что-то вроде операционного усилителя. В Klayout имеется только редактор топологии, сейчас началась разработка LVS. У нас в конторе тем не менее KLayout используют как просмотровщик GDS, чтобы не ставить Cadence тем, кто в нём ничего не разрабатывает.

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

я поиграл с каденсом 6.10 - за ЭТО разработчики должны доплачивать пользователю

Полностью согласен. Я его использую на работе, и иногда удобнее набить нетлист в консоли и просимулировать в Spectre, чем запускать Schematic. Ещё Cadence умудряется тормозить на 24-ядерном Xeon.

DarthVadimius ★★ ()