Nvidia анонсувала процесори Rubin та Rubin Ultra з 1 ТБ пам’яті HBM4

[Yuriy_5070ti]

Пропоную обговорити Nvidia анонсувала процесори Rubin та Rubin Ultra з 1 ТБ пам’яті HBM4

Сталкер 2 - нативні 80 кадрів/с в 4к

[doc-oc]

Зато в потребительских картах так и будет памяти с гулькин нос

[Kashtan]

Фейнман - наступна архітектура побутових відеокарт виходить, дуже цікаво, що ж там такого абсолютно нового розробили.

[Enjthesilence]

Фейнман - наступна архітектура побутових відеокарт виходить, дуже цікаво, що ж там такого абсолютно нового розробили.

6060>5090

[vmsolver]

Фейнман - наступна архітектура побутових відеокарт виходить

Об этом не объявляли, но там ещё Rubin есть, но нельзя исключать какую-то другую архитектуру.

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

Производительность tensor-cores начиная с Ампер повысилась лишь раз, за счет повышения частоты при переходе с 8нм Ампера на 4нм Ада (1.9 ГГц -> 2.8 ГГц).

[stoned]

R2-D2 RTX On

[Classique]

Це такий тренд зараз? Чому не електроніка ВП?

[dead_rat]

Штош, тепер ми знаємо куди ділася уся памʼять

[Kashtan]

Фейнман - наступна архітектура побутових відеокарт виходить, дуже цікаво, що ж там такого абсолютно нового розробили.

6060>5090

6000-а серія це Вера Рубін. Фейнман це 7000-на виходить.

[Nekros]

6060>5090

6000-а серія це Вера Рубін. Фейнман це 7000-на виходить.

У нвідї різні архітектури до серверного сегменту і ігрового. Якщо сервери зараз Вера Рубін, то ігрові 6000 будуть на іншій

[ronemun]

Надіюсь придумають як ці матричні блоки пристосувати до звичайних математичних розрахунків, в т.ч. рендеру
А то шкода коли стільки суперчіпів і суперпамяті підуть в сміття після оновлення, а прискорення тут шалені - GB300 в мережі діпсік на 600+ млрд. параметів в 10 раз швидше за H200. Це завдяки великому обєму памяті, але далі обєднання чіпів дасть прискорення в геометричній прогресії.
Є наближені обчислення шляхом апроксимації - вони мали б ідеально підходити під такі гадання
Але як їх пристосувати до багатовимірних і нелінійних систем? Пошук закономірностей неймовірно важка штука, прямі обчислення елементарно легші

[GigaCore]

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

это если бы рендер был преимущественно compute bound нагрузкой, а на деле он latency bound, отсюда и ray reordering, и wide bvh, и прочая трансформация задержек в псп

[vmsolver]

ronemun
GigaCore
Не будут матричные блоки использоваться в рендере, в этом нет никакого смысла, основной тип чисел используемых в рендере, например пространство сцены, это FP32, а tensor-core во-первых не умеют их использовать напрямую, а во вторых даже если с трюками задействовать их в формате вычислений FP16 * FP16 + FP32, что не универсально, то их производительность будет не лучше чем вычисления на АЛУ, никакого ускорения не будет. Tensor-core это история про FP16 и ниже, поэтому это железо для нейросетей.

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

рендер был преимущественно compute bound нагрузкой, а на деле он latency bound

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

[GigaCore]

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

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

[vmsolver]

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

Переупорядочивание лучей нужно чтобы не простаивали вычислительные блоки, потому что processing block обрабатывает по 32 потока одновременно, если ему вместо этого давать по одному лучу, то GPU будет простаивать, поэтому лучи переупорядочивают, то есть группируют. Я бы не назвал это скрытием задержек, это повышение пропускной способности вычислений, то есть более эффективное использование ресурсов GPU, ведь если этого не сделать, то нельзя будет генерировать например в 10 раз больше лучей, даже если rt-core успеют найти все треугольники в которые попадают эти дополнительные лучи, то если неэффективно загружать АЛУ, то GPU просто не сможет быстро вычислить пиксельный шейдер для каждого этого луча, поэтому переупорядочивание решает другую задачу и дело не в латентности памяти.

Я согласен, что натянуть тензорные опсы маловероятная перспектива, но долежн заметить что фп16 точности для просчета непосредственно материалов вполне себе хватит,

Для пиксельного шейдера может быть FP16 и будет достаточно, но этой истории уже много лет, вроде бы ещё с Паскаля была истерика (у сектантов-радеонщиков) что новый Радеон в два раза производительнее в FP16 чем карты на архитектуре Паскаль. С тех пор прошло много лет, истерика поутихла, а FP16 как использовали только в мобилках, так и используют. Амперы, Ады, Блэквеллы умеют вычислять FP16 на АЛУ с тем же темпом, что и FP32. Внимание вопрос, кому те FP16 нужны, если никакого буста производительности не будет, программистам надо будет просто быть внимательнее и следить чтобы у них не было переполнений для FP16 арифметики. Я думаю они все будут в дружном восторге от такой перспективы, вместо использования стандартного беспроблемного FP32 с той же производительностью
А что касается тензоров, то все материалы, цвета, нормали и прочие атрибуты, они ведь в виде текстур сохранены, а у GPU есть блоки тектурирования, аппаратные! И снова вопрос, а зачем козе баян, если многим занимаются аппаратные блоки, а пиксельный шейдер выполняется на АЛУ, в какое место тут надо засунуть матрицу 16х16?
Больше возни, чем реально прока.

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

Физику, в дребезги FP16? Ой не нравится мне это, ой не нравится.
Кроме одного варианта, о котором вчера распинался Хуанг на GTC, когда на тензорах вычисляется нейросеть, которая вычисляет физику. Причем, она не точная, она просто похожа на неё, а играм ничего другого и не надо.

[Scoffer]

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

Це від того що намагаються натягнути сову на глобус, а сова не резинова. Для пастрейсінгу архітектурно треба щось накшталт старого-доброго ларабі/зіон-фі або cell spe. Тобто проц на багато-багато ядер зі шматочком власної виділеної локальної пам'яті. Але такий, так би мовити, gpu просере всі полімери в традиційному растрі, а значить в осяжному майбутньому випущеним не буде бо хто його купить. Та і в неосяжному напевне теж. Разок вже намагались, ніхто не оцінив.

[ronemun]

vmsolver
я писав вище про так звані наближені обчислення
те що чомусь там тре 32, 16, 64/128 і т.д. біт точності - це лише фікція, чисто дискретне значення і все. Часто хватає і 8 біт, наприклад звичайний колір має 3 значення по 8 біт. А іншим і 128 мало - все залежить від умов і градієнту.
Ми наприклад ділимо чи множимо в стовпчик, 10ти значні, 8, 16, чи 2х значні числа - це все неважливо - все одно - одна позиція за раз, а далі тупе повторення. По суті ми суперскладну операцію просто розділяємо на елементарні речі, так звані ітерації. І з кожним повторенням цієї ітерації ми ближчі до істини.
Це і є наближені обчислення. І їм непотрібні багато біт за раз. Хватає мінімум - 2 у цілих і 4х у FP числах. І можна обчислити абсолютно все.
Бо по суті вся інформація, істина - це просто статистика, а статистика - це лише ймовірність, невідоме нам відношення % точних значень в загальній кількості. Наша задача якомога частіше попасти в область заданої точності.
Тільки в 1му вимірі ми можем бавитись в точність, перебір і т.п. А у 2х, 3х і т.п. ці вгадування займуть колосальну кількість роботи і важко зрозуміти куди нас несе.

[vmsolver]

я писав вище про так звані наближені обчислення
те що чомусь там тре 32, 16, 64/128 і т.д. біт точності - це лише фікція, чисто дискретне значення і все.

В смысле фикция? Вы думаете с 8 битных процессоров перешли на 64-битные без причин, показалось нам всем так? Почитайте про базовую арифметику рендера, проекции, повороты, пространство сцены, пространство модели, камеры и как это всё увязывается друг с другом. А теперь заберём у вас FP32 и дадим INT8, что будет с вашим настроением? А если от вашего результата будет зависеть ваша и колег зарплата, а также будущее компании, то что вы скажете тому фантазёру, который предложит взять всё и поделить отказаться от FP32?

Часто хватає і 8 біт, наприклад звичайний колір має 3 значення по 8 біт. А іншим і 128 мало - все залежить від умов і градієнту.

Ну да, а если вдруг понадобились более точные вычисления, чем просто заполнить экран градиентом, вы запланируете в следующем поколении FP32?

Ми наприклад ділимо чи множимо в стовпчик, 10ти значні, 8, 16, чи 2х значні числа - це все неважливо - все одно - одна позиція за раз, а далі тупе повторення. По суті ми суперскладну операцію просто розділяємо на елементарні речі, так звані ітерації. І з кожним повторенням цієї ітерації ми ближчі до істини.

Ну попробуйте отрендерить один треугольник с градиентом считая всё в столбик. А после ответите на вопрос, зачем это всё.

Це і є наближені обчислення. І їм непотрібні багато біт за раз. Хватає мінімум - 2 у цілих і 4х у FP числах. І можна обчислити абсолютно все.

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

Бо по суті вся інформація, істина - це просто статистика, а статистика - це лише ймовірність, невідоме нам відношення % точних значень в загальній кількості. Наша задача якомога частіше попасти в область заданої точності.
Тільки в 1му вимірі ми можем бавитись в точність, перебір і т.п. А у 2х, 3х і т.п. ці вгадування займуть колосальну кількість роботи і важко зрозуміти куди нас несе.

Тут у вас дискриминант отрицательный

Лучше почитайте книжку по железу.

[ДядяСаша]

Це Sams обіцяє Хуангу в 27 випустить HBM4e ?