Мини блог

Ради эксперимента завел канал в телеграм для обзоров статей, конференций и тд.

Тематика та же: C++, графика, vulkan.

Присоединиться

Преимущество такого формата - короткое описание с ссылкой на оригинал и тэги, это позволяет быстро найти нужную статью. 

Как делается поддержка множества конфигураций железа

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

В Metal было несколько подходов, сначала был feature set, а потом его заменили на GPU family с Common/iOS/Mac семействами. Common задает общие фичи для всех конфигураций железа. Часть параметров также требуется запрашивать в рантайме. Сейчас свежее железо типа M1 и A14 имеет почти идентичные характеристики, что сильно упрощает разработку.

В Vulkan огромное количество фич и разнообразные лимиты, даже есть сайт, где можно посмотреть все конфиги: gpuinfo, также добавили слой device_simulation_layer, который частично эмулирует другие девайсы и упрощает тестирование.

Особенности рендер пассов

 Рендер пассы в Vulkan в основном нужны для оптимизации тайлового рендера в мобильных GPU (tile based deferred renderer), для этого в них используются сабпассы.

В чем проблема Vulkan on top of Metal

 MoltenVk и некоторые другие проекты предоставляют возможность использовать Vulkan API поверх Apple Metal API, но внутри они содержат много неэффективного кода.

Volume render, часть 4. Облака

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

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

Как работает host visible память

 Некоторые особенности работы с разными типами памяти в Vulkan.

Vulkan device simulation layer

 Не все знаю и умеют правильно использовать этот слой для тестирования движка на разных конфигах железа.

Главное - этот слой всего лишь меняет информацию, возвращаемую драйвером, на новую, определенную в json. Таким образом слой валидации сможет обнаружить ошибки в использовании констант и в работе с некогерентной памятью.

Детальное описание можно прочитать здесь.

Оптимизация очереди тасков

 Пришло время оптимизировать очередь тасков для job/task system.

В идеале алгоритм выглядит так:

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

Генерация фигур

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

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

Volume render, часть 3. Освещение

Разбираем различные способы освещения объемов.

Volume render, часть 2. Оптимизация

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

Профилирование шейдеров

Не так давно в Vulkan появились расширения GL_ARB_shader_clock  и   GL_EXT_shader_realtime_clock, с их помощью можно получить время работы шейдера и время работы потока в сабгруппе.

Volume render, часть 1

Экспериментирую с рендером объемов и их оптимизацией.

Crash reporting

Что нужно для отправки и обработки крэшей:

1. С помощью google breakpad отлавливается падение приложения или необработанное исключение, далее генерируется минидамп (dmp формат) и вызывается колбэк, из которого можно отправить минидамп на сервер, самому либо средствами breakpad. У меня дополнительно отправляется лог и другие данные, поэтому отправку написал сам через CURL. Также упаковка данных с помощью brotli заметно уменьшает их размер.

2. Должен быть сервер, который принимает крэши и добавляет их в базу данных.

3. Для крэшей используется dmp формат от Майкрософт (описание), формат позволяет добавлять кастомные данные, что и использует breakpad. Чтобы прочитать dmp файл нужен sym файл с информацией об исходном коде приложения, для этого на этапе сборки нужно вызвать "dump_syms.exe app.exe > app.exe.sym". Сам dump_syms.exe должен быть собран той же версией компилятора, что и приложение, поэтому dump_syms.exe из breakpad репозитория не подходит, так как собран более старой версией (vs2015). В breakpad есть парсер дампов  "minidump_stackwalk" в виде консольного приложения, но под windows он не собирается, так что пришлось написать свой парсер основываясь на их исходниках. Из минидампа извлекается информация о системе, callstack, место, адрес в памяти причина падения, например "EXCEPTION_ACCESS_VIOLATION_WRITE 0x0". Это используется для сортировки крэшей.

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

5. Дополнительно можно сохранять pdb файл, это позволит открывать минидамп в студии.

Исходники тут.

Job system

Понемногу пишу движок, на котром обкатываю новые фичи. Среди них - планировщик задач (thread pool, job system, ...).
Какой требуется функционал:

• Зависимости между тасками - то есть таск запускается только когда все его зависимости завершились.
• Отмена тасков - до захвата таска потоком отмену обрабатывает сам планировщик, после - поток в котором выполняется таск.
• Слабые и сильные зависимости - определяет что будет при отмене зависимого таска. При слабой зависимости следующий таск запустится даже при отмене зависимого таска. При сильной зависимости следующий таск также отменяется.
• Кастомные зависимости - таким образом можно добавить зависимость между таском и GPU через VkFence, например.
• Совместимость с другими системами - работа с сетью также сделана на тасках, многопоточный ECS и рендер тоже будет на них и тд.
• Поддержка блокировок - для этого сделана отдельная зависимость InterlockDependency, куда передается callback, который может захватить мютекс или любой другой примитив синхронизации. Особенность в том, что захват идет через try_lock и если захватить не получилось, то таск остается в очереди до следующей проверки, если же получилось захватить, то таск отправляется на выполнение, а после выполнения вызывает функцию что бы разблокировать. Это позволяет не блокировать потоки при доступе к общим данным.

Исходники можно посмотреть тут.

Виртуальная машина для тестирования lock-free

Я знаю, что в clang есть санитайзер для проверки lock-free (и подобных на атомиках) алгоритмов, но мне нужно было что-то более универсальное, поэтому написал свою виртуальную машину, которая подменяет атомики, мютексы и прочее на свою реализацию.

Идея в том, что есть несколько независимых функций, использующих lock-free алгоритм, они рандомно запускаются на множестве потоков, а все синхронизации и кэш флуши, все чтение и запись в общую память сделано через виртуальную машину, где и происходят проверки. Потоков сделано чуть больше чем доступно хардварных потоков, чтоб ОС постоянно приостанавливала работу одних и запускала другие. После обращения к атомикам поток усыпляется на случайное время, это позволяет ловить ошибки, когда операции с двумя и более атомиками никак не синхронизированны и кто-то может вклиниться между ними.

Что обнаруживает виртуальная машина:

• Data race - параллельное чтение и запись в одну и ту же память.
• Пропущенные flush / invalidate cache, когда в другом потоке произошел flush, а в текущем читают без вызова invalidate. Либо когда в память произошла запись, но не вызвался flush.

Ошибки в работе с кэшем невозможно обнаружить на x86 и x64 архитектурах из-за особенностей их работы с кэшем (CISC инструкции). Но эти проблемы проявляются на ARM (RISC инструкции), а постоянно тестировать на телефоне не так уж удобно, тем более проблемы могут очень долго не проявляться.

Исходники и примеры тут.

Краткий обзор вулкан рендера в X4

Изначально постил обзоры в этой теме, но там они уже затерялись, поэтому продублирую тут.

Недавно вышел X4 Foundation, где только вулкан рендер. И реализация рендера оставляет желать лучшего.Даже рендердок не может долго дебажить, где-то портится память и все перестает работать. vktrace тоже не работает. 
Выдает всего 30фпс в 4к даже в пустом космосе... 
Недостатки: 
- general layout для depth buffer 
- барьер включают абсолютно все этапы (src = ALL_COMMANDS, dst = ALL_COMMANDS) и они даже не сгруппированы, то есть может подряд идти 2 таких барьера 
- а еще у всех барьеров стоит флаг DEPENDENCY_BY_REGION, что не имеет смысла 
- шейдеры с дебажной инфой и плохо оптимизированны 
- очень много дескриптор сетов 
- SSAO в полном разрешении, причем нужен только для кабины, где все статично, можно было запечь АО и сэкономить 3мс.

Краткий обзор вулкан рендера в UE4

Изначально постил обзоры в этой теме, но там они уже затерялись, поэтому продублирую тут.

 vkAcquireNextImage вызывается в отдельном потоке и принимает fence, его ожидание происходит в потоке рендера, похоже это такой способ сделать двойную/тройную буферизацию. 
- многопоточногого рендера нету. 
- постоянно вызывается vkCmdResetQueryPool, хотя в пул записывается время, которое сбрасывать не требуется, а на трансфер очереди такое не будет работать. 
- постоянно копируется время из пула в host-visible память, но я не знаю насколько это плохо, я бы все же сделал отложенное копирование. 
- дескриптор сеты сбрасываются каждый кадр, что тратит время цпу и очень плохо для мобилок. 
- очень много дескриптор пулов, что не рекомендуется делать, (366 пулов в демке с частицами) 
- 5 сабмитов на кадр, причем все в конце кадра, это не очень хорошо, так как сабмиты тяжелые. 
- для каждого сабмита создается фенс, который потом нигде не используется. 
- много подряд идущих барьеров, неплохо было бы их сгруппировать. 
- симуляция частиц идет в фрагментном шейдере, вот это интересно. 
- пустой рендер пасс для очистки текстуры, как было в doom. 
- есть dynamic offset для буферов, но смысла в них нет, так как дескриптор сет не переиспользуется.

Граф синхронизаций.
Сконвертированный из трейса код кадра.

Почему на мобилках не рекомендуют сбрасывать дескриптор пулы: pdf

VR эмулятор

На Windows обычно уже установлено приложение Mixed Reality Portal, в котором есть режим эмуляции девайса. Но для разработки под WMR придется использовать DirectX. К счастью есть совместимость с SteamVR, поэтому эмулятор можно использовать и при разработке для OpenVR на OpenGL/Vulkan/DirectX.

Что спрашивают на собеседованиях в геймдев

Архитектура CPU
Какой есть кэш и как работает, скорость доступа к памяти. Модели памяти weak vs strong.
Когда происходят кэш промахи.


Архитектура GPU
Как сгруппированы ядра: stream multiprocessor / compute unit, warp, какие особенности.
Как происходит растеризация, почему вытянутые треугольники это плохо (до перехода на tile based rendering).


Алгоритмы
Типичные вопросы по vector vs list, как работает map, unordered_map, что быстрее по сложности О и что лучше использует кэш. Как сделать быстрый поиск, как ускорить сортировку. Сложность алгоритмов.
Какие паттерны проектирования используются для оптимизации (ECS, DOD).

Выделение памяти на стэке и на куче, в чем разница.

Алгоритмы рендеринга
Forward и deferred rendering, в чем различия, плюсы и минусы, какие оптимизации есть (tiled, clustered).
Physically based rendering в чем особенность, что такое BRDF, какие BRDF есть, в чем отличие.
Техники теней: shadow map, cascaded sm и тд. Фильтрация между каскадами.
Трассировка лучей: SSR, SDF shadows, volume rendering и тд.
Алгоритмы AA: supersampling, MSAA, MLAA, TAA и тд. Как сделать deferred shading с MSAA, как оптимизировать.


Многопоточность
Как получить deadlock. Какие примитивы синхронизации есть. Как работают атомики, что происходит с кэшем (надо расказать про memory order). Какая-нибудь задача на распараллеливание.


Математика
Векторное и скалярное произведение. Кватернионы. Как рассчитать OOBB. Как определить пересекается ли OOBB с frustum и как рассчитать экранные координаты. Задачи на геометрию.


C++
Вопросы про static, inline, virtual. Как работает виртуальная таблица, множественное наследование. Исключения. Move семантика. Плюсы и минусы стандартной библиотеки (stl).