FrameGraph (11 стр)

/A\
Ты делаешь то, что делал раньше драйвер DX11 - неявно расставлял барьеры тут и там.

v1c
Ну да, разница только в том, что у меня должно быть больше информации, чем у драйвера.
На самом деле сейчас драйвер тоже много чего неявно делает.

/A\
блин, там же барьер на слой. неужели оно не может нормально параллельно работать с другим слоем, который уже находится в нужном лейауте?
насколько вообще первый вариант медленнее, чем второй?

HolyDel
> насколько вообще первый вариант медленнее, чем второй?
Я не замерял, но барьер не дает следующим командам начать выполнение, а так может там все в память упирается и от распараллеливания не будет толка, а может наоборот долгие вычисления и куча ядер простаивают. Правильней все же с профайлером пройтись и оптимизировать.

Читал тред, перечитал кучу линков кторые давали, и гуглил, но есть несколько вопросов по фреймграфу:
1. я правильно понимаю что фремграф строится каждый кадр?
2. т.е. например для рендеринга N точечных источников света классическим forward рендерингом с теням нужно добавить
N пассов для генерации шэдомапы (указывать каждому создавать шэдомап текстуру) + N пассов уже непосредственно для освещения ( где на вход каждому указывать сгенеренную шэдомап текстуру)?

Или все совсем не так?

p.s.
Смотрел Granite, там в примерах вроде граф строится только на изменение swapchain.

Outlaw
> 1. я правильно понимаю что фремграф строится каждый кадр?
построение фреймграфа считается быстрой операцией, поэтому нет смысла пытаться его кешировать или оптимизироать. если он станет слишком тяжёлым, тогда можно начинать об этом думать. в типичном геймдев-проекте такого не предвидится.

Outlaw
> 2. т.е. например для рендеринга N точечных источников света классическим
> forward рендерингом с теням нужно добавить
> N пассов для генерации шэдомапы (указывать каждому создавать шэдомап текстуру)
> + N пассов уже непосредственно для освещения ( где на вход каждому указывать
> сгенеренную шэдомап текстуру)?
N пассов на рендеринг шэдоумеп и 1 lighting pass с циклом по всем источникам, нет смысла делать каждый источник отдельным пассом для освещения.

Outlaw
У фреймграфа (как алгоритма) есть возможности:
- выкидывание неиспользуемых пассов
- оптимизация по памяти (переиспользование рендер таргетов)
- правильная расстановка барьеров (это больше дх12 и вулкан)

У каждого фреймграф делает часть из этих функций разными способами. Я в итоге отказался от первых 2х пунктов из-за многопоточности. Еще и потерял производительность на ЦП из-за накапливания дроуколов.

> 1. я правильно понимаю что фремграф строится каждый кадр?
У меня нет, есть граф внутри командного буфера и граф для синхронизаций между очередями. Командный буфер не блокирует другие потоки. Граф синхронизаций блокирует только при добавлении в него командного буфера.

> 2
Обычно 1 пасс - это рисование в 1 фреймбуфер. Если у тебя атлас теней или каскад, то можно за 1 пасс отрисовать все.

Suslik
> построение фреймграфа считается быстрой операцией
Зависит от содержимого, если отслеживать состояния всех ресурсов и диапазонов внутри них, то совсем не быстро.

Suslik
> N пассов на рендеринг шэдоумеп и 1 lighting pass с циклом по всем источникам,
> нет смысла делать каждый источник отдельным пассом для освещения.
Т.е. для данного паса необходимо будет указывать все N шэдоумапов как входные параметры?

/A\
> У фреймграфа (как алгоритма) есть возможности:
> - выкидывание неиспользуемых пассов
> - оптимизация по памяти (переиспользование рендер таргетов)
> - правильная расстановка барьеров (это больше дх12 и вулкан)
>
> У каждого фреймграф делает часть из этих функций разными способами. Я в итоге
> отказался от первых 2х пунктов из-за многопоточности. Еще и потерял
> производительность на ЦП из-за накапливания дроуколов.
На этапе компиляции я планирую выкидывать неиспользуемые пассы, строить граф зависимостей, делать группировку пассов уже по физическим потокам.
На этапе выполнения уже заполнять command list каждый в своем потоке. Финальный сабмит command list в command queue уже в основном потоке. Барьеры у каждого command list расставляются локально, а при финальном сабмите уже апдейтить глобальные состояния ресурсов.

Просто мне как то тяжело представить как можно один раз собрать граф и его использовать, кроме как полностью для статической сцены. Ведь число источников света в кадре например может меняться, сам источник быть ближе дальше что например влияет на размер шэдомапы и т.д.
Кроме как только это все отслеживать и пересобирать граф при изменениях.

P.s.
Пасиб за ответы парни.

Outlaw
> Т.е. для данного паса необходимо будет указывать все N шэдоумапов как входные
> параметры?
если все лайты можно отренедить за один пасс, зачем вместо этого делать N пассов? тени, например, рендерятся за N пассов, если каждая из них рендерится в отдельный таргет (без атласа), тогда выбора нет. а если что-то можно упаковать в один пасс, то это почти всегда имеет смысл сделать.

Outlaw
> а при финальном сабмите уже апдейтить глобальные состояния ресурсов.
я все ресурсы разбил на две составляющие: сам ресурс, который хранит immutable данные: всякие хендлы, размеры, форматы итп. и прокси, указывают на ресурс и хранят в себе его состояние, которое может модифицроваться во время работы фреймграфа. таким образом сам ресурс — это независимая от фреймграфа сущность, их точно так же можно байндить в дескрипторсеты и всё такое прочее, но для них фреймграф не будет генерировать барьеры синхронизации. и на самом деле большинство ресурсов в игре (например, обычные текстуры объектов, env map'ы) после загрузки вообще нет смысла отслеживать фреймграфом, потому что их состоние не меняется. а разруливает фреймграф только прокси — всякие рендертаргеты, текстуры, пока они стримятся, итп.

например, вот тут https://github.com/Raikiri/LegitEngine/blob/master/src/Render/Ren… umeRenderer.h можешь посмотреть, как байндится specularCubemapView (который загружается один раз при загрузке сцены и не отслеживается фреймграфом) по сравнению с accumulatedLightImageView , который отслеживается графом через accumulatedLightViewProxy.

Кстати, энкодеры в метале похожи на пассы рендерграфа.