Я сам разрабатываю свой процессор, который может работать как CPU и как ядро GPU, поэтому полью это поделие говнецом.1. Я разрабатывал в первую очередь ALU на уровне транзисторов буквально чтобы минимизировать площадь и энергопотребление. У микросхем есть два важных параметра - non recurrent expences(NRE) и recurrent expences(RE). Оба эти параметра надо снижать уменьшая площадь изделия. А так же потому что а)патенты! патенты! патенты на всё, даже пернуть нельзя не нарушив патент. б)ALU должны быть многофункциональными, то есть подблоки должны уметь комбинироваться для выполнения разных операций и тем самым еще сильнее снижать площадь. Я не увидел этого в risc-v от слова совсем. Аналогично регистровый файл - это вторая критическая точка оптимизации, которую они скорее всего реализовали "стандартно-библиотечно", то есть через жопу. Для эльбруса например РФ свирепо оптимизировали, хотя там далеко не гигагерцы.
2. Он еще и греться будет, ибо стандартные ячейки 60% энергии сливают на сквозной ток при переключении(потому что SVT-транзисторы с 0.4v порогом при питании 1.2v дают зазор в 1.2-0.4-0.4=0.4 вольта на переключении когда ячейка открыта накоротко, и 20% на статическую утечку, потому что короткие затворы. 80% энергии в трубу. Самое эффективное - это домино-логика с мультиплексорами и LUT на n-транзисторах и в конце инвертор на HVT-транзах с порогом 0.7v и толстым затвором, который p-транзом сидит на питании, а нижним смотрит в выход мультиплексора/LUT, а тот на ноль. Дальше latch также на HVT. И быстро и холодно.
3. Система команд: это второе узкое место. Я её адаптировал к бинарной трансляции х86, т.е. команды по 13бит пакуются в 64битные пачки, с заголовком для синхронизации и управления в 12бит и достаточно точно отображаются на отдельные байты команд х86-64. При этом есть префиксы для векторных операций, которые используются для эмуляции AVX и для шейдерных операций, сам рендерер на llvm-pipe т.к. минимум изменений требуется. Выборка идёт по нескольким указателям инструкций, при этом есть команды fork и join. Это называется strand-level parallelism и позволяет быстро перестраивать "плотность" шейдеров на процессорный модуль. И это всё сделано чтоб обойти патенты.
В риске я вижу что-то между AMD GCN и мертворожденным Intel Larrabee, причем сильно ближе к последнему. Там просто чудовищное количество патентов от интела. Да и сам подход larrabee убог в принципе от чего и сдох. Сам набор команд(они не постеснялись опубликовать его) - днище. Возникло впечатление, что люди которые его придумывали, никакого отношения к процессорам не имеют, а просто взяли мануал по opengl1.4 и на каждую функцию сделали по "инструкции".
4. Кэш данных. Внезапно, Write-Back кэш для таких задач не подходит. Write-Thru с огромной ассоциативностью(буквально массивы компараторов адресов нужны) и при этом надо добавить регистр, блочащий часть кэша и не дающий её вытеснять. Вот эти моменты надо проверять на симуляторе, причем не обязательно через verilator гонять или симулировать. Можно примитивную модель на С++ написать, снять программой для трассировки вулкана или opengl лог с пары игр и попробовать прогнать через модель. Проблемы с обычным WB кэшем(а у них именно _обычный_ кэш) будут видны сразу потому что ему может влегкую не хватить ассоциативности, когда целый варп шейдеров постучит по кратным адресам, встанет в ожидание, за ним следующий вытеснит данные предыдущего и сам встанет, и так они начнут гонку вплоть до live lockа.
Это даже не мертворожденный проект, это глина номер 4 какая-то.
