2016-07-30 4 views
3

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

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); 
  1. Это даже законно? (можете ли вы поддержать его по спецификации?)
  2. Какова структура изображения в каждой точке программы?
  3. Для полноты, каков правильный/лучший способ написать это (один производитель, две ситуации с потребителями)? (Подкачки 3: и 4: и сделать это зависимость чтения-чтения?)

ответ

2

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

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

1: write(image); 
2: imageBarrier(image, src=COLOR_ATTACHMENT_OUT, dst=FRAGMENT_SHADER, newLayout=A); 
3: read(image); // e.g. through vkCmdDraw -- expects layout A 
4: imageBarrier(image, src=FRAGMENT_SHADER, dst=TRANSFER, newLayout=B); 
5: readT(image); // different kind of read e.g. Transfer -- expects layout B 

Зависимость в # 4 говорит, что переход расположение и последующие команды передачи не будет происходить до тех пор, все предыдущие операции FRAGMENT_SHADER не завершена.

сделать его чтения Read зависимость

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

Это «зависимость чтения-записи-чтения». Средняя часть должна ждать, пока первое чтение не будет выполнено, но второе чтение не может произойти до тех пор, пока средняя часть не будет завершена. Требуется зависимость от выполнения с привязкой к памяти изображения &.

+0

Хорошо, это была моя интуиция (это ответственность приложений - как всегда). Я просто задавался вопросом, нужно ли мне выполнять определенный порядок двух функций чтения. (У меня есть трюк с subpasses, но не встроенный, я думаю). – krOoze

+0

@krOoze: вы не можете иметь два независимых прохода, просматривая одно и то же изображение с разными макетами. Один * должен * быть зависимым от другого, так как реализации разрешено чередоваться с обходами, если он не зависит от другого. –

+0

Я имел в виду это (спецификация): «Если два subpasses используют одно и то же вложение в разных макетах, но оба использования доступны только для чтения [...], приложение не должно выражать зависимость между двумя subpasses. .] " – krOoze

 Смежные вопросы

  • Нет связанных вопросов^_^