Войти
ПрограммированиеФорумГрафика

Как сделать очень быстрый CPU ray-tracing?

Страницы: 1 2 Следующая »
#0
(Правка: 13:23) 13:21, 11 фев. 2019

Очень классический вопрос с очень не-классическим контекстом. Во первых, как обычно, как сделать самый быстрый CPU ray-tracing? Во вторых, вопросы уже не обычные. Как сделать самую быструю в мире Texture Fetch на CPU, с самой быстрой линейной интерполяцией? Как сделать самый быстрый в мире шейдинг на CPU? Как сдружить некоторые процессы с кешами CPU? Как реализовать тайловый текстуринг на CPU? Как не облажаться с много-мерным программированием (т.е. когда надо менять точки зрения)? И как сделать при этом код очень минималистичным?
Некоторые вопросы я забыл во время написания, возможно вспомню позже. Включить RTX пока не предлагать, и так слишком очевидно. Нам бы к Zen 2 пора готовиться.


#1
(Правка: 13:37) 13:34, 11 фев. 2019

SSE, Threads, Разбиение сцены
https://github.com/prasser/s2r2 - реалтайм, без протормозов, Java, 80 FPS, GPU Intel

#2
13:42, 11 фев. 2019

amber3d
> Очень классический вопрос
amber3d
> как обычно, как сделать самый быстрый
Очевидно , писать надо на самом эффективном языке —на родных машинных кодах 111001110011

#3
15:37, 11 фев. 2019

Посмотри код blender3d, там реализован и кпу и и гпу и гибрилный рейтрес

#4
21:09, 11 фев. 2019

Использовать BVH со spatial split'ами, вроде бы это одна из самых быстрых ускоряющих структур.
Если нужны только прямые лучи - отслеживать пакеты по 4(SSE) или 8(AVX) лучей. Если нужно глобальное освещение, то лучше преобразовать двоичный BVH в дерево с 4 или 8 дочерними узлами и обходить отдельными лучами. Cycles так делает. Такая схема вроде бы быстрее, чем сортировать лучи со случайными направлениями для пакетной трассировки.

#5
(Правка: 21:41) 21:41, 11 фев. 2019

Мне интересны новаторские подходы, привычные "BVH" стали не интересны и скучны мне. Мне бы из разряда гибридного рендринга, либо с применением вокселей. Я например рассматриваю возможность построить иерархию лучей на GPU чтобы с легкостью пересечь геометрию на CPU. То есть с точки зрения самой геометрии.

#6
22:08, 11 фев. 2019
калорифер, ты штоле?
#7
22:13, 11 фев. 2019

запекаешь RT мапы и всё будет летать.

#8
22:26, 11 фев. 2019

Типа как тут http://www.cse.chalmers.se/~uffe/RAH07Electronic.pdf , только пересечение искать на стороне CPU? Вроде примерно понял. Но выходит, что очень много придется перегонять в RAM. Если нода это сфера + конус, то получается около 90мб для full hd. Останется только надеяться, что оно успеет несинхронно перетечь пока готовится следующий кадр.

#9
22:39, 11 фев. 2019

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

#10
22:56, 11 фев. 2019

Ну да, то есть метод хорош для intel hd карт.

#11
8:41, 12 фев. 2019

Никак.
Был тут Калорифер.
Тоже оптимизил да не выоптимизировал.
В итоге он поехал.
Еще железо слабое для быстрого и качественого рей трейсинга.

#12
8:43, 12 фев. 2019

Жди лет 8.

#13
10:12, 12 фев. 2019

Ждин 2^n лет

#14
21:27, 12 фев. 2019

Embree еще не пробовал?

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика