ACPI в RISC-V

Не, не могут, там попил на попиле.

Желающих попилить много, попилили - и хватит. Настала пора дать пилить тем у кого нет подозрительных нерусских букв

Графические задачи нормально так параллелились для VLIW

Фиксированный конвеер – да. Шейдеры – не очень. Во всяком случае так утверждается в статье.

VLIW designs are designed to excel at executing many operations from the same task in parallel by breaking it up into smaller groupings called wavefronts. In AMD’s case a wavefront is a group of 64 pixels/values and the list of instructions to be executed against them. Ideally, in a wavefront a group of 4 or 5 instructions will come down the pipe and be completely non-interdependent, allowing every Radeon core to be fed. When dependent instructions would come down however, fewer instructions could be scheduled at once, and in the worst case only a single instruction could be scheduled. VLIW designs will never achieve perfect efficiency in this regard, but the farther real world utilization is from ideal efficiency, the weaker the benefits of VLIW.

But as new games and GPGPU programs have come out efficiency has dropped over time, and based on AMD’s own internal research at the time of the Cayman launch the average shader program was utilizing only 3.4 out of 5 Radeon cores

РИСК - это чужеродное и непонятное. Почти вражеское. Подсознание его не приемлет.

Главное, чтобы алгоритмы и вычисления «приемлили».

Или.. Неужели вы хотите запускать на процессорах подсознание? :D

На ппроцессорах (отечественных) должен запускаться софт (отечественный), а не подсознание (хотя бы и отечественное)

Настала пора дать пилить тем у кого нет подозрительных нерусских букв

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

Конечно рассматривают! Именно заняться реальной разработкой!

И немножечко пилить.

На процессорах должен запускаться софт

Вот именно. Intel и AMD независимо в разное время пришли к тому, что VLIW, как минимум, субоптимален для запуска софта. Поэтому Intel ушли в x86_64, AMD изобрели GCN. ИМХО чем скорее в МЦСТ уйдут с тупикового пути «очень широких команд» (на тот же RISC-V, например), тем скорее они начнут выпускать (на заводах ли в Азии, на полумифическом ли «Микроне» – не столь важно) сколько-нибудь конкурентоспособную продукцию.

Все это слишком сложно. Надо просто работать, а не смотреть на вражеские фирмы.

И немножечко пилить.

И поэтому они уменьшили ширину чтобы лучше вписываться в новые реалии. То что ты не процитировал.

… the average shader program was utilizing only 3.4 out of 5 Radeon cores. Shrinking from VLIW5 to VLIW4 fights this some, but utilization will always be a concern.

В GPGPU VLIW будет плохо себя показывать из-за низкого ILP, а GPGPU нужно чтобы конкурировать с CUDA.

2007 TeraScale 1 (VLIW5)
2007 CUDA
2009 TeraScale 2 (VLIW5)
2010 TeraScale 3 (VLIW4)
2012 GCN 1 # но поезд уже ушёл :)

И поэтому они уменьшили ширину чтобы лучше вписываться в новые реалии

В времена d3d9 и d3d10 было 3.4 из 5. Сколько было бы возможным нагрузить в эпоху Vulkan? И сколько будет «думать» над каждым шейдером компилятор в таком случае? Уменьшение шины – решение «там и тогда», но звоночек для инженеров прозвенел.

Так или иначе. У Эльбруса ЕМНИП VLIW20+. И при этом он даже не OpenCL / HIP код запускает, а хостовый код, с его ожиданиями RAM, многозадачностью, прерываниями и прочими страшными вещами.

Позволь мне ответить цитатой из статьи которой ты тут козыряешь. :)

The fundamental issue moving forward is that VLIW designs are great for graphics; they are not so great for computing.

У Эльбруса ЕМНИП VLIW20+

Нет, в этой терминологии всего лишь VLIW6. Остальные исполнительные устройства, можно сказать, чисто заморочки E2K. Хотя и полезное в них тоже есть.

The fundamental issue moving forward is that VLIW designs are great for graphics; they are not so great for computing.

У Эльбруса VLIW6

Так про что и речь.

Так я ничего против не имею. Просто сделал пояснение из-за необоснованных наездов на TeraScale. :)

robus

Но даже, блин, шейдеры оказалось невозможно нормально распарралелить на «очень длинные слова» на этапе компиляции.

Ну ок. Правда на практике ни Cayman, ни Evergreen не были great. Но скорее всего это упоротый fglrx :\

Новенький Radeon HD 7870 на GCN тоже был не очень по сравнению со своим предшественником из той же категории по транзисторному бюджету. :)

the average shader program was utilizing only 3.4 out of 5 Radeon cores

Смею заметить что в суперскалярных YOBA-ядрах современного ЦП загрузка исполнительных блоков тоже обычно 0.5 и ниже.

Я добивался ~4.7 / 5 на компьюте у тераскейла, путём засовывания двух «потоков» в один шейдер.

VLIW/ШМК архитектуры есть и будут рекордсменами Оп / с / Вт

Ну и на видяхах щас кроме игорей крутят эн масс только нейронки, а тут VLIW как раз к месту, на них можно адовые matmul’ы крутить, особенно когда архитектура может пропускать register writeback.

Ты случайно не знаешь чем pandd отличается от обычного andd?

К примеру у меня массив беззнаковых байтов который я тупо в 64 битный регистр положил и мне просто надо старшие биты отсечь чтоб превратить в 16и битные:

int vec_mul(const int sz, const unsigned char *b, const __di *bs) {
     unsigned long long v0 = ((unsigned long long *)b)[0];

     v0 = v0 & 0x00FF00FF00FF00FFUL; // andd src1, src2, dst
                                     // (логическое "and" 32/64)

     /* поразрядное логическое AND 64-х разрядов (64S/64U) 
     dst = __builtin_e2k_pandd( src1, src2 );*/
     
     //...
}

Ты случайно не знаешь чем pandd отличается от обычного andd?

Это одинаковая операция в разных доменах. andd выполняется в целочисленном домене (int), а pandd в векторном (vec).

В руководстве 6.1. Планирование кода об этом написано вскользь.

fp->int         +2
int->fp         +1

Наконец, есть дополнительный «штраф» за передачу данных между целочисленными и вещественными операциями - он составляет +2 такта к длительности операции в случае, когда операция-источник является вещественной, а потребитель - целочисленной, и +1 такт в симметричном случае: источник - целочисленная операция, потребитель - вещественная.

Нужно отметить, что дополнительный «штраф» в классе fp получают упакованные (векторные) целочисленные операции, а также операции целочисленного умножения и деления.

Задержки не указываются, но они кажется были 3 такта для vec->int. int->fp и int->vec кажется 0 тактов, но надо перепроверить. Я Эльбрусами уже давно не занимался и начинаю забывать детали, а этих записей у меня нет, хотя может что-то осталось в каком-то чате в Telegram.

В этом руководстве были ошибки, часть исправили.

Если коротко, то в векторизированном коде используй pandd/pord/pxord/paddd/psubd/pslld/psrld вместо целочисленных инструкций если компилятор сам не справляется.