programina
> ты наверно имел в виду перекодирование
Нет, я имел ввиду декодирование, то есть разжатие h264 / vp9 в кадр на экране. С разрешением 8к х 8к не все карточки могут справиться, а для h264 еще и в скорость чтения с диска упирается.
/A\
> Нет, я имел ввиду декодирование, то есть разжатие h264 / vp9 в кадр на экране.
> С разрешением 8к х 8к не все карточки могут справиться, а для h264 еще и в
> скорость чтения с диска упирается.
глупость какая... 1070 читает файл 8192x4096 только в путь. Какой у тебя плеер? Наверно в нем причина.
programina
> Какой у тебя плеер?
MPC-HC, и 2 популярных для VR со стима. Везде лагает.
В таск менеджере пишет 50% нагрузки гпу - декодирование, остальное видимо вывод на экран.
/A\
> еще и в скорость чтения с диска упирается
причем тут скорость диска? Ты сжатый файл читаешь, а не сырой?
programina
> причем тут скорость диска?
Потому что для h264 в хорошем качестве получается 4гб на 1мин видео.
/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 или больше )))
Если не принципиально, то лучше использовать H.265 или H.265 (Nvidia NVEnc), потому что H.265 специально создали для больших разрешений.
programina
Я сейчас проверил те видео, оказалось на нвидии 8к не хочет декодироваться и включается цпу версия, отсюда лаги.
Но остаются еще VR плееры, которые насколько я помню использовали гпу декодер и лагали.
https://github.com/azhirnov/glsl_trace
Вынес либу для отладки шейдеров в отдельный репозиторий и добавил поддержку OpenGL.
Но профайлинг работает только под вулканом.
Сделал запись времени работы шейдера, но почему-то на RTX пайплайн не создается если записывать в storage buffer.
Пришлось руками вставлять это в шейдер.
Что интересного - видны ограничивающие объемы, почему-то на них чуть больше времени тратится. Шейдеры работают тайлами, это видно по квадратности картинки. Еще странно что кролик виден сквозь штору, то есть у них алгоритм находит несколько или все пересечения, а потом уже выбирает ближайшее.
/A\
прикольная инфа
Обновил glsl-trace и FG, там автоматически добавляется замер времени шейдера, а в FG сделана визуализация как на картинках выше.
Хороший кейс, который правильный фреймграф должен оптимизировать:
Из-за того, что у меня отслеживается состояние каждого слоя текстуры такой оптимизации не происходит.
Есть ли смысл вообще строить сложные графы, чтоб сортировать команды? Или проще сделать полуавтоматическую расстановку барьеров и вручную сортировать команды как во втором примере кода?
Тема в архиве.