- /A\
- Постоялец
Mobile Developer
> Покажи мне мобилы с RT-ядрами NVidia?
У них есть тегры на новой архитектуре, только без РТ ядер.
/A\
> Эльбрус может под это подходит?
Эльбрус — это еще хуже, чем SIMD.
> Сейчас все скалярное. Разве что у АМД половина регистров - векторные.
Наоборот — все современные десктопные видеокарты, в том числе встроенные, — это чистейший SIMD (кстати, AVX512, если кто не знает, пришло из экспериментальной видеокарты от Интела). То "скалярное", про которое все рассказывают — это ушли от VLIW×SIMD (пока, Эльбрус!) к чистому SIMD. Т. е. было Vector×Vector, стало Scalar×Vector. Другая размерность, короче.
Mobile Developer
> SIMD в вопросах мобильного рейтрейсинга путь в никуда, КПД очень низкий. Поэтому о нём нет смысла говорить.
Тогда зачем считать операции? Там вспомогательная обвязка гораздо больше транзисторов занимает, чем, собственно, ALU. В общем, скалярные операции обычно на порядок дороже векторных.
> Все мобилы скалярные уже давно - это помогает сохранить энергию.
Наборот, для экономии энергии делают всякие специализированные блоки, вместо универсальных скалярных.
> Модуль траверсинга: включает в себя 4-16 килобайт кеша
Выглядит как тупик: если лучи идут случайно, то кеш бесполезен; если закрепим кусок сцены за каждым юнитом, то большинство будет простаивать. В общем, без специального шедулера, который будет лучи по этим юнитам распределять следя за эффективным использованием кеша, не взлетит. А при наличии такого волшебного шедулера, непонятно, зачем эти специализированные юниты, в принципе, нужны: существующие шейдерные процессоры справятся не хуже и транзисторы сэкономят.
> 2 ребёнка это алгоритмический оптимум, по количеству вычислений, и следовательно по тратам энергии.
Оптимум — это когда время обработки полученного из памяти совпадает со временем доступа к этой памяти. В этом случае можно эффективно запараллелить одно ALU и один порт доступа к памяти. При отклонении от оптимума придется увеличивать количество исполнительных устройств, либо они будут простаивать. Конкретно, 2 ребенка выглядит очень далеким числом от оптимума: доступ к памяти долгий, кеши для трейсинга бесполезны, за время получения данных можно успеть обработать гораздо больше 2-х детей.
> В частности, отсутствие латентности при чтении памяти - является одним из главных факторов ускорения.
Законы физики не позволяют (по крайней мере, в рамках технологии CMOS). Чем больше память, тем дольше до нее доступ. А кеши требуют волшебного шедулера, про который я уже писал.
phridrich
> Ходили слухи о каких-то очень многоядерных RISC-V - это как раз из той оперы.
Я думаю, вместо честной многоядерности, будет лучше сделать что-то типа гипертрединга на 1024 потока. Ну и выкинуть кеши всех уровней и предсказатели ветвлений (ибо это latency-oriented), нарастив за счет них очереди потоков.
/A\
> У них есть тегры на новой архитектуре, только без РТ ядер.
Ну и что?
}:+()___ [Smile]
> Тогда зачем считать операции? Там вспомогательная обвязка гораздо больше
> транзисторов занимает, чем, собственно, ALU. В общем, скалярные операции обычно
> на порядок дороже векторных.
Не в данном случае. У тебя отдельный непрограммируемый юнит, там вспомогательной обвязки много не требуется, всё забито этими самыми специализированными ALU.
>Наборот, для экономии энергии делают всякие специализированные блоки, вместо универсальных скалярных.
The Mali Utgard and Midgard GPU architectures implement Single Instruction Multiple Data (SIMD) maths units, exposing vector instructions to each thread of execution. The Mali Bifrost GPU architecture switches to scalar arithmetic instructions, but still implements vector access to memory.
Векторные блоки делают много лишних операций, это тратит энергию зазря.
>Выглядит как тупик: если лучи идут случайно, то кеш бесполезен;
Потому и полезен, что они идут случайно. Такой формат бесполезен для когерентных лучей.
>если закрепим кусок сцены за каждым юнитом, то большинство будет простаивать.
Само по себе простаивание не проблема - энергия не тратится.
А так - у тебя 30 компут юнитов нагружают рейтрейсный юнит задачами, каждый отправляет задачи для нескольких модулей. Все лучи бегает по своим подветкам, т.к. некогерентные.
>А при наличии такого волшебного шедулера, непонятно, зачем эти специализированные юниты, в принципе, нужны: существующие шейдерные процессоры справятся не хуже и транзисторы сэкономят.
Это сразу смерть рейтрейсингу: 1. эти юниты не способны обеспечить нужный bandwidth даже в перспективе, 2. их просто очень мало; классических компутюнитов нужно под тысячу, для решения самых минимальных задач рейтрейсинга, при том, что на нынешних мобилах их десятки. 3. энергопотребление улетает в космос.
Вариант который предлагаю я - решает эту проблему за счёт специальной математики, которая позволяет сделать вычисление на меньшем количестве транзисторов, и меньшем количестве памяти. Такая математика на обычные компутшейдера не ложится.
>Оптимум — это когда время обработки полученного из памяти совпадает со временем доступа к этой памяти.
Думай так:
1. существующий формат железа в принципе не способен обеспечить рейтрейсинга. Значит нужно сделать новые модули с новой архитектурой.
2. обычные реализации BVH на fp16 жрут условно метра 3-5. Для быстрых кешей это многовато. Поэтому ужимаем до <1, это позволяет весь BVH впихнуть в быструю память.
3. Получаем спец.блоки с памятью с доступом за один такт и проблема решена.
>Конкретно, 2 ребенка выглядит очень далеким числом от оптимума
Это алгоритмический оптимум под который подстраиваем новое железо.
>Законы физики не позволяют (по крайней мере, в рамках технологии CMOS). Чем больше память, тем дольше до нее доступ.
Да, поэтому один блок имеет доступ только к своей небольшой памяти, а блоков сотни.
}:+()___ [Smile]
> Я думаю, вместо честной многоядерности, будет лучше сделать что-то типа
> гипертрединга на 1024
Ну и получишь дико ригидную структуру без ветвлений. Матрицы считать оно быстро будет, а на хоть сколько-то сложных шейдерах умрёт.
кто тут работал с RadeonRays 2.0?
innuendo
> кто тут работал с RadeonRays 2.0?
Только ты. Раньше АМД были слабее нвидиа, а сейчас ими только майнеры пользуются)
/A\
> Раньше АМД были слабее нвидиа
чьи чипы в последних конзолях?
/A\
> Только ты
Жаль - там просто пример как сделать RT без хардварных фишек на десктопах
innuendo
> Жаль - там просто пример как сделать RT без хардварных фишек на десктопах
Не знаю как за год ситуация там изменилась, но пару лет назад я использовал пример АМД, как обоснование того, что рейтрейсинг без аппаратной оптимизации не нужен для реалтайма.
Это когда железки одного поколения в одном случае выдают 20Глучей, а в другом - меньше одного.
Так то я в 98 году показывал рейтрейсинг даже без видяхи, на десктопе. Ну и что что 2 треугольника всего :)
Mobile Developer
> Не знаю как за год ситуация там изменилась, но пару лет назад я использовал
> пример АМД, как обоснование того, что рейтрейсинг без аппаратной оптимизации не
> нужен для реалтайма.
какой пример ты юзал ? RR2.0 это на opencl
innuendo
> какой пример ты юзал ? RR2.0 это на opencl
Сам не смотрел, брал данные из инета.
Еще одна архитектура для мобильного рейтреса: powervr photon
Вообще я пытался найти их хардварный рейтрейсер 2012-года, но что-то все подчистили.
upd: нашел https://www.gdcvault.com/play/1020741/New-Techniques-Made-Possible-by
/A\
Тема старая, мы их смотрели, но тоже не взлетит. Они её давно предлагают.
Против математики не попрёшь.
Mobile Developer
> Сам не смотрел, брал данные из инета.
а я делал под UE4
innuendo
Шоты/видео есть?
Просто я тоже много чего делал, и для практики и для экспериментов.
И понятное дело, что для кустомных случаев и мизерный бюджет по лучам пойдёт. Но для общего случая, говорить, что 20 (которых тоже мало на что хватает) и 0.5 это что-то сопоставимое - на мой взгляд странно.
Mobile Developer
> Тема старая, мы их смотрели, но тоже не взлетит.
В чем-то они обгоняют нвидию
Тема в архиве.