Стандартное использование барьеров относительно несложно, но мне было интересно, что такое поведение двух (или более) перекрывающихся барьеров изображения (особенно в отношении их побочного эффекта - переход макета). Например. (Псевдокод):Каково поведение перекрывающихся барьеров изображения?
begin(commandBuffer);
1: write(image);
2: imageBarrier(
image,
src=STAGE_FRAGMENT(from the write at 1:),
dst=STAGE_FRAGMENT(intended for read in FS of read at 4:),
appropriate src and dst access flags,
newLayout=A
);
3: imageBarrier(
image,
src=STAGE_FRAGMENT(from the write at 1:),
dst=STAGE_TRANSFER(intended for read by transfer of readT at 5:),
appropriate src and dst access flags,
newLayout=B
);
4: read(image); // through vkCmdDraw -- expects layout A
5: readT(image); // different kind of read through Transfer -- expects layout B
end(commandBuffer);
- Это даже законно? (можете ли вы поддержать его по спецификации?)
- Какова структура изображения в каждой точке программы?
- Для полноты, каков правильный/лучший способ написать это (один производитель, две ситуации с потребителями)? (Подкачки 3: и 4: и сделать это зависимость чтения-чтения?)
Хорошо, это была моя интуиция (это ответственность приложений - как всегда). Я просто задавался вопросом, нужно ли мне выполнять определенный порядок двух функций чтения. (У меня есть трюк с subpasses, но не встроенный, я думаю). – krOoze
@krOoze: вы не можете иметь два независимых прохода, просматривая одно и то же изображение с разными макетами. Один * должен * быть зависимым от другого, так как реализации разрешено чередоваться с обходами, если он не зависит от другого. –
Я имел в виду это (спецификация): «Если два subpasses используют одно и то же вложение в разных макетах, но оба использования доступны только для чтения [...], приложение не должно выражать зависимость между двумя subpasses. .] " – krOoze