Vulkan: синхронизация вложений с неявными переходами макета

Question

Я прочитал почти все, что Google дал мне в этой теме, и не смог прийти к удовлетворительному выводу. По сути, это следующий вопрос:

Макеты движущихся изображений с барьером или проходами рендеринга

Предположим, у меня есть цветное вложение, которое записывается в один проход рендеринга и отбирается во втором. Пусть в обоих проходах рендеринга будет только один подпроход. Одним из способов обработки перехода и зависимостей макета является добавление барьера между двумя проходами рендеринга, который меняет макет с VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL на VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.

Но Vulkan также предлагает неявные переходы макета (vkAttachmentDescription, initialLayout и finalLayout). Я предполагаю, что их использование дает преимущество в производительности, поэтому давайте просто попробуем избавиться от нашего барьера. Мы устанавливаем поля initialLayout и finalLayout в структуре vkAttachmentDescription и удаляем барьер. Проблема в том, что мы потеряли синхронизацию, обеспечиваемую барьером, поэтому нам нужно вернуть синхронизацию другими способами. И вот тут начинается неразбериха, которая приводит к моим вопросам:

1) Каков рекомендуемый способ синхронизации вложения между двумя проходами рендеринга? Очевидно, что я мог бы просто заново добавить барьер и не изменять макет, но разве это не противоречит цели всего упражнения, а именно: получить лучшую производительность с помощью неявных переходов макета и избавиться от барьера? Или я должен добавить зависимость подпроцесса от одного подпрохода прохода рендеринга 1 до VK_SUBPASS_EXTERNAL? Есть ли какие-либо предостережения от использования VK_SUBPASS_EXTERNAL с точки зрения производительности?

2) Как насчет синхронизации вложения в обратном направлении? Приложение отвечает за перевод приложения в правильное начальное расположение, что, очевидно, может быть выполнено с помощью барьера. Можно ли заменить этот барьер, чтобы получить преимущество в производительности? Единственный способ, о котором я могу думать, - это сделать часть зависимости с зависимостью подпроцесса от VK_SUBPASS_EXTERNAL до одного подпрохода прохода рендеринга 1 и использовать «быстрый» барьер (тот, который не синхронизируется), который выполняет только изменение макета. Имеет ли это смысл? Как будет выглядеть этот барьер? Или «полный» барьер в этом случае неизбежен?

Краткая версия моих вопросов проста: как другие люди выполняют синхронизацию вложений в сочетании с неявными переходами макета?

Answer 1

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

В вашем случае у вас есть 2 варианта: барьеры или механизмы прохода рендеринга (зависимости подпрохода и переходы макета). Барьеры работают с чем угодно; им все равно, откуда исходит изображение, для чего оно используется или куда оно идет. Механизмы прохода рендеринга работают только с вещами, которые происходят в проходе рендеринга, и в основном работают с изображениями, прикрепленными к проходам рендеринга (неявные переходы макета только работают с вложениями).

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

Именно поэтому, если у вас есть две «отдельные» операции рендеринга, которые могут быть в одном проходе рендеринга (если вы читаете из вложения способом, который может соответствовать ограничениям входные вложения), вы должны предпочесть поместить их в тот же проход рендеринга.

Answer 2

Краткая версия моих вопросов проста: как другие люди выполняют синхронизацию вложений в сочетании с неявными переходами макета?

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

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

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