FrameGraph (10 стр) / ПроЭкты / Форум / Флейм / GameDev.ru

programina
> ты наверно имел в виду перекодирование
Нет, я имел ввиду декодирование, то есть разжатие h264 / vp9 в кадр на экране. С разрешением 8к х 8к не все карточки могут справиться, а для h264 еще и в скорость чтения с диска упирается.

programina
Постоялец

#136
20:54, 28 мар. 2020

/A\
> Нет, я имел ввиду декодирование, то есть разжатие h264 / vp9 в кадр на экране.
> С разрешением 8к х 8к не все карточки могут справиться, а для h264 еще и в
> скорость чтения с диска упирается.
глупость какая... 1070 читает файл 8192x4096 только в путь. Какой у тебя плеер? Наверно в нем причина.

$Андрей (/A\)$

/A\
Участник

#137
(Правка: 20:59) 20:58, 28 мар. 2020

programina
> Какой у тебя плеер?
MPC-HC, и 2 популярных для VR со стима. Везде лагает.
В таск менеджере пишет 50% нагрузки гпу - декодирование, остальное видимо вывод на экран.

programina
Постоялец

#138
20:59, 28 мар. 2020

/A\
> еще и в скорость чтения с диска упирается
причем тут скорость диска? Ты сжатый файл читаешь, а не сырой?

$Андрей (/A\)$

/A\
Участник

#139
21:00, 28 мар. 2020

programina
> причем тут скорость диска?
Потому что для h264 в хорошем качестве получается 4гб на 1мин видео.

programina
Постоялец

#140
(Правка: 29 мар. 2020, 0:06) 21:18, 28 мар. 2020

/A\
> MPC-HC
у себя записала видео 32 секунды размером 8192х4096, оно весит 2.44 Гб (mjpeg сжатие).
В программе Handbrake -> вкладка видео -> кодек видео H.264, постоянное качество 23, пресет кодирования Ultrafast, галочка "Быстрое декодирование".
На выходе видео размером 1.1 Гб. Вполне сносно читается MPC-HP. Если никуда не торопишься, то можешь поставить вместо Ultrafast например Fast, а постоянное качество уменьшить с 23 до 27, тогда файл у тебя будет намного меньше по размеру и будет шустро читаться с диска.

~~PS: качество 23 - это для HD, в случае с 8K думаю можно сделать 27 или больше )))~~

programina
Постоялец

#141
21:37, 28 мар. 2020

Если не принципиально, то лучше использовать H.265 или H.265 (Nvidia NVEnc), потому что H.265 специально создали для больших разрешений.

programina
Постоялец

#142
(Правка: 23:36) 23:22, 28 мар. 2020

+ 1.31 Гб на 32 секунды

+ Кадр из полученного видео

− Скрыть

В-общем, вот. С гугл-диска (статистика в верхнем левом углу не относится к видео, она записалась во время записи видео из движка):

$Андрей (/A\)$

/A\
Участник

#143
23:31, 28 мар. 2020

programina
Я сейчас проверил те видео, оказалось на нвидии 8к не хочет декодироваться и включается цпу версия, отсюда лаги.
Но остаются еще VR плееры, которые насколько я помню использовали гпу декодер и лагали.

programina
Постоялец

#144
(Правка: 23:49) 23:49, 28 мар. 2020

+ Те же настройки, только H.265, уменьшают размер файла до 231 Мб

+ Качество видео не изменилось

$Андрей (/A\)$

/A\
Участник

#145
1:29, 5 апр. 2020

https://github.com/azhirnov/glsl_trace
Вынес либу для отладки шейдеров в отдельный репозиторий и добавил поддержку OpenGL.
Но профайлинг работает только под вулканом.

$Андрей (/A\)$

/A\
Участник

#146
0:06, 9 мая 2020

Сделал запись времени работы шейдера, но почему-то на RTX пайплайн не создается если записывать в storage buffer.
Пришлось руками вставлять это в шейдер.

Что интересного - видны ограничивающие объемы, почему-то на них чуть больше времени тратится. Шейдеры работают тайлами, это видно по квадратности картинки. Еще странно что кролик виден сквозь штору, то есть у них алгоритм находит несколько или все пересечения, а потом уже выбирает ближайшее.

+ Показать

Suslik
Модератор

#147
5:39, 9 мая 2020

/A\
прикольная инфа

$Андрей (/A\)$

/A\
Участник

#148
15:08, 11 мая 2020

Обновил glsl-trace и FG, там автоматически добавляется замер времени шейдера, а в FG сделана визуализация как на картинках выше.

$Андрей (/A\)$

/A\
Участник

#149
15:48, 23 авг. 2020

Хороший кейс, который правильный фреймграф должен оптимизировать:

+ Самый_медленный_код

− Скрыть

VkImage heightMapArray;
VkImage normalMapArray;

for (int i = 0; i < 32; ++i)
{
  // heightMapArray[i]: undefined -> general
  vkCmdPipelineBarrier( ... );

  // идет запись в heightMapArray[i]
  vkCmdDispatch( ... );

  // heightMapArray[i]: flush & invalidate cache
  // normalMapArray[i]: undefined -> general
  vkCmdPipelineBarrier( ... );

  // идет чтение из heightMapArray[i] и запись в normalMapArray[i]
  vkCmdDispatch( ... );

  // normalMapArray[i]: flush cache
  vkCmdPipelineBarrier( ... );
}

+ Как_должно_быть

− Скрыть

VkImage heightMapArray;
VkImage normalMapArray;

// heightMapArray: undefined -> general
vkCmdPipelineBarrier( ... );

for (int i = 0; i < 32; ++i)
{
  // идет запись в heightMapArray[i]
  vkCmdDispatch( ... );
}

// heightMapArray: flush & invalidate cache
// normalMapArray: undefined -> general
vkCmdPipelineBarrier( ... );

for (int i = 0; i < 32; ++i)
{
  // идет чтение из heightMapArray[i] и запись в normalMapArray[i]
  vkCmdDispatch( ... );
}

// normalMapArray: flush cache
vkCmdPipelineBarrier( ... );

Из-за того, что у меня отслеживается состояние каждого слоя текстуры такой оптимизации не происходит.
Есть ли смысл вообще строить сложные графы, чтоб сортировать команды? Или проще сделать полуавтоматическую расстановку барьеров и вручную сортировать команды как во втором примере кода?