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

Методы расчета нормалей воды (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
21:46, 24 июля 2019

Kripto289
> Кстати почему геометрические шейдеры везде не рекомендуют юзать
Из-за того, что они сразу превращаются в геимплейный код. Кашу тормозов, логики и костылей.
Если пиксельный шейдер это image processing. А вершинный тупа трансформ, то геометрический толком не знает большинство.


#31
23:45, 24 июля 2019

lookid
> Из-за того, что они сразу превращаются в геимплейный код. Кашу тормозов, логики
> и костылей.
> Если пиксельный шейдер это image processing. А вершинный тупа трансформ, то
> геометрический толком не знает большинство.
вообще мимо кассы. геометрические шейдеры не используются, потому что их сначала придумали, а потом стали думать, как их эффективно реализовать. в итоге так и не придумали нормального scheduler'а, который бы с них адекватно балансировал нагрузку между ядрами, даже сама nvidia признала это: https://devblogs.nvidia.com/introduction-turing-mesh-shaders/
Изображение

#32
0:37, 25 июля 2019

Suslik
> вообще мимо кассы. геометрические шейдеры не используются, потому что их
> сначала придумали, а потом стали думать, как их эффективно реализовать. в итоге
> так и не придумали нормального scheduler'а, который бы с них адекватно
> балансировал нагрузку между ядрами, даже сама nvidia признала это:
> https://devblogs.nvidia.com/introduction-turing-mesh-shaders/
Я правильно понимаю, что если геометрический шейдер просто обрабатывает текущие патчи или создаёт равное кол-во вершин, то проблема с балансировкой нивелируется? В таком случае потоки имеют примерно одинаковую нагрузку и не ждут самую тормозную задачу?

#33
2:11, 25 июля 2019

Suslik
> геометрические шейдеры не используются, потому что их сначала придумали, а
> потом стали думать, как их эффективно реализовать

это даже не смешно

#34
2:16, 25 июля 2019

innuendo
> это даже не смешно
Согласен, это печально. Только gapi засрали геометрическими шейдерами.

#35
2:28, 25 июля 2019

MrShoor
> Согласен, это печально. Только gapi засрали геометрическими шейдерами.

до тебя не дошло, что это был сарказм ?

#36
2:30, 25 июля 2019
innuendo
> до тебя не дошло, что это был сарказм ?
Нет, до тебя не дошло, что геометрические шейдеры не нужны. И суслик уже все правильно озвучил.
#37
2:38, 25 июля 2019

MrShoor
> Нет, до тебя не дошло, что геометрические шейдеры не нужны

причём так не нужны, что да же в CE/UE используются ... но тут появляются знатоки

#38
2:56, 25 июля 2019

innuendo
> причём так не нужны, что да же в CE/UE используются ... но тут появляются
> знатоки
Ага, используются. От безысходности, ибо в SV_RenderTargetArrayIndex писать можно только из геометрических шейдеров.
Ну еще может квад для поинтспрайта нагенерить. Но это можно и без геометрических легко и так же эффективно сделать.

#39
8:07, 25 июля 2019

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

молодец, показал все свои знания

у нас в LiF использовались для импостеров деревьев в лесу - при большом числе > 10000 gs работало быстрее чем инстансинг

#40
8:10, 25 июля 2019

innuendo
> у нас в LiF использовались для импостеров деревьев в лесу - при большом числе 10000 gs работало быстрее чем инстансинг
чиво. с какой стати ему быть быстрее?

#41
8:13, 25 июля 2019

Suslik
> чиво. с какой стати ему быть быстрее?

вот прям что в железе не так разботает не знаю - подозрение что инстансинг при больших числах задыхается :)

#42
8:20, 25 июля 2019

вот ещё пример использования
http://rastergrid.com/blog/2010/10/opengl-4-0-mountains-demo-released/

#43
(Правка: 8:28) 8:25, 25 июля 2019

innuendo
> вот прям что в железе не так разботает не знаю - подозрение что инстансинг при
> больших числах задыхается :)
ты наркоман что ли? что значит "задыхается"? я 3 года назад тестировал инстансинг и геометрический шейдер для рисования билбордов https://gamedev.ru/code/forum/?id=220480&page=3&m=4361279#m39 и, как и следовало ожидать, разницы нет никакой. тестил до 100к частиц, разница в производительность под погрешностью измерения.

innuendo
> http://rastergrid.com/blog/2010/10/opengl-4-0-mountains-demo-released/
лул, 2010 год. сегодня такой ландшафт можно вообще без геометрии рендерить каким-нибудь minmax octree. или тесселяцией (которая для этого, кстати, и придумывалась). или mesh shader'ом. геометрический шейдер вообще не для этого (а с тем, для чего он придумывался, он справляется отстойно).

#44
(Правка: 27 июля 2019, 19:18) 8:45, 25 июля 2019

Suslik
> до 100к частиц
Вроде XProger где-то десять лет назад делал/показывал тест с миллионом частиц/точек, если я ничего не перепутал. Прогресс однако. // пруфов не будет.

Suslik
> разница в производительность под погрешностью измерения.

Вот финальные результаты по производительности:
Vertex attribs: 100fps
SSBO: 160fps
Instancing: 165fps
Geometry: 165fps

Помню раньше кто-то рассказывал, что если fps ≥ N, то тест возможно УГ. А еще что мерить надо время, а не fps.
Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика