- innuendo
- Забанен
http://on-demand.gputechconf.com/gtc-kr/2018/pdf/HPC_Minseok_Lee_NVIDIA.pdf
вот тут немного как юзать tensor core, правда, через cuda
Prescott
Обходим все пиксели начиная от источника света по спирали, для каждого проверяем видимость трассировкой до источника методом Брезенхэма. НО! Если луч попадает между двумя лучами, ранее пропущенными через некоторый пиксель (рассматриваем пиксель как квадрат с некоторыми размерами, для луча считаем с субпиксельной точностью координаты входа), то если у тех двух одинаковый результат на пути до источника (достиг/не достиг), то и у рассматриваемого луча результат будет тот же. Я думаю, можно сделать освещение сцены за O(число пикселей)
P.S. Есть идеи и для 3D, излагал в теме про Рендеринг в Minecraft, самому пока лень сделать
Aslan
> Обходим все пиксели начиная от источника света по спирали, для каждого
> проверяем видимость трассировкой до источника методом Брезенхэма. НО! Если луч
> попадает между двумя лучами, ранее пропущенными через некоторый пиксель
> (рассматриваем пиксель как квадрат с некоторыми размерами, для луча считаем с
> субпиксельной точностью координаты входа), то если у тех двух одинаковый
> результат на пути до источника (достиг/не достиг), то и у рассматриваемого луча
> результат будет тот же
можно то же самое сделать через обычный обход в ширину. вопрос тут не в том, как это сделать, а как это эффективно реализовать на gpu, потому что в твоём случае каждый пиксель оказывается потенциально зависим от всех пикселей, обработанных до него, то есть самый отстойный вариант для gpgpu.
также результатом работы твоего алгоритма будет освещение от одного источника света, а для расчёта GI нужно то же самое, только считая каждый пиксель источником.
твит в тему https://twitter.com/viniciuskps/status/1194746016446189568
реалтайм GI на вулкане(с низкой нагрузкой на GPU)
код уже в вулкан-репозитории Godot, но там все течет и падает лишь как демонстрация годиться покачто
Suslik
> можно то же самое сделать через обычный обход в ширину
нет, потому что более близкий к источнику света пиксель может оказаться позже достигнутым
> каждый пиксель оказывается потенциально зависим от всех
> пикселей, обработанных до него
И лежащих вблизи того же луча к источнику. Алгоритм возможно распараллелить
ещё по теме)
https://twitter.com/TeemuVaisanen/status/1125869673470464001
https://twitter.com/TeemuVaisanen/status/1125484112826044417
Mr F
мне тут мысль пришла про ускорение ray-trace - может у nvidia сделано что-то вроде параллельной проверки - типа за один вызов чекаем 1K трианглов ?
проверки - типа за один вызов чекаем 1K трианглов
Скорей всего.
innuendo
троллируешь?) вроде гпу не славятся однопоточностью)
Наверно у Инуендо однопоточный GPU :)
Mr F
> троллируешь?) вроде гпу не славятся однопоточностью)
не в многих потоках - типа SIMD
если знаешь как nvidia ускоряет rt - расскажи
Mr F
> ещё по теме)
> https://twitter.com/TeemuVaisanen/status/1125869673470464001
> https://twitter.com/TeemuVaisanen/status/1125484112826044417
выглядит как https://www.shadertoy.com/view/ltyyD1
сложение кадров, практически уверен что так
innuendo
> не в многих потоках - типа SIMD
а, в этом плане - понял.
ну кто бы знал, может быть, а может и не быть. я не встречал пейперов с такими подробными деталями.
Danilw
ну аккумуляция какая-то явно происходит, но разве ж в этом что-то плохое
Mr F
> я не встречал пейперов с такими подробными деталями.
а как ещё можно радикально ускорить?
Mr F
кстати, в dx12 семплах есть raytrace fallback - можно посмотреть как емулируется
Тема в архиве.