Нужна ли синхронизация между несколькими вызовами отрисовки с прозрачностью в Vulkan? - PullRequest
Новая
       62

Нужна ли синхронизация между несколькими вызовами отрисовки с прозрачностью в Vulkan?

2 голосов
/ 05 ноября 2019

Я нахожусь в процессе изучения Vulkan, и я только что интегрировал ImGui в свой код, используя пример Vulkan-GLFW в оригинальном репозитории ImGui, и он отлично работает.

Теперь я хочу сделатьи графический интерфейс, и моя 3D-модель на экране одновременно, а поскольку для графического интерфейса и модели определенно требуются разные шейдеры, мне нужно использовать несколько конвейеров и отправлять несколько команд. Графический интерфейс частично прозрачен, поэтому я хотел бы, чтобы он отображался после модели. В спецификации Vulkan говорится, что порядок выполнения команд, скорее всего, не будет тем, что я записываю команды, поэтому мне нужна какая-то синхронизация. В этом посте Reddit было предложено несколько методов точного достижения моих целей, и я однажды поверил, что для решения этой проблемы я должен использовать несколько подпроходов (вместе с зависимостью от подпрохода) или барьеры или другие подобные методы синхронизации.

Затем я взглянул на примеры Vulkan SaschaWillems , хотя в примере ImGui я не вижу синхронизации между двумя вызовами отрисовки, он просто записывает команду для рисования модели в первую очередь, изатем команда для рисования GUI.

Я в замешательстве. Действительно ли необходима синхронизация в этом случае, или я неправильно понял что-то о переупорядочении или смешивании команд? Спасибо.

1 Ответ

4 голосов
/ 05 ноября 2019

Подумайте, что вы делаете на секунду. Как вы думаете, почему необходима синхронизация между двумя наборами команд? Потому что второй набор команд должен сочетаться с данными в первом наборе, верно? И, следовательно, он должен выполнить чтение / изменение / запись (RMW), которые должны быть в состоянии прочитать данные, записанные предыдущим набором команд. Считываемые данные должны быть записаны, и для этого обычно требуется синхронизация.

Но подумайте немного больше о том, что это значит. Смешивание должно читать из кадрового буфера, чтобы сделать свою работу. Но ... так же тест глубины, верно? Он должен прочитать значение глубины существующего образца, сравнить его с входящим фрагментом, а затем отбросить фрагмент или нет на основе теста глубины. Таким образом, в основном каждый вызов отрисовки , который использует тест глубины, содержит чтение / изменение / запись кадрового буфера.

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

Так или иначе, RMW теста глубины работает без какой-либо явной синхронизации. Итак ... почему вы думаете, что это не соответствует RMW этапа смешивания?

Спецификация Vulkan гласит, что команды и этапы внутри команд будут выполняться в основном неупорядоченным образом, с несколькими исключениями. Наиболее очевидным является наличие явных барьеров / зависимостей выполнения. Но это также говорит о том, что этапы тестирования и смешивания с фиксированной функцией для каждого образца всегда будут выполняться (как если бы) в порядке представления (в подпроходе). Мало того, это требует, чтобы треугольники, сгенерированные внутри команды, также выполняли эти этапы (как будто) в определенном, четко определенном порядке.

Вот почему ваш тест глубины ненужна синхронизация;Вулкан требует, чтобы это было обработано. Вот почему вашему смешиванию не потребуется синхронизация (в подпроходе).

Таким образом, у вас есть много вариантов (от самого быстрого до самого медленного):

  • Визуализируйте ваш пользовательский интерфейс в том же подпроходе, что и не-пользовательский интерфейс. Просто измените конвейеры соответствующим образом.
  • Визуализируйте ваш пользовательский интерфейс в подпроцессе с явной зависимостью от образов кадрового буфера не-пользовательского интерфейса. Хотя это технически медленнее, но, вероятно, не будет намного медленнее, если вообще будет. Кроме того, это полезно для отложенного рендеринга, поскольку ваш пользовательский интерфейс должен произойти после вашего прохода освещения, который, несомненно, будет его собственным подпроходом.
  • Визуализация вашего пользовательского интерфейса выполняется на другом проходе рендеринга. Это действительно понадобится только в тех случаях, когда вам нужно выполнить какую-то полноэкранную работу (SSAO), которая заставит ваш проход рендеринга без интерфейса пользователя в любом случае прерваться.
...