У майбутньому графічні архітектури AMD RDNA/CDNA замінить уніфікована UDNA

[mraleks]

Пропоную обговорити У майбутньому графічні архітектури AMD RDNA/CDNA замінить уніфікована UDNA
GCN маше ручкою?

[Nikolay Yeryomenko]

И зачем это надо две разные соединять в одну? У RDNA свои оптимизации, у CDNA свои - это ж разные области.

[taras_cs]

И зачем это надо две разные соединять в одну? У RDNA свои оптимизации, у CDNA свои - это ж разные области.

Можливо, для обчислень на ігрових RDNA. Припускаю, що розробники наукових та інших не ігрових не дуже поспішають оптимізувати власний софт під CDNA та ще й під RDNA, тому подібна уніфікація допоможе в цьому напрямку.
Класичне

Код: Выделить всё

#if isRDNA
...
#else
...
#endif 

[lostsoulforever]

И зачем это надо две разные соединять в одну? У RDNA свои оптимизации, у CDNA свои - это ж разные области.

Можливо, для обчислень на ігрових RDNA. Припускаю, що розробники наукових та інших не ігрових не дуже поспішають оптимізувати власний софт під CDNA та ще й під RDNA, тому подібна уніфікація допоможе в цьому напрямку.
Класичне

Код: Выделить всё

#if isRDNA
...
#else
...
#endif 

Запуск ШІ на допомогу ігровим потужностям? Зараз це популярно

[Nikolay Yeryomenko]

Код: Выделить всё

#if isRDNA
...
#else
...
#endif

Мда

[KimRomik]

Скоріш AMD переживає не кращі часи, тому об'єднання двох напрямків розробки в один дозволить оптимізувати витрати.

[Alexx-wisa]

"Це ж було вже" ©

Відправлено через 55 хвилин 56 секунд:
"Це ж було вже" ©

[vmsolver]

И зачем это надо две разные соединять в одну? У RDNA свои оптимизации, у CDNA свои - это ж разные области.

Для экономии на разработке, разрабатывают базовую архитектуру, а потом её дополняют нужными фичами для целевого рынка, посмотрите на Nvidia: Паскаль, Тьюринг/Volta, Ampere, Lovelace, Blackwell, это всё одна основа, но для игрового рынка она была дополнена одними фичами, а для HPC другими.

АМД тоже хочет экономить, потому что тащить две архитектуры это просто глупо, ведь CDNA емнип основана ещё на GCN, то есть старая ерунда из 2008 года (в котором она была не плоха, но сейчас уже конец 2024) и её надо менять. Вопрос на что? Делать ещё одну архитектуру? Так игровую тоже надо глубоко перерабатывать, так что надо делать две новые архитектуры, так почему не сделать одну, но хорошую?

[block_stupid]

Об'єднання двох мікроархітектур в одну оптимізує ресурси, як людські так і часові, для самих AMD та розробників, які потім цим будуть користуватись.
А тимчасова зупинка гонки в TOP сегменті дасть додаткову передишку, бо ця гонка не мала результатів, а ресурсів забирала купу.
І через 1-2 роки зможуть вийти із значно кращими пропозиціями і для професійного сегменту і для ігр.
Потім допилювання і вже можна тягатись із топами Nvidia і показати що вони мають для майбутнього покоління консолей.

[vmsolver]

Паскаль, Тьюринг/Volta, Ampere, Lovelace, Blackwell, это всё одна основа

Заметил неточность, каждая перечисленная архитектура является основой, а не у них одна основа. Если перейти на уровень семейств архитектур, тогда можно говорить, что у них одна основа, но Паскаль в таком ряду будет лишним. Как раз Volta это родоначальник нового семейства архитектур и всё что было позже это "доделанная Volta", Паскаль же это последняя архитектура прошлого семейства архитектур.

[Scoffer]

vmsolver
У тебе застарілі дані. Ада і хоппер більше не одного сімейства мікроархітектури. Перша cuda 8.9 + графіка, друга 9.0 і випилений з кінцями графічний конвеєр. SM, відповідно, теж відрізняються. Тобто нвідія потихеньку рухається зворотнім шляхом розуніфікації і розділення.

[vmsolver]

Ада і хоппер більше не одного сімейства мікроархітектури. Перша cuda 8.9 + графіка, друга 9.0 і випилений з кінцями графічний конвеєр

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

SM в игровых и HPC чипах одной архитектуры всегда разный, про это и речь выше.

[Scoffer]

vmsolver
Що значить на одній ступенькі? Вони структурно складаються з різних блоків і на макро, і на мікро рівні. Вся схожість закінчується на тому що і то нвідія, і то, і то куда, і то. Це різні мікроархітектури як не крути.

[vmsolver]

Що значить на одній ступенькі?

Одна внутренняя система команд, все похожие блоки одинаковы и т.д, потому что основа одна.
Если в SM будет 32 FP64 юнита вместо 4-х, то это не изменение архитектуры, это просто разная конфигурация железа в рамках одной архитектуры.

В Хоппер они изменили чуть больше, но в целом правило верно, одна основа, которая конфигурируется нужными фичами для конкретного рынка, поэтому есть игровой Ампер и его HPC версия. А вот Ампер, Лавлейс и т.д. у них есть разница в основе (пусть это будет микроархитектура), но это одно семейство архитектур.

[taras_cs]

АМД тоже хочет экономить, потому что тащить две архитектуры это просто глупо, ведь CDNA емнип основана ещё на GCN, то есть старая ерунда из 2008 года

Легкий гуглінг каже нам, що
Release date of CDNA: November 16, 2020
І розроблялася вона під AMD Instinct MI100

"CDNA is a successor to the Graphics Core Next (GCN) microarchitecture" - не означає, що вона базується, а лише що вона замінює собою стару GCN на нову CDNA.

[vmsolver]

"CDNA is a successor to the Graphics Core Next (GCN) microarchitecture" - не означає, що вона базується, а лише що вона замінює собою стару GCN на нову CDNA.

Я конечно могу ошибаться и там выше писал по памяти, но если взять доку на CDNA, то там пишут вот так:

The 120 enhanced compute units (CUs) are built on the foundations of the GCN architecture and organized into four compute engine...

И foundations это основана, базируется, а не "лише що вона замінює собою стару GCN". Так что лёгкое гугление не всегда показывает истину, а лишь находит маркетинговый булщит того, чего хотелось бы найти.

[Scoffer]

Одна внутренняя система команд

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

[vmsolver]

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

Да о чём ты вообще? У тебя нет никакого программного доступа к SM, он, кстати, не что-то одно, в нём четыре независимых processing block, каждый из которых уже является минимальным вычислительным устройством во всей системе. Так вот, у тебя никакого доступа к SM, ты пишешь шейдер (программу), далее он компилируется и когда ты его запускаешь на исполнение, драйвер или планировщик внутри решает какие SM будут его исполнять, всё, ты тут вообще не при делах, это не твоё дело что на каком SM исполняется, ты контролируешь лишь что надо исполнить.

Никаких новых механизмов при добавлении int не нужны, во-первых что вообще ты под этим понимаешь не ясно, во вторых, команда лоад просто прочитает указанное ей количество байт и разместит их в нужном регистре, ей совершенно наплевать что ты далее будет эти четыре байта использовать как int или как float или ещё как, да хоть упакованный 4xFP8, это не его дело вообще, поэтому не выдумывай. Общая система команд и означает, что все эти базовые вещи решены, понятно как их соединять и что они точно будут работать.

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

[Scoffer]

vmsolver
У тебе є програмний доступ до SM. Ніхто не забороняє тобі писати на асмі відяхи, принаймні поки що, хоча нвідія теж до того йде. Те що ти його не юзаєш і пишеш більш високорівнево, а замість тебе це робить драйвер - твої особисті справи, до обговорення це ніяк не стосується. Це по-перше.
А по-друге дивись 5.2.3.1. і далі.
https://docs.nvidia.com/cuda/cuda-c-pro ... index.html
навіть пишучи на високорівневій куді ти вимушений писати ядра так щоб вони спочатку з'ясовували пропускну спроможність апаратури і лише потім запускали відповідно налаштовані завдання, інакше діла не буде. Це не автоматичний процес. І компілиться драйвером в різний код.

[vmsolver]

У тебе є програмний доступ до SM. Ніхто не забороняє тобі писати на асмі відяхи, принаймні поки що, хоча нвідія теж до того йде. Те що ти його не юзаєш і пишеш більш високорівнево, а замість тебе це робить драйвер - твої особисті справи, до обговорення це ніяк не стосується. Це по-перше.

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

А по-друге дивись 5.2.3.1. і далі.
https://docs.nvidia.com/cuda/cuda-c-pro ... index.html
навіть пишучи на високорівневій куді ти вимушений писати ядра так щоб вони спочатку з'ясовували пропускну спроможність апаратури і лише потім запускали відповідно налаштовані завдання, інакше діла не буде. Це не автоматичний процес.

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

Тут актуальна картинка "вы не понимаете, это другое"
И это реально другое.

з.ы. Наофтопили про универсальную архитектуру АМД )))