NVIDIA забезпечить підтримку CUDA на системах із процесорами RISC‑V

[1234waltz]

Пропоную обговорити NVIDIA забезпечить підтримку CUDA на системах із процесорами RISC‑V
Некромантія

[KimRomik]

мене більше цікавить до чого тут Китай

[denizen]

бо RISC-V це майбутне, не вимагає ліцензування, може використовуватись, в тому числі, в Китаї

[Afit]

бо RISC-V це майбутне, не вимагає ліцензування, може використовуватись, в тому числі, в Китаї

Я навіть не пам'ятаю скільки років я вже щось подібне чую/читаю. Майбутнє... майбутнє... майбутнє за RISC‑V
Практика показує що це все просто існує паралельно

[denizen]

згоден, теж це чую багато років. потенційно це цікаве рішення, але мабуть дуже багато є небажаючих пустити на ринок.

бо RISC-V це майбутне, не вимагає ліцензування, може використовуватись, в тому числі, в Китаї

Я навіть не пам'ятаю скільки років я вже щось подібне чую/читаю. Майбутнє... майбутнє... майбутнє за RISC‑V
Практика показує що це все просто існує паралельно

[tornadox]

згоден, теж це чую багато років. потенційно це цікаве рішення, але мабуть дуже багато є небажаючих пустити на ринок.

Наскільки я пригадую, там не діло в тому щоб пустити на ринок, а в тому що там потрібні роки розробки щоб створити щось схоже на сучасні високопродуктивні процесори. Ви вже зараз можете купити якийсь IoT на RISC-V, але навіть існуючі девборди не дотягують до рівня існуючих SBC на арм, не говорячи вже про х86.

Afit
Так і є, не впевнений чи ми побачимо щось для десктопу в майбутні 5 років, а для серверів звісно щось буде.

Відправлено через 4 хвилини 51 секунду:
KimRomik

Чипи з архітектурою RISC‑V тепер зможуть виступати як основний процесор для систем на базі CUDA, роль якого традиційно виконували рішення x86 або Arm

Китай немає власних розробок процесорів, є свій Логсун, який десь обгризає рештки МІПСа. АРМ зараз диктує заборону на власний дизайн, то ж схоже що історія з зоопарком виробниців процесорів може повторитися як це було в часи 8086

[1234waltz]

Так і є, не впевнений чи ми побачимо щось для десктопу в майбутні 5 років, а для серверів звісно щось буде.

Мало віриться, он гейропейці робили-робили-робили, в результаті на стоковому АРМ випустять.

[yuriy_dd]

перевага RISC‑V - що безкоштовна архітектура

але є проблема - нема безкоштовних реалізацій, а купити - не так і дешево

перевага АРМ - що є все і відразу. Саме тому навіть такі далекі гравці як Сяомі - за короткий час і дешеві гроші - може випустити сучасний швидкий АРМ проц для смартів, і зробити щоб в ньому було все те що їм потрібно

[Scoffer]

але навіть існуючі девборди не дотягують до рівня існуючих SBC на арм, не говорячи вже про х86

І не дотягне ніколи. Автори занадто сильно упоролись в простоту ISA ціною складності високопродуктивної апаратури.
Ото шо вони там у себе понавигадували в спеках з компрессед+макро-опс фьюжн не робить навіть апаратура х86. Відповідно не вміє і жодна з реалізацій ріск-в. Це треба трейс кеш будувати чи ще щось подібне страшне. А без цього бекенду проца треба виконати на 20-30% мікрокоманд більше ніж в будь-якій іншій архітектурі. Навіть отой стартап де Келлер рісквою займається так і не показав з себе нічого не те що видатного, а навіть середнього.
Коротше ріск-в от прямо ідеальний приклад як робити не треба. Не здивуюсь якщо то якийсь умовний інтол їх замовив просто щоб збити бажання зробити нормальну відкриту іса

[CADR]

VLIW тоже долгое время подавал заоблачные надежды как RISC-V. Но нет.

[vmsolver]

Откровенно говоря, не понятен негативный настрой против RISC-V, набор команд как набор команд, не лучше и не хуже чем у остальных.

На всякий случай спросил LLM-ку про особенности RISC-V у нвидии, получил такой ответ:

RISC-V поддержка в CUDA от NVIDIA действительно имеет свои особенности, но они связаны скорее с интеграцией и оптимизацией, чем с кардинальными изменениями базовой архитектуры.
Основные отличия:
Расширения ISA: NVIDIA использует стандартные расширения RISC-V, но акцентирует внимание на тех, которые важны для параллельных вычислений - векторные расширения (RVV), атомарные операции (A-extension), и расширения для работы с плавающей точкой (F, D extensions).

Оптимизация для GPU-интеграции: Ядра RISC-V в контексте CUDA оптимизированы для тесной интеграции с GPU, включая специальные пути для обмена данными между CPU и GPU частями чипа, оптимизированные механизмы синхронизации.

Поддержка CUDA Runtime: Добавлена нативная поддержка CUDA runtime API, что позволяет запускать CUDA-приложения напрямую на RISC-V ядрах без эмуляции x86/ARM слоя.

Энергоэффективность: Особый акцент на power management и динамическом масштабировании частот для мобильных и edge-устройств.
Сам набор команд остается стандартным RISC-V - NVIDIA не создавала проприетарных расширений. Основные улучшения касаются микроархитектуры, кэшей, предикторов переходов и интеграционных решений. Это позволяет сохранить совместимость с экосистемой RISC-V, при этом получив оптимизации для CUDA-workloads.

[Martix]

Молодец, Хуанг. Цифровая революция начата. Партия тобой довольна. Вот твоя миска риса и кошка-жена

спойлер

По-моему НВ таким образом показала средний палец кому-то, кто вводил ограничения на продажу их продукции в Китай.

Отправлено спустя 2 минуты 14 секунд:
vmsolver
Никакого хэйта, RISC-V это будущее. Если НВ идет на такие, непривычные для своей кампании шаги, значит у них есть серьёзные наработки в этой области.

[AssayMAS]

майбутнє за RISC‑V

то прост все корпорации "нищеброды" не хотят на себе тянут будущее с хай енд RISC‑V...а сделать лоу енд процессор уже обыденность. Вон Китай тетрисов на RISC‑V с эмуляторами сеги, денди, ... и десятка консолей наштамповал - и каждый ПРОЦ самобытен и имеет свои лузлы. Так что без гор бабла и десятилетий работы новый грааль типо "Х86" не сделать - вот Нвидия и видит нишу куда можно не самой влезть, а заманить недалёких инвесторов с Азии.
Просто если б тема с RISC‑V была дельной она б еще в 2020 выстрелила где то кроме узких SoC.

[denizen]

будь-яку архітектуру можна адаптувати під будь-які задачи, було б бажання і гроші.

[Scoffer]

denizen
Можна, але якою ціною? Якщо взяти базову іса, то проги на ріск-в будуть відсотків на 20-30 більшими як в байтах, так і в командах за наприклад арм64. Відповідно для досягнення тої ж продуктивності ріскві треба більший кеш і ширший ооо-проц на ці самі відсотки, а це дофіга.
Що пропонують автори ріскви щоб виправити ситуацію? А пропонують вони дві штуки:
1. Компрессед розширення, котре вводить скорочені 16-бітні версії деякого обмеженого набору команд. В теорії це має скоротити розмір коду в байтах (але не в командах!) до рівня арм64 чи навіть трішки нижче. Гарно звучить? Гарно, це б вирішило проблеми з кешем. Але потік з 16 і 32-бітних команд не є вирівняним по межі 32-бітного слова, що означає необхідність вводити переддекодери для визначення меж команди (прям як в х86), не є вирівняним по межі лінії кешу, що заставляє читати дві лінії кешу замість однієї щоб захопити хвости (знову привіт х86), не є вирівняним по межі сторінки пам'яті, що заставляє вводити додаткові перевірки на тему прав доступу (х86, ага) і взагалі всіляко ускладнює життя. Квалком не один рік бореться щоб випилити це розширення зі спеки, але рісква фундація вперлась рогами;
2. Злиття макрооперацій. Це коли апаратура проца може виконати складну команду, але через куцість іса не може її отримати після декодера просто в результаті декодування бо ні з чого. Декодер має взяти пару команд і зліпити з неї одну мікрокоманду. Тут ми передаємо ще один привіт переддекодерам, котрі тепер мають розпізнавати не тільки 16 і 32 бітні команди, а і їхні пари 16+16, 16+32, 32+16, 32+32 і ще один привіт отим всим проблемам з вирівнюваннями. Також значно ускладнюються самі декодери і створюються проблеми для імплементації таких структур як кеш мікрооперацій. Наприклад якщо скласти в кеш мікрооперацій злиту команду, то що буде якщо прога згенерить перехід на її середину, що не заборонено іса? Виключення? Так це тоді явний баг. То шо треба два комплекти мікрокоманд зберігати в кеші? Попахує маразмом і взагалі неекономненько. Як наслідок жодна! реалізація на даний момент цього не вміє. І не збирається вміти. А значить проблеми з кількістю мікрооперацій нікуди не зникла. Стартап де Келлер намагається просто в лоб розширити ооо, але щось у них все це не надто гарно працює.
Плюс з рісквою є купа дрібних проблем поменше, але на фоні оцих шо вище то не суттєво.

Відправлено через 21 хвилину 8 секунд:

не лучше и не хуже чем у остальных

Та от ні. В ріск-в примудрились зробити навіть гірше ніж було в міпсі. Старість не радість, по молодості у авторів кукуха варила краще.

Відправлено через 17 хвилин 43 секунди:
А, ще робота з невирівняними даними (читати як з utf-8, зараз це головний їхній генератор), реалізована через переривання що до смішного повільно і це взагалі не контриться мікроархітектурою. LWL/LWR з міпса на дві голови краще.

[vmsolver]

Та от ні. В ріск-в примудрились зробити навіть гірше ніж було в міпсі. Старість не радість, по молодості у авторів кукуха варила краще.

LLM-ка:

RISC-V имеет довольно хорошо продуманную архитектуру с точки зрения выравнивания данных и декодирования команд, но есть некоторые нюансы:
Выравнивание данных
RISC-V не требует строгого выравнивания данных на уровне архитектуры. Процессор может обращаться к невыровненным данным, но:

Производительность: Невыровненные обращения могут быть значительно медленнее (могут потребовать нескольких циклов памяти)
Реализация: Конкретные процессоры могут генерировать исключения при невыровненном доступе, если это не поддержано аппаратно
Атомарные операции: Требуют естественного выравнивания (4 байта для 32-битных, 8 байт для 64-битных)

Декодирование команд
Здесь RISC-V показывает себя хорошо:
Преимущества:

Команды имеют фиксированную длину 32 бита (в базовом наборе)
Простая и регулярная структура кодирования
Поля команд расположены в одинаковых позициях для схожих типов операций
Опкоды легко декодируются

Потенциальные сложности:

Расширение C (сжатые команды): Добавляет 16-битные команды, что усложняет декодер, так как нужно различать 16 и 32-битные инструкции
Переменная длина: С расширениями команды могут быть 16, 32, 48 или 64 бита
Будущие расширения: Потенциально могут добавить еще больше вариантов длины

Решение проблем декодирования:
RISC-V использует младшие биты для определения длины команды:

xx00 или xx01 или xx10 = 16-битная команда (сжатая)
xxx11 = 32+ битная команда

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

Итак, кто из вас галюцинирует?

Відправлено через 2 хвилини 24 секунди:

А, ще робота з невирівняними даними (читати як з utf-8, зараз це головний їхній генератор)

Это в ESP32 каком-то или где? А то ведь новость о совсем других реализациях.

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

[Scoffer]

vmsolver
Отак і виросло покоління людей, котрі забули як це думати без ллм. Ти прочитай для початку що саме я написав. А потім піди в квалком і розкажи їм що вони не праві, і немає у них ніяких проблем з рісквою. І Келлеру заодно.

Відправлено через 6 хвилин 54 секунди:

Это в ESP32 каком-то или где? А то ведь новость о совсем других реализациях.

Це в усіх реалізаціях. Рісква не передбачає доступу до невирівняних даних. Все що вона робить це генерація виключення. А далі пиши там шо хочеш. Наприклад таке
https://rust.godbolt.org/z/bM5rG6zds
або таке якщо це порядок від старшого до молодшого як в отих ваших інтернетах
https://rust.godbolt.org/z/TndWTK3zh
Шо в х86, шо в армі це одна команда і без виключень. В міпсі дві, і теж без виключень.

[vmsolver]

Scoffer
Твоя ошибка в том, что ты обобщаешь не понимая предмета.

Что ты такого написал, что не решается?
Вот это?

Але потік з 16 і 32-бітних команд не є вирівняним по межі 32-бітного слова, що означає необхідність вводити переддекодери для визначення меж команди (прям як в х86)

Выше написали, что размер команды определяется по двум младшим битам. Какие проблемы? Или сам факт, что надо проверять пару бит это проблема?

Или это?

що означає необхідність вводити переддекодери для визначення меж команди (прям як в х86)

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

Со слитыми командами надо смотреть на конкретные примеры, а то у тебя пару бит проверить проблема ))

[Scoffer]

vmsolver
Та ні, це ти не розумієш. До того як в декодер прийде команда її треба нарізати зі строки кешу, але оскільки команди не вирівняні по 32-бітам, то доведеться нарізати з двох строк кешу бо голова останньої може бути в першій, а хвіст в другій строкі. І запитувати з кешу дві строки. В цьому проблема, а не в твоїх двох бітах. Це тупо вдвічі більший трафік л1і на рівному місці. І якщо в х86 на то є історичні причини, то в ріскві причини в тупості.

[vmsolver]

Это в ESP32 каком-то или где? А то ведь новость о совсем других реализациях.

Це в усіх реалізаціях. Рісква не передбачає доступу до невирівняних даних. Все що вона робить це генерація виключення. А далі пиши там шо хочеш. Наприклад таке
https://rust.godbolt.org/z/bM5rG6zds
або таке якщо це порядок від старшого до молодшого як в отих ваших інтернетах
https://rust.godbolt.org/z/TndWTK3zh
Шо в х86, шо в армі це одна команда і без виключень. В міпсі дві, і теж без виключень.

Где в спецификации RISC-V запрещает решать проблему невыравненого доступа аппаратно? Реализация этой фичи это приоритет разработчика ядра, RISC-V это просто система команд. Если разработчики не решают эту проблему апаратно, значит не видят в ней приоритета, в конце концов, что тебе мешает писать программы учитывая это?

Ну и что ты с тем Келлером носишься, он взял готовое ядро от другой конторы:

Tenstorrent, a developer of heterogeneous processors for AI applications led by ex-AMD engineers Ljubisa Bajic and Jim Keller, has licensed a general-purpose CPU design developed by SiFive based on the RISC-V architecture. Licensing general-purpose cores and IP will speed up time-to-market of Tenstorrent’s products.

Відправлено через 7 хвилин :

Та ні, це ти не розумієш. До того як в декодер прийде команда її треба нарізати зі строки кешу, але оскільки команди не вирівняні по 32-бітам, то доведеться нарізати з двох строк кешу бо голова останньої може бути в першій, а хвіст в другій строкі. І запитувати з кешу дві строки. В цьому проблема, а не в твоїх двох бітах. Це тупо вдвічі більший трафік л1і на рівному місці. І якщо в х86 на то є історичні причини, то в ріскві причини в тупості.

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

Дело не в какой-то там тупости, а просто не надо бояться длинных команд, не надо бояться перехлёста кеш-линий, это будет, это просто обычная работа процессора. Это в микроконтролллерах можно сделать всё по 16 бит или по 32 бита с оговорками, в больших системах вот то, что ты описал, это обычное дело.