четверг, 30 августа 2018 г.

FrameGraph. часть 2

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

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

FrameGraph. часть 1

  Здесь будет рассказано о функциях фреймграфа: управление памятью, управление ресурсами, оптимизация кадра и тд.

FrameGraph. часть 0

  Начитался я презентаций от Dice, а также советов по оптимизации vulkan-рендерера, и захотел когда-нибудь написать свой фреймграф, и так уж получилось, что время на это нашлось...
  Для начала, что в моем представлении делает фреймграф - создает слой абстракции от низкоуровневого api (Vulkan, DX12), в отличие от различных graphics framework, фреймграф использует конкретный способ представления кадра - как набор узлов (задач), которые формируют граф. Такое представление кадра позволяет распараллелить некоторые задачи (раньше это не позволяло ни api, ни железо), оптимизировать память временных ресурсов, так как определены моменты начала и конца использования, наилучшим образом выставлять барьеры и тд.
  Первоначально я написал фреймграф на своем движке, реализация оказалось немного неудачной и, (так уж получилось) нашлось время на полное переделывание фреймграфа, на этот раз это будет отдельная либа с минимумом зависимостей и только на vulkan api, но абстракция позволяет добавить любое другое api. 

  Визуализация графа в программе GraphViz, это была не финальная реализация и тут отсутствуют некоторые связи между ресурсами. Зато хорошо видно как раставлены барьеры (маленькие узлы графа), разные типы узлов (красные - рисование, фиолетовые - копирование), видно как задачи отсортированы и некоторые из них могут выполняться параллельно.

пятница, 13 июля 2018 г.

Интересные блоги

Чтоб не потерялось решил и тут сохранить интересные блоги и прочее.

Блоги
Real world technologies
The ryg blog
The Danger Zone
AMD GPU Open
Demo fox
KOSMONAUT'S BLOG
Adam Sawicki Blog
Krzysztof Narkowicz blog
nlguillemot blog
Outerra
Tom's Computer Graphics Research
Humus
Intel GameDevTech


Статьи по рендеру
SDF shadows2
Shadow of War: performance & memory optimization - особенно интересно про sparse memory
Precomputed Global Illumination in Frostbite
FrameGraph in Frostbite
GPU-based clay simulation and ray-tracing tech in Claybook
Thinking Parallel23 - BVH raytracing
Physically Based Rendering - online книга

Статьи по GPU
Breaking down barriers - как работают синхронизации на GPU
OpenGL pipeline - начальный уровень
Подробный разбор графического конвеера - более продвинутый уровень
Про особенности GTX 1080 и GTX 2080

Статьи по ECS и DOD
ECS & DOD - начальный уровень
[video] multithreaded compile-time ECS

Статьи (разное)
Про std::atomicеще
Handles are the better pointers
Job system

Демо
PixelFlow

четверг, 7 декабря 2017 г.

Планы по развитию движка

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

воскресенье, 5 ноября 2017 г.

  Наконец-то увидел под какую же машину я разрабатывал))
На 0:42 знакомый UI, подробного обзора навигации пока не нашел, но машинка красивая))


суббота, 15 апреля 2017 г.

Модульная архитектура

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

вторник, 7 февраля 2017 г.

OpenCL vs OpenGL vs CUDA

  Небольшое сравнение функционала этих API для GPGPU. Тестов на производительность не будет, только удобство использования API.

четверг, 12 января 2017 г.

Просто скриншоты с работы

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

среда, 4 января 2017 г.

Разбор багов компиляторов и программистов

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

воскресенье, 13 ноября 2016 г.

Долгий путь борьбы с глобальными переменными

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

пятница, 4 ноября 2016 г.

Shadertoy!

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

вторник, 25 октября 2016 г.

Перезапуск

  За последний год я обновил движок, поэкспериментировал с системами частиц, разобрался с distance field, рейтресом, процедурной генерацией. Теперь пришло время опробовать все это в большом проекте, поэтому буду периодически выкладывать результаты.
  А пока немного скриншотов и видео:

среда, 19 февраля 2014 г.

Долгий анализ входящего смс

  В процессе улучшения работы анализа смс сообщения наткнулся на одну проблему в работе BroadcastReceiver'а: при долгом анализе сообщения в функции onReceive процесс прибивался и не получалось отфильтровать ненужное сообщение.
  На версии до 2.3.3 (API 10) на работу внутри onReceive выделялось больше времени, в версии 3.0 (API 11) время сократили, но появилась функция goAsync() возвращающая BroadcastReceiver.PendingResult, что позволяет делать тяжелую обработку в параллельном потоке и не нагружать главный. На работу в параллельном потоке дается 10 секунд, этого вполне достаточно. Следующий в очереди BroadcastReceiver не будет вызван до вызова BroadcastReceiver.PendingResult.finish(), так же есть функция BroadcastReceiver.PendingResult.abortBroadcast() чтоб прервать дальнейшую обработку события.

  Вариант с выносом обработки в Service для меня не подошел из-за невозможности вызвать другие обработчики смс. Для эмуляции прихода нового сообщения необходимо разрешение BROADCAST_SMS которое доступно только системным приложениям. Был вариант с имитацией получения смс, для этого нужно было показать уведомление и добавить во входящие (остальные изменения имитировать не получится), но по приведенной выше причине, а также из-за возможных проблем на версии 4.4, этот вариант не подошел.
  Ну и ссылка на приложение: SMS Spam Filter ))

среда, 10 июля 2013 г.

среда, 9 января 2013 г.

Некоторые особенности OpenGL

 За время использования OpenGL последних версий (3.3 и выше) накопилось не мало особенностей в его использовании, а так же отличия реализаций от nVidia и AMD, поэтому сформировал небольшой (пока) сборник.

среда, 3 октября 2012 г.

Двухсторонняя карта смещения.

Сейчас пишу игру на конкурс шутеров на gamedev.ru. В игре планирую использовать несколько интересных техник и по мере реализации буду писать о них здесь.
Первая техника - двухсторонняя карта смещения (dual-sided dismplacement map) используется для создания разрушаемых стен, полов и других аналогичных поверхностей (далее для простоты буду называть такие поверхности стенами).