Vulkan API и асинхронность. Введение. Требования к архитектуре

В сфере искусственного интеллекта произошло заметное событие. shagunov 10 минут назад Vulkan API и асинхронность. Требования к архитектуре Средний 9 мин 164 C++ * Обзор ПриветствиеПриветствую Вас, дорогой читатель! В этот раз представляю Вашему вниманию цикл статей, который будет посвящён одной из важнейших тем в программировании на Vulkan API - использование асинхронности и параллелизма для написания производительных движков.

Данный цикл не является туториалом, а лишь моей попыткой исследования основных аспектов асинхронного программирования на Vulkan API. Целью данного исследования - разработать архитектуру, упрощающую управление многопоточным выполнением, в основу которой будет положено использование корутин c++20. Это статья будет посвящена вводной части.

Технические детали

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

Асинхронность — модель взаимодействия, при которой момент инициирования операции отделён от момента получения её результата; результат доставляется позднее через callback/future/promise/poll/awaitable. Параллелизм - модель выполнения, при которой разные задачи исполняются на разных вычислительных ресурсах. Хотя асинхронность и параллелизм и являются различными понятиями, тем не менее, в основе реализации асинхронности может лежать параллелизм.

Мотивация использования асинхронности обусловлена следующим образом. Для ряда компонентов критичен интервал между итерациями основного цикла обработки событий (tick interval); в частности, главный цикл событий не должен блокироваться продолжительным ожиданием операции рендеринга, поскольку это увеличивает задержку обработки событий (latency) и ухудшает восприятие отзывчивости интерфейса (UX). Если скорость поступления событий превышает скорость их обработки, очередь растёт и задержки накапливаются — в системах с ограниченным буфером это может приводить к потере событий.

Отраслевые последствия

Многие этапы рендера (подготовка command buffers, culling, staging uploads) можно выполнять параллельно, тогда как submit → GPU execute → present требуют сохранения порядка. Перенос подготовки или других тяжёлых задач в рабочий поток уменьшает нагрузку главного цикла обработки событий, но требует явной синхронизации и аккуратного управления временем жизни ресурсов (см. раздел о примитивах синхронизации).

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

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

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.