Я прочитал почти все, что 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 и использовать «быстрый» барьер (тот, который не синхронизируется), который выполняет только изменение макета. Имеет ли это смысл? Как будет выглядеть этот барьер? Или «полный» барьер в этом случае неизбежен?
Краткая версия моих вопросов проста: как другие люди выполняют синхронизацию вложений в сочетании с неявными переходами макета?