Size: a a a

pro.graphon (and gamedev)

2020 November 01

U

UsernameAK in pro.graphon (and gamedev)
натягиваю джаву на плюсы
источник

S

Stas in pro.graphon (and gamedev)
Timur Gagiev
чтобы хранить массив этих IEntity с разными виртуальными таблицами
А для чего?
Разве не должен существовать конечный класс, который в себе держит компоненты?
источник

S

Stas in pro.graphon (and gamedev)
(вроде даже не в себе, а в EntitySystem, но ещё не смотрел туда)
источник

S

Stas in pro.graphon (and gamedev)
Timur Gagiev
чтобы хранить массив этих IEntity с разными виртуальными таблицами
Больше гибкости?
Это все вот эти EntityNetwork, EntityAI и так далее - чтобы задавать более специфическое поведение для сущностей?
источник

MK

Michael Kharitonov in pro.graphon (and gamedev)
Всем привет.
источник

MK

Michael Kharitonov in pro.graphon (and gamedev)
В книге по ДХ уделяют внимание тому, что если мы засабмитим на ГПУ кучу команд и начнём сабмитить следующие только тогда, когда она выполнит предыдущие - она будет нас ждать, но мол мы не хотим этого. Логично. Но они предлагают с ЦПУ сабмитить внимание! текущий (n) фрейм, n+1 и n+2 фрейм!

Мне понятен сабмит текущего фрейма. Ок. Мне понятен сабмит следующего, если скажем сейчас ГПУ рисует n-1 фрейм, мы сейчас собираем n фрейм и мы уже получили инпут и знаем кто куда двинется включая игрока для n+1 фрейма, можем собрать и его. Но n+2 это как вообще?
источник

MK

Michael Kharitonov in pro.graphon (and gamedev)
Только я не рендерщик, не бейте сильно ) Для общего развития читаю
источник
2020 November 02

eb

ed braed in pro.graphon (and gamedev)
Michael Kharitonov
В книге по ДХ уделяют внимание тому, что если мы засабмитим на ГПУ кучу команд и начнём сабмитить следующие только тогда, когда она выполнит предыдущие - она будет нас ждать, но мол мы не хотим этого. Логично. Но они предлагают с ЦПУ сабмитить внимание! текущий (n) фрейм, n+1 и n+2 фрейм!

Мне понятен сабмит текущего фрейма. Ок. Мне понятен сабмит следующего, если скажем сейчас ГПУ рисует n-1 фрейм, мы сейчас собираем n фрейм и мы уже получили инпут и знаем кто куда двинется включая игрока для n+1 фрейма, можем собрать и его. Но n+2 это как вообще?
Ну дак ты же на цпу уже можешь и большее кол-во фреймов обработать (в т.ч. получить инпут для n+2), в чём проблема то?
ЦПУ то тоже не в один поток работает (в идеале)..
источник

MK

Michael Kharitonov in pro.graphon (and gamedev)
Не думал что я могу получить ввод для n+2, я же (как игрок) ещё не увидел предыдущий кадр получается?
источник

eb

ed braed in pro.graphon (and gamedev)
Michael Kharitonov
Не думал что я могу получить ввод для n+2, я же (как игрок) ещё не увидел предыдущий кадр получается?
Ну, насколько я это вижу - хоть n+10.. Смотря насколько быстро оно всё ворочается.
Но при сильном рассинхроне цпу/гпу, получим соответствующую картинку (игрок бежит туда, куда он нажал секунду назад).
источник

MK

Michael Kharitonov in pro.graphon (and gamedev)
Ну вот я ожидаю услышать пример с прода ) В теории то что ты сказал - очевидно, почему и вызвало вопрос. В книгах пишут уверенно, не знаешь кому верить ))
источник

eb

ed braed in pro.graphon (and gamedev)
Конкретно про n+1/n+2, надо понимать что мы говорим о 16/32мс (при 60 кадрах) - не вижу проблемы.
источник

U

UsernameAK in pro.graphon (and gamedev)
ну это плюс к латенси ввода не?
источник

U

UsernameAK in pro.graphon (and gamedev)
кстати, решать проблему бендинга дизерингом - это нормально?
источник

S

Stas in pro.graphon (and gamedev)
Я тут добрался до видео.
Они говорят что карточка заточена специально для игр.
А в чём принципиальная разница между видеокартой как ускорителем расчётов и карточкой для игр?
Меня интересует момент если делать запеканки через compute shader-ы. Они такие же быстрые будут по сравнению с nvidia
или же нет?
источник

S

Stas in pro.graphon (and gamedev)
По их собственным замерам не везде они таки выигрывают.
источник

S

Sergey in pro.graphon (and gamedev)
Нет доверия презентациям маркетологов. Нужно смотреть реальные замеры в конкретных приложениях.
источник

S

Sergey in pro.graphon (and gamedev)
"специально для игр" - думаю, это уловка. Nvidia часто говорит о применении их карт в ML, в майнинге и прочих не-игровых областях, и возможно это попытка переманить "игроков"
источник

S

Stas in pro.graphon (and gamedev)
Интересно как у них с дровами обстоят дела. Раньше было не очень как помню
источник

M

Mikhail in pro.graphon (and gamedev)
Michael Kharitonov
В книге по ДХ уделяют внимание тому, что если мы засабмитим на ГПУ кучу команд и начнём сабмитить следующие только тогда, когда она выполнит предыдущие - она будет нас ждать, но мол мы не хотим этого. Логично. Но они предлагают с ЦПУ сабмитить внимание! текущий (n) фрейм, n+1 и n+2 фрейм!

Мне понятен сабмит текущего фрейма. Ок. Мне понятен сабмит следующего, если скажем сейчас ГПУ рисует n-1 фрейм, мы сейчас собираем n фрейм и мы уже получили инпут и знаем кто куда двинется включая игрока для n+1 фрейма, можем собрать и его. Но n+2 это как вообще?
Это чтобы скрывать тормоза. Например _ровно один_ фрейм на гпу тормозит – на 2х фреймах ты получаешь: быстро записали n=1 (он будет тормозить на гпу), засабмитили, быстро подождали n=0 с гпу, быстро записали n=2, засабмитили, долго ждем n=1 с гпу (тормозит)... При 3х фреймах, если гпу в целом тащит, этот единственный фрейм сгладится соседними и на стороне цпу тормозов от него не будет видно. Увеличивая число frames in flight ты скрываешь больше тормозов, но а) ты тратишь больше ресурсов и б) CPU и GPU начинают играть в разные игры. 3 считается оптимальным
источник