Некоторые вопросы VkSubpassDependency по образцу закадрового рендеринга Саши Виллемса - PullRequest
0 голосов
/ 26 мая 2020

В образце закадрового рендеринга Саши Виллемса есть 2 VkSubpassDependency для основного renderPass и 2 для закадрового renderPass. Во-первых, я часто вижу пары VkSubpassDependency и не понимаю почему. 1008 * В главном renderPass вторая VkSubpassDependency (dependencies [1]) здесь только для представления в цепочке подкачки? Это обязательно?

Для offScreen renderPass, в общем, я не понимаю точки зависимостей [0]:

Поскольку нам нужно только записать в буфер кадра и сообщить основной renderPass, когда он завершен, мне кажется, что это то, что делают зависимости [1].

Что означает dependencies [0] .srcSubpass = VK_SUBPASS_EXTERNAL; потому что перед закадровым renderPass нет другого прохода. Это просто для того, чтобы внеэкранный рендеринг дождался завершения sh основного renderPass * презентации в цепочке подкачки?

Мой последний вопрос более конкретный c: если я использую эти 4 VkSubpassDependency, аналогичным образом Саша делает в этом примере, поэтому для выполнения неэкранного renderPass у меня возникла ошибка проверки: «График зависимостей должен быть указан таким образом, чтобы более ранний проход не мог зависеть от более позднего прохода». Я не могу найти ничего об этой ошибке на inte rnet. Я только что обнаружил, что эта ошибка возникает из-за: dependency.srcSubpass> dependency.dstSubpass. Есть идеи?

Вот ссылка на образец закадрового рендеринга Саши Виллемса: https://github.com/SaschaWillems/Vulkan/blob/master/examples/offscreen/offscreen.cpp

1 Ответ

2 голосов
/ 26 мая 2020

Этот вопрос похож на Порядок действий команд с использованием зависимостей подпрохода? - это та же кодовая база.

Примеры немного устарели, как я сказал в SaschaWillems / Vulkan # 665 . С тех пор спецификация была значительно уточнена. Так что иногда там возникают некоторые излишне запутанные аргументы.


main renderPass, dependencies [1]

Да, такая зависимость типична, когда ей следуют сигналом семафора. Например, с представлением в цепочке подкачки.

Теперь внешняя зависимость dst с dstStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT ничего не делает. Респ. это то же самое, что и неявная зависимость. Тем не менее, это эстетичный c выбор, который в любом случае должен быть явным.

VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT не имеет доступа, поэтому dstAccessMask должно быть просто 0.

VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT немного запутался в том, какой доступ был последним. Последний доступ к прикреплению цветов - это storeOp, что соответствует VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT для STORE или DONT_CARE.


offScreen renderPass, dependencies [0]

Сторона зависимости dst должна быть очевидна. Это просто доступ к буферу цвета. Он должен соответствовать loadOp, что в случае CLEAR цветового буфера равно VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT и VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.

Теперь src равно VK_ACCESS_SHADER_READ_BIT в VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT. Это изображение, доступ к которому осуществляется как текстура во фрагментном шейдере. Кажется, что есть только один закадровый буфер кадра. Итак, не слишком изучая образец, я бы предположил, что эта зависимость гарантирует, что "main renderPass" завершит чтение закадрового буфера, прежде чем он снова будет записан закадровым renderPass.


значение зависимостей [0] .srcSubpass = VK_SUBPASS_EXTERNAL; потому что до закадрового RenderPass нет другого прохода.

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


Я только что обнаружил, что эта ошибка возникает из-за: dependency.srcSubpass> dependency.dstSubpass. Есть идеи?

Верно. Кажется, вы разобрались?

srcSubpass и dstSubpass должны быть либо VK_SUBPASS_EXTERNAL, либо srcSubpass должны быть меньше dstSubpass, чтобы случайно не создать циклы и взаимоблокировки в зависимости ДАГ.

...