FrameGraph. часть 2

  Итак, первый этап разработки фреймграфа завершен, тесты написаны, картинка рисуется. Но похожих проектов уже несколько на гитхабе и намного больше в приватных репозиториях и в коммерческих проектах. Так как доказать, что мое решение лучше? А если не лучше, то как сделать его таковым?

  Нужны тесты на производительность. Но писать их долго, тем более нужно с чем-то сравнивать и желательно с чистым вызовами vulkan api, да еще с наилучшей оптимизацией. Это конечно весело, но хочется побыстрее получить результат, поэтому я стал искать другие варианты и нашел - слой vktrace позволяет записывать все вызовы vulkan api и потом проигрывать их заново. Остается только конвертировать сохраненный трейс в C++ код с вызовом чистого vulkan api и с вызовом FrameGraph api, таким образом можно за короткое время получить множество тестов на производительность и корректность рендеринга (сравнивая кадры), да еще и не на простых демках, а на реальных играх и приложениях.

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

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