Изначально постил обзоры в этой теме, но там они уже затерялись, поэтому продублирую тут.
Недавно вышел X4 Foundation, где только вулкан рендер. И реализация рендера оставляет желать лучшего.Даже рендердок не может долго дебажить, где-то портится память и все перестает работать. vktrace тоже не работает.
Выдает всего 30фпс в 4к даже в пустом космосе...
Недостатки:
- general layout для depth buffer
- барьер включают абсолютно все этапы (src = ALL_COMMANDS, dst = ALL_COMMANDS) и они даже не сгруппированы, то есть может подряд идти 2 таких барьера
- а еще у всех барьеров стоит флаг DEPENDENCY_BY_REGION, что не имеет смысла
- шейдеры с дебажной инфой и плохо оптимизированны
- очень много дескриптор сетов
- SSAO в полном разрешении, причем нужен только для кабины, где все статично, можно было запечь АО и сэкономить 3мс.
воскресенье, 18 августа 2019 г.
Краткий обзор вулкан рендера в UE4
Изначально постил обзоры в этой теме, но там они уже затерялись, поэтому продублирую тут.
vkAcquireNextImage вызывается в отдельном потоке и принимает fence, его ожидание происходит в потоке рендера, похоже это такой способ сделать двойную/тройную буферизацию.
- многопоточногого рендера нету.
- постоянно вызывается vkCmdResetQueryPool, хотя в пул записывается время, которое сбрасывать не требуется, а на трансфер очереди такое не будет работать.
- постоянно копируется время из пула в host-visible память, но я не знаю насколько это плохо, я бы все же сделал отложенное копирование.
- дескриптор сеты сбрасываются каждый кадр, что тратит время цпу и очень плохо для мобилок.
- очень много дескриптор пулов, что не рекомендуется делать, (366 пулов в демке с частицами)
- 5 сабмитов на кадр, причем все в конце кадра, это не очень хорошо, так как сабмиты тяжелые.
- для каждого сабмита создается фенс, который потом нигде не используется.
- много подряд идущих барьеров, неплохо было бы их сгруппировать.
- симуляция частиц идет в фрагментном шейдере, вот это интересно.
- пустой рендер пасс для очистки текстуры, как было в doom.
- есть dynamic offset для буферов, но смысла в них нет, так как дескриптор сет не переиспользуется.
Граф синхронизаций.
Сконвертированный из трейса код кадра.
Почему на мобилках не рекомендуют сбрасывать дескриптор пулы: pdf
vkAcquireNextImage вызывается в отдельном потоке и принимает fence, его ожидание происходит в потоке рендера, похоже это такой способ сделать двойную/тройную буферизацию.
- многопоточногого рендера нету.
- постоянно вызывается vkCmdResetQueryPool, хотя в пул записывается время, которое сбрасывать не требуется, а на трансфер очереди такое не будет работать.
- постоянно копируется время из пула в host-visible память, но я не знаю насколько это плохо, я бы все же сделал отложенное копирование.
- дескриптор сеты сбрасываются каждый кадр, что тратит время цпу и очень плохо для мобилок.
- очень много дескриптор пулов, что не рекомендуется делать, (366 пулов в демке с частицами)
- 5 сабмитов на кадр, причем все в конце кадра, это не очень хорошо, так как сабмиты тяжелые.
- для каждого сабмита создается фенс, который потом нигде не используется.
- много подряд идущих барьеров, неплохо было бы их сгруппировать.
- симуляция частиц идет в фрагментном шейдере, вот это интересно.
- пустой рендер пасс для очистки текстуры, как было в doom.
- есть dynamic offset для буферов, но смысла в них нет, так как дескриптор сет не переиспользуется.
Граф синхронизаций.
Сконвертированный из трейса код кадра.
Почему на мобилках не рекомендуют сбрасывать дескриптор пулы: pdf
Подписаться на:
Сообщения (Atom)