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 ()
Последнее исправление: question4 (всего исправлений: 1)

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

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

сколько кто в процентах разрабатывал не знаю

In addition, we worked on the specification of Scalable Vector Extension (SVE) as a lead partner of Arm Limited, the result of which has been adopted

Кроме того предлагаю попробовать ответить на вопрос засчет чего в топ500 набиваются основные флопсы. Я бы предположил, что голые флопсы там идут из ГПУ, а вовсе не от ЦПУ.

Fugaku на первом месте и у него нет никаких дополнительных GPU

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

но проигрывают по энергоэффективности

В том-то и дело, что x86 *выигрывает* по энергоэффективности. И при этом рвет в клочья кукурузный арм.

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

По IPC интеловские ядра начали сливать ядрам от яббла еще в 2017-2018 годах. Это было не так заметно, тк на десктопе/сервере павер енвелоп не так ограничен, как в мобильном сегменте и благодаря лидерству в техпроцессе можно было кочегарить ядра на 5+ггц.
Яблочный M1 весьма хорош.
А вот AVX модуль, который жрет дофига места и павера на кристалле и редко когда бывает нужен по-настоящему(тут лучше Линуса послушать) я бы и правда перестал всюду пихать.

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

Ох, Вася, ну давай я это сделаю разок за тебя:

Here is a brief rundown of current top 10 systems:

- Fugaku remains at the top spot, growing its Arm A64FX capacity from 7,299,072 cores to 7,630,848 cores. The additional hardware enabled its new world record 442 petaflops result on HPL. This puts it three times ahead of the number two system in the list. Fugaku was constructed by Fujitsu and is installed at the RIKEN Center for Computational Science (R-CCS) in Kobe, Japan.
- Summit, an IBM-built system at the Oak Ridge National Laboratory (ORNL) in Tennessee, remains the fastest system in the US with a performance of 148.8 petaflops. Summit has 4,356 nodes, each one housing two 22-core Power9 CPUs and six NVIDIA Tesla V100 GPUs.
- Sierra, a system at the Lawrence Livermore National Laboratory in California, is ranked third with an HPL mark of 94.6 petaflops. Its architecture is very similar to that of Summit, with each of its 4,320 nodes equipped with two Power9 CPUs and four NVIDIA Tesla V100 GPUs.
- Sunway TaihuLight, a system developed by China’s National Research Center of Parallel Computer Engineering & Technology (NRCPC) and installed at the National Supercomputing Center in Wuxi, is listed at number four. It is powered exclusively by Sunway SW26010 processors and achieves 93 petaflops on HPL.
- At number five is Selene, an NVIDIA DGX A100 SuperPOD installed in-house at NVIDIA Corp. It was listed as number seven in June but has doubled in size, allowing it to move up the list by two positions. The system is based on AMD EPYC processors with NVIDIA’s new A100 GPUs for acceleration. Selene achieved 63.4 petaflops on HPL as a result of the upgrade.
- Tianhe-2A (Milky Way-2A), a system developed by China’s National University of Defense Technology (NUDT) and deployed at the National Supercomputer Center in Guangzho, is ranked 6th. It is powered by Intel Xeon CPUs and NUDT’s Matrix-2000 DSP accelerators and achieves 61.4 petaflops on HPL.
- A new supercomputer, known as the JUWELS Booster Module, debuts at number seven on the list. The Atos-built BullSequana machine was recently installed at the Forschungszentrum Jülich (FZJ) in Germany. It is part of a modular system architecture and a second Xeon based JUWELS Module is listed separately on the TOP500 at position 44. These modules are integrated by using the ParTec Modulo Cluster Software Suite. The Booster Module uses AMD EPYC processors with NVIDIA A100 GPUs for acceleration similar to the number five Selene system. Running by itself the JUWELS Booster Module was able to achieve 44.1 HPL petaflops, which makes it the most powerful system in Europe
- HPC5, a Dell PowerEdge system installed by the Italian company Eni S.p.A., is ranked 8th. It achieves a performance of 35.5 petaflops using Intel Xeon Gold CPUs and NVIDIA Tesla V100 GPUs. It is the most powerful system in the list used for commercial purposes at a customer site.
- Frontera, a Dell C6420 system that was installed at the Texas Advanced Computing Center of the University of Texas last year is now listed at number nine. It achieves 23.5 petaflops using 448,448 of its Intel Platinum Xeon cores.
- The second new system at the top of the list is Dammam-7, which is ranked 10th. It is installed at Saudi Aramco in Saudi Arabia and is the second commercial supercomputer in the current top 10. The HPE Cray CS-Storm systems uses Intel Gold Xeon CPUs and NVIDIA Tesla V100 GPUs. It reached 22.4 petaflops on the HPL benchmark.
Класс, давайте поможем Васе посчитать, сколько из топ10 суперкомпьютеров используют ГПУ?

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

сколько из топ10 суперкомпьютеров используют ГПУ?

какая разница, на первом месте Fugaku с огромным отрывом

This puts it three times ahead of the number two system in the list

по-моему он производительный всех оставшихся в списке топ-10 вместе взятых.

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

с 2017г вообще-то вышли tiger lake и zen3

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

я много чего пробовал. даже alliance пытался собрать но там видимо совсем полный трэш. это просто убивает - сто разных плееров аудио и ни одной приложухи где надо просто по сетке по сути расставлять объекты.

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

давай сам гугли. автор doug little, все форумы по atari его знают, ссылки на скачку битые. хз где его искать.

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

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

где-то даже описывал как делаетcя освещение - это древняя техника с lookup tables

К сожалению, не находится.

Еще одна реализация 3d на atari 030 - doom bad mood https://www.youtube.com/watch?v=MUWJSUiPXzw

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

panzerito
()
Последнее исправление: panzerito (всего исправлений: 2)
Ответ на: комментарий от panzerito

так это тот же самый автор.

освещение так делали много где. у тебя есть тектура палитровая. допустим в ней 32 цвета. ты выбрал тексел и знаешь уровень освещения. допустим там 16 градаций.

у тебя есть 32*16 вариантов конечного цвета,и ты просто составляешь из значения тексела и яркости значение в таблице где содержатся конечные цвета.

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

я так скажу - если бы этот атариквак вышел тогда, в 1992м, мир 3д-игр мог бы быть другим.

32/24/16-бит fixed point на самом деле ведь может быть дополнена известной compile-time экспонентой, которая дается в команде. то есть многое из того, что делается даже сейчас возможно сделать в fixed point. тот же кризис портировать, главное чтоб мощности dsp хватило. или количества dsp.

16 - хватит для моделек. с точностью 1мм. их же хватит для матриц поворота.

32 - хватит для промежуточных данных c точностью для сцены размером 64км по каждому направлению.

24 - наверно для сцены размером те же 64км в формате 16.8 или 4км в формате 12.12. но это довольно большие сцены.

я даже не удивился бы, если бы floating point так бы и оставался уделом научного софта.

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

Жаль, что Doug Little не опубликовал исходники ни Quake 2 on Falcon030, ни BadMood. Или я плохо искал.

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

32/24/16-бит fixed point на самом деле ведь может быть дополнена известной compile-time экспонентой, которая дается в команде.

Не понимаю, как этот трюк изменит ограничения физической разрядности dsp.

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

надо ставить eDP и lvds, а всё остальное - для поехавших.

Сам ты [слово], если интерфейс с матрицей размещать в GPU то это существенно сузит круг возможных используемых FPGA и не менее существенно поднимет планку для разрабатываемых чипов, потому что в твоём варианте чип или FPGA должны будут иметь патентованный видеорот(HDMI/DP) и большой скоростной DAC, расположение которго на стороне видеокарты есть анахронизм от времён VGA мониторов.

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

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

я напомню что квак нормально шел только на пентиумах. его даже k6 не тянул толком причем не помогало даже внеочередное исполнение, т.к. fxch на пне было zero-cost, а на k6 - вполне себе инструкцией да еще и вносило зависимость по данным.

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

А что, матрица может самостоятельно запоминать и воспроизводить изображение?
(про eDP в основном пишут про скорость и число линий, а так по принципам организации там вроде всё аналогично vga, на карте dac, из него в матрицу идёт то, что будет в данный момент показывается на экране)

Ну ок, сейчас почитал ещё раз, я правильно понял что eDP это последовательный порт через который в матрицу идут обновления кадра?

Но даже если это так, то лучше бы он был универсальной шиной вроде scsi, без каких либо специальных особенностей под конкретное устройство.

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

дело не в разрядности а в том, что для графики надо очень много множить и складывать. cpu того времени множили как говно, 12 тактов. cyrix486dlc помоему 3 такта умел но 16х16 но +сложение + movmovmov короче всё равно скорость была дном. даже деление можно делать умножением довольно точно и быстрее аппаратного деления при условии что у тебя умножение хотя бы два цикла а лучше - сразу параллельно конвейеру в отдельный аккумулятор откуда можно mov потом.

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

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

Не спорю, можно. Но зачем?
На гитхабе есть несколько примеров открытых (ГП)ГПУ разной степени завершенности: и MIAOW, и Nyuzi.
И, если мы уж говорим про запиливание yet another GPU, я бы сказал, что самая сложная и болезненная часть - вовсе не железо. С железом, как показывает практика, могут справиться студенты нормального вуза с нормальным ментором над ними, а вот прикрутить к этому весь софтварный стек - БОЛЬ. Вдвойне боль - сделать так, чтобы этот софт работал быстро.

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

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

если бы эта демка вышла на atari хотя бы в 1995м - поменялось бы многое. если бы она вышла в 1992м - возможно у нас бы было другое железо. сильно другое.

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

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

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

использоваться float для графики.

Но ведь fixed point для тригонометрических функций будет давать неравномерную ошибку. Какой трюк это исправит?

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

Хочу увидеть исходники 3d engine на чистых fixed point. Quake 2 для атари это хорошо, но исходников нет, а верить пересказам о внутреннем устройстве не нравится.

У atari Falcon030 есть fpu, кстати.

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

во-первых, не факт что ошибку будет видно.

алгоритм вычисления берется из тригонометрических функция для sse - там формула тейлора первые два члена(для cos 1+), а перед ней умножение и некоторое издевательство над числами с хитрожопым округлением.

в пределе 4(2x/pi)^3-2(2x/pi) даст ~~ 4(1+a)^3 где а - влезшие биты которы должны быть, т.е. 1/16384. это где-то 12/16384 ну пусть будет 1/1024 по царски оценим. и на сколько её надо умножить, чтоб вышел хотя бы один пиксель?

если у нас моделька в формате координат 4.12 (размером 16 метров по каждому направлению), то в пределе будет 1/256 метра. домножим на 3 и получим полную ошибку 0.003 метра для одного преобразования.

это в нищенских 16 битах. если будет 32 бита, то точности с запасом хватит на несколько преобразований такого плана.

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

да более того. на 24 битах уже в принципе можно «кризис» сделать. нужно всего-то в инструкции добавить поправку «экспоненты» явную, то есть на DSP от атари не взлетит.

но допустим шобла из хм…. 1000 например атаревских DSP с улучшениями может и потянуть кризис на минималках в 320х240.

salozar
()

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

люди фундаментально не понимают, как работают GPU. напрочь.

Pixel Instructions –SetPix/ClrPix/GetPix –Blend –Ztest –ROP
/dev/disk/facepalm

на самом деле ROP (у амд это экспорт пикселя из шейдера) перекрывает SetPix и Blend одновременно.

ClrPix - это как вообще понимать? Они не знают как очищаются буфера? Хотя не, они явно что-то иное имели ввиду:

•Frame Buffer Instructions –SetZ/ClrZ–SetArea/ClrArea
Помоему они наркоманы. Как можно «очистить пиксель»? он при чтении будет сегфолт возвращать или что? Иначе чем это отличается от записи в пиксель

Ztest - simd операция сравнения и получения маски, зачем городить лишнее? уж если так хотят, пусть сделают compare mode для Z-текстур чтоб аппаратуру не дублировать, оно самое будет.

Texture Instructions –Tex2d, Tex3d –TexEnv –TexGen –MipMap –Persp –TexLoad –TexCodec
$ ls /dev/input facepalm0 facepalm1 facepalm2 facepalm3

Они где-то нашли мануал по opengl и просто оттуда переписывают все функции которые находят.

TexLoad, TexEnv, TexCoded - я могу догадываться, что речь идёт о загрузке инфы о текстуре в некий регистр, но помоему настройки текстуроблока можно загрузить просто записывая в некие аппаратные регистры. Может я ошибаюсь?

Persp - я не знаю что это такое, но перспективная коррекция делается на шейдерах как и создание мипмапов.

И тут я увидел вот это

Optional Graphics Instructions (micro-coded) –ModelView –Backface –Lookat –Proj –Clip2/Clip3 –Lit (a,d,s) –Persp–InterpStep (i.e. Bresenham DDA or scanline attributes) –Window –TexMap–Z-Test –AlphaBlend –FragMerge 

PANIC: unable to handle facepalm at kernel/wtf.c:105 whatiswrongwiththem+0x07/0x40

и все вопросы отпали. модел,мать его,виев.

–Persp–InterpStep (i.e. Bresenham DDA or scanline attributes)

слов нет. вот как это делают здоровые люди, не курильщики.

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

на самом деле ROP (у амд это экспорт пикселя из шейдера) перекрывает SetPix и Blend одновременно

ROP использует данные в локальной памяти

The ROPs perform the transactions between the relevant buffers in the local memory – this includes writing or reading values, as well as blending them together.

https://en.wikipedia.org/wiki/Render_output_unit

а Blend работает с фреймбуфером

https://community.khronos.org/t/does-the-gpu-process-the-blending/31914

normal rendering, the GPU does : -compute pixel color -write to FrameBuffer

blending requires the GPU to do : -compute pixel color -read framebuffer -do blending operation between src and dst -write to FrameBuffer

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

а Blend работает с фреймбуфером

а фреймбуфер в облаке а облако в амазоне. внезапно фреймбуфер это просто буфер в памяти. он не лучше и не хуже других буферов

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

внезапно фреймбуфер это просто буфер в памяти. он не лучше и не хуже других буферов

только ты путаешь быструю локальную память SRAM (кэш) и фреймбуфер во внешней медленной DRAM - ROP работает с фрагментами в локальной быстрой памяти.

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

а разве не все обращения к памяти идут через кэш

GPU это конвеер, чем реже обращается к внешней памяти тем быстрей обработка

https://images.bjorn3d.com/Material/revimages/articles/Fermi/e19.jpg

возможно они просто разделили комплексную ROP на микрооперации и с blend из opengl это не связано

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

так SRAM или кэш?

кэш делают в SRAM

растеризатор имеет свой кэш если что

L2 кэш общий если что. Кстати - разобрался для чего новый тип данных ? или «здоровым» людям матричные типы не нужны - нужно только насрать из-под тишка.

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

кэши могут быть разные. на первых GCN и до них у амд кэш второго уровня был read-only и ничего туда ROPы не писали, довольствуясь своим личным небольшим кэшиком.

никому в AMD в голову бы не пришло, что оказывается для экспорта пикселя нужно две разные инструкции, в зависимости от того, лежит он в кэше или нет(видимо это надо угадать).

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

во-первых, не факт что ошибку будет видно.

алгоритм вычисления берется из тригонометрических функция для sse - там формула тейлора первые два члена(для cos 1+), а перед ней умножение и некоторое издевательство над числами с хитрожопым округлением.

в пределе 4(2x/pi)^3-2(2x/pi) даст ~~ 4(1+a)^3 где а - влезшие биты которы должны быть, т.е. 1/16384. это где-то 12/16384 ну пусть будет 1/1024 по царски оценим. и на сколько её надо умножить, чтоб вышел хотя бы один пиксель?

если у нас моделька в формате координат 4.12 (размером 16 метров по каждому направлению), то в пределе будет 1/256 метра. домножим на 3 и получим полную ошибку 0.003 метра для одного преобразования.

это в нищенских 16 битах. если будет 32 бита, то точности с запасом хватит на несколько преобразований такого плана.

А в чём проблема быстро вычислять обратный корень на Atari? И зачем для вычисления отражения кваке плавающая точка?? Да и мегатекстура это уже квака4.

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

целых три мегатупых вопроса в одном посте. как вам удаётся?

Да у меня есть в книжке «Параллельные вычисления на GPU» Архитектура и программная модель CUDA издательства МГУ уравнение трассировки лучей. И даже про рендерер Hydra на openCL из ВМиК МГУ. Я просто так спросил. И ещё я слышал, что в Кваке3 «честные» круглые поверхности, без всяких приближений по точкам, не знаю как они ухитрились.

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

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

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

Да вот и мне интересно что такое быстрый обратный корень в double. В википедии написано только про float!

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