Введение в Vulkan Raytracing (комментарии) (5 стр)

Danilw
Я бы не стал приводить Shadertoy как пример, спека по OpenGL ES не гарантирует точность:

> While encodings are logically IEEE 754, operations (addition, multiplication, etc.) are not necessarily performed as required by IEEE 754

В то же время, например, CUDA это гарантирует.

>спека по OpenGL ES не гарантирует точность
>В то же время, например, CUDA это гарантирует.

проблема не в точности, а в алгоритме
я привел в пример тупой "попиксельный рейтрейсинг" что на CPU что на GPU(да если поставить 300+ шагов проблема битых пикселей практически уйдет, но появиться проблема тормозов)
на CUDA будет тоже что я показал https://github.com/clones1201/cudaRayTracing оба скриншота там это показывают (все демки на шадертой идентичны CUDA трейсерам, и на шадертое есть пара трейсеров которые дают идеальную картинку, но пара фпс/мин) вот "фотореалистичный" https://github.com/knightcrawler25/Optix-PathTracer без погрешностей, с рендер таймом по 6 мин на кадр
...кароче это "ray-tracing" vs "physically based path trace"

давай лучше про этот RTX(судя по демкам нвидии) эта проблема что я описал в демо роликах нвидии тоже есть(шагов мало для экономии производительности)
https://youtu.be/tjf-1BxpR9c?t=336 пиксели прыгают на отражении огого как(поэтмоу камеру наверно быстро убрали)
также раньше чайник бликовал, и на 5:12 прыгает отражение самое дальнее

Danilw
ты какую-то дичь выдумываешь. floating-point операции что на GPU, что на CPU могут выполняться хоть с побитово одинаковой точностью. шумные пиксели появляются от реализации алгоритма, а не от того, на чём он запускается.

> пиксели прыгают на отражении огого как
их path tracer за это время элементарно не успевает сходиться к вменяемому решению, поэтому денойзер производит такие артефакты. опять же, абсолютно никакой разницы в качестве картинки между CPU и GPU не будет и быть не может, если алгоритм один и тот же.

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

количество шагов, але

кароче это в чушь уже какуюто зашло

все я не прав(хз в чем но окей) успокойтесь

Danilw
> количество шагов, але
если алгоритм написан оптимально с точки зрения использования вычислительной мощности железа, то вычислительная мощность GPU как минимум на порядок больше. то есть тот же самый код либо отработает на GPU в 10 раз быстрее, либо позволит посчитать в 10 раз больше итераций. это какие-то не очевидные вещи?

Danilw
> вот по быстрому сделал похожую сцену на GPU
> https://www.shadertoy.com/view/XlyBRz (с тенями и отражениями)
Твоя демка даже в маленьком окошке просто ушатала GF980, а GF1080Ti выдала всего 30FPS (в том же маленьком окошке).
Посему не смог проти мимо, и решил заглянуть что же в коде. А там батюшки святы, циклы в циклах в циклах. Тройной вложенности! Это же 96^3 = 884736 итераций. Неудивительно что оно сдохло.
Совершенно не было желания искать, где же ты там точность всю просрал. Поэтому я просто запилил свой код с твоей сценой:
https://www.shadertoy.com/view/XtGfzz
Я выкинул твои "итерации" на мороз, и вообще целиком цикл с освещением переработал. Теперь имеем абсолютную точность и 60FPS даже в фуллскрине.

MrShoor
нормальную OS поставь челик
у меня Nvidia 750 GTS дает 50фпс в окошке, и 20-30 в 1920*1080 (в моем примере)
как у тебя на карте которая в 5-10 раз мощнее моей фпс ниже, я не знаю

>https://www.shadertoy.com/view/XtGfzz
молодец, возьми с полки пирожок
уделал так уделал, бросаю кодинг а удаляюсь из жизни
(что ты этим доказать хотел, кроме своей токсичности я незнаю, извини ес че)
(заменять полноценный рей-трейсер для любых SDF форм на Intersect простых форм(сферы плосности), такое себе)

>Пока писал код дважды! наступил на баги в драйвере. Для одного сделал воркэраунд.
ты наступил на баги в ANGLE, добро пожаловать

>Что инетерсно на GF1080Ti все норм, на GF980 отражения черные.
на 750 нвидии у меня все норм

скорее всего, эта таже проблема с чем я столкнулся тут https://danilw.github.io/cputests/wasm/sgame/best/sgame.html (на Windows будет одна планета черная(которая синего цвета), шум не будет генерироваться) когда тут
https://danilw.github.io/cputests/wasm/sgame/best_wfix/sgame.html с уменьшением цикла генерации шума на 1 все заработает (на Linux очевидно все работает в обоих случаях)
это Angle раскладывает вложения циклов до определенной глубины

Suslik
> ты какую-то дичь выдумываешь. floating-point операции что на GPU, что на CPU
> могут выполняться хоть с побитово одинаковой точностью. шумные пиксели
> появляются от реализации алгоритма, а не от того, на чём он запускается.
У нас в одном софте реализация одного и того же алгоритма на CUDA, OpenCL и CPU дает разную точность. Пришлось даже делать небольшие изменения только чтобы это учесть. Что мы делаем не так?

BingoBongo
> У нас реализация одного и того же алгоритма на CUDA, OpenCL и CPU дает разную
> точность. Что мы делаем не так?

возможно на GPGPU fast math юзается для ряда случаев .. там вроде есть опция в виде "use safe math" (по крайней мере в RadeonRays есть такой параметр) .. правда что это именно для GPGPU не ручаюсь .. :D

>У нас в одном софте реализация одного и того же алгоритма на CUDA, OpenCL и CPU дает разную точность

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

BingoBongo
> У нас в одном софте реализация одного и того же алгоритма на CUDA, OpenCL и CPU
> дает разную точность.

и там и там 64-битные вычисления дают разный результат ?

вроде как в FPU вычисления проводятся и хранятся в регистрах с 80-битной точностью - может в этом ньюанс ?

itmanager85
Везде используется только float без включения доп режимов.
> вроде как в FPU вычисления проводятся и хранятся в регистрах с 80-битной
> точностью - может в этом ньюанс ?
Да, про повышенную точность на CPU x64 я забыл. Но есть еще и различия между CUDA и OpenCL (особенно проявляется, если алгоритм накапливает ошибку).

Danilw
> что ты этим доказать хотел, кроме своей токсичности я незнаю, извини ес че
Эта жи ниточный GPU, рейтрейсер нужна писать на CPU!!!111

> на 750 нвидии у меня все норм
>
> скорее всего, эта таже проблема с чем я столкнулся тут https://danilw.githu…
> st/sgame.html
Это была какая-то странная проблема связки драйвера+ANGLE. В эдже например все оказалось норм. После этого я обновил драйвера (стояли драйвера восьмимесячной давности), и стало все норм и в хроме. В том числе производительность подросла. Но даже подрощенная производительность не дала 60 FPS, а только около 50 на gf980.

вообщем посмотрел я реализацию HLBVH в RadeonRays_SDK. так вот , там закодена самая первая версия HLBVH которая билдится приблизительно раз в 7 медленнее чем ускоренная версия от nVidia (а сейчас она вообще вроде как перешла на TrBvh).

и оказалось что "HLBVH" в RadeonRays_SDK работает только с базовой сценой , а c тестовой (которая отлично работает на "BVH") - нет.

вывод - AMD глючное г..но (хотя для игр вроде норм, но я в них не играю), не даром на стиме любителей их видеокарт всего 17% .. :D

itmanager85
> вывод - AMD глючное г..но (хотя для игр вроде норм, но я в них не играю), не
> даром на стиме любителей их видеокарт всего 17% .
гений дедукции!