Войти
ФлеймФорумПроЭкты

FrameGraph (6 стр)

Страницы: 15 6 7 810 Следующая »
#75
(Правка: 13:14) 13:13, 20 фев. 2019

/A\
как твои ощущения от использования своего middleware для вулкана? для меня процесс написания rendergraph'а вместе с миллионом других обёрток для API объектов занял на два порядка больше времени, чем, собственно, реализация алгоритмов рендера с их использованием. шэдоумеппинг, например, занял 15 минут на написание, потом ещё 5 минут на отладку — то ли опыт, то ли действительно вулканом гораздо удобнее пользоваться из-за строгой типизации и дебаг лееров, но скомпилированный код практически всегда сразу работает правильно, а баги очень легко отлавливаются.

#76
13:30, 20 фев. 2019

Suslik
> а баги очень легко отлавливаются.
Я потратил час пытаясь понять почему белая текстура с форматом RGBA8U в шейдере читается как черная. Оказалось я перепутал формат, нужен был RGBA8_UNorm, а это интовый формат требует usampler2D, слои валидации молчали.

Но в целом мне мой подход с тасками нравится, все состояния сразу заданы и меньше шансов перепутать, через рендер док также можно посмотреть текущий пайплайн и все состояния. Но мне больше всего нравится мой дебагер шейдеров, я с ним отлаживал трассировщик по SDF, сразу видны мелкие ошибки типа промаха на полпикселя и округлений. А так у меня для огл раньше было написано что-то подобное, только без тасков, для прототипирования удобно, а для движка иногда нужен более низкоуровневый доступ. Но у тебя как раз чуть более низкоуровневый.

#77
(Правка: 13:52) 13:42, 20 фев. 2019

/A\
> Я потратил час пытаясь понять почему белая текстура с форматом RGBA8U в шейдере
> читается как черная. Оказалось я перепутал формат, нужен был RGBA8_UNorm, а это
> интовый формат требует usampler2D, слои валидации молчали.
у меня тоже был один трудноотлаживаемый баг, в котором не помогли слои валидации. я всего лишь забыл обнулить значение переменной в шейдере для расчёта суммы чего-то там, в результате в ней был жуткий мусор. я все барьеры перерыл, думая, что это был баг синхронизации, а оказалось, что просто неинициализированный тупняк. вот тут как раз отладчик шейдеров бы помог, но я всю жизнь шейдеры выводом цвета отлаживал. а в этом случае выводится мусор, который как ни выводи, он мусором останется.

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

+ Показать

а как в твоём фреймворке выглядит код построения мипов?

#78
(Правка: 14:01) 13:56, 20 фев. 2019

Suslik
> для меня самой сложной частью пока было реализовать работу с расстановкой
> барьеров при рендере в разные лееры разных мип-уровней.
Так тут 2д массив (слой х мип), я его просто привел к 1д виду и использовал тот же алгоритм, что и для диапазонов буфера.

> а как в твоём фреймворке выглядит код построения мипов?
именно генерацию мипов я просто захардкодил)
https://github.com/azhirnov/FrameGraph/blob/dev/framegraph/Vulkan… sor.cpp#L1717

#79
13:57, 20 фев. 2019

/A\
так алгоритм-то понятен. мне синтаксис интересен.

#80
14:01, 20 фев. 2019

Suslik
Указываю ImageSubresourceRange (те же поля что в вулкане) для блита и копирования, либо ImageViewDesc для передачи в шейдер.
Там в параметрах задается диапазон мипов и слоев.

#81
17:57, 25 фев. 2019

Продолжаю трасировать лучи.
На этот раз полупрозрачные объекты.

rtx depth peeling | FrameGraph

#82
20:54, 25 фев. 2019

Добавил преломления

rtx refraction | FrameGraph

#83
2:46, 26 фев. 2019

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

#84
11:35, 26 фев. 2019

Suslik
Внутренние отражения есть, но чтоб их показать наверное нужно сделать освещение.
Вообще для порядко независимой прозрачности рейтрейс может быть быстрее обычного рендера, на кролика в худшем случае уходит 8 лучей, но случается очень редко, при обычной растеризации пришлось бы 8 раз отрисовать все прозрачные объекты, что достаточно дорого.

#85
14:14, 26 фев. 2019

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

#86
14:26, 26 фев. 2019

kas
У меня только автоматическая расстановка барьеров, ну и просто удобная обертка)
Оптимизация памяти больше актуальна для мобилок и может быть старых консолей, ну и ААА игр.

#87
14:40, 26 фев. 2019

/A\
> У меня только автоматическая расстановка барьеров
ну казалось бы можно и без расставлять? просто их будет чуть больше

/A\
> ну и просто удобная обертка
а в чем удобство? я для себя пока рассматриваю такой подход только с точки зрения оптимизации памяти, но мало ли

#88
14:58, 26 фев. 2019

kas
> а в чем удобство?
Все команды представлены в виде тасков, делаешь зависимости между тасками и они выполняются последовательно, не сделал и можешь их переставлять для оптимизации.
Еще можно автоматически объединять рендер пассы в один с сабпасами, что хорошо для мобилок.

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

#89
5:18, 27 фев. 2019

/A\
> А если автоматизировать, то в любом случае получится аналог фреймграфа.
ну нет. просто есть "дефолтное" состояние. когда надо не оно - переводишь в то которое надо и сразу после - назад. работает отлично, на перф чтобы влияло не похоже, причем и для дх12 тоже самое все

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

Страницы: 15 6 7 810 Следующая »
ФлеймФорумПроЭкты