Использование барьеров трубопровода вместо семафоров - vulkan


1

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

Мне кажется, что синхронизация является самой сложной задачей в Вулкане. ИМО в спецификации недостаточно ясно об этом.

Источник
  •  37
  •  2
  • 16 мар 2020 2020-03-16 08:21:41

2 ответа

0

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

Спецификация Vulkan 1.0.35 улучшила формулировку, которая делает это ясным:

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

...

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

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

3

Преамбула:

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

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

Необходимые определения:

Трубопровод - это абстрактная схема обработки единицы продукции. Существует четыре типа (хотя Vulkan не говорит поставщикам, как делать вещи, если они следуют правилам):

  1. Псевдопроводность доступа к хосту (с одним этапом)
  2. Передача (с одного этапа)
  3. Вычислить (с одним этапом)
  4. Графика (с множеством этапов, т.е. DI → VI → VS → TCS → TES → GS → EFT → FS → LFT → Выход)

Существуют специальные этапы TOP (прежде чем что-либо делается), BOTTOM (после того, как все закончено) и ALL (что совпадает с битовым полем со всеми установленными этапами).

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

Командный буфер представляет собой некоторую последовательность команд (в записанном порядке!). И очередь представляет собой череду записанных команд (объединенных из подчиненных командных буферов).

Очередь имеет некоторую свободу действий, в которой он выполняет команды (он может изменять порядок команд до тех пор, пока сохраняется состояние пользовательского набора), а также может перекрывать команды (например, выполнить VS следующей команды перед завершением FS предыдущей команды). Пользовательские примитивы синхронизации устанавливают границы этого ограничения. (Есть также некоторые скрытые гарантии - но лучше не полагаться на них и чрезмерно синхронизировать до уверенности)

Я беру на себя объяснение барьеров трубопроводов:

(Возможно, к сожалению) барьеры трубопроводов объединяют три отдельных аспекта - барьер выполнения, барьер памяти и переход макета (если это изображение).

Часть барьера выполнения гарантирует, что все команды, записанные до того, как Барьер достигнут в exececution, по крайней мере, на указанной стадии (или этапах) srcStageMask в srcStageMask до того, как какая-либо из команд, записанных после того, как Барьер начнет выполнение заданного этапа (или этапов) в dstStageMask.

Он обрабатывает только зависимость от выполнения, а не память! Часть барьера памяти гарантирует, что память (кэши) должным образом очищена и недействительна где-то между этой зависимостью от барьеров (т.е. после зависимых и до зависимых команд и этапов).

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

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

  • 16 мар 2020 2020-03-16 08:21:42