Выходные данные шейдера фрагментов не всегда отображаются правильно (много деталей ниже) (найдено решение)

#c #synchronization #shader #driver #vulkan

#c #синхронизация #шейдер #драйвер #vulkan

Вопрос:

Итак, вот в чем дело: я работаю над игровым движком в учебных целях, и это своего рода хобби. Движок использует OpenGL и Vulkan. В настоящее время я работаю над средством визуализации PBR в Vulkan. Он работал долгое время, пока я не переработал его.

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

Поэтому я подумал, что это может быть проблемой с униформой. Я загрузил RenderDoc, и оказывается, что при захвате кадра я не только правильно получаю все данные, но и результат корректен для изображения swapchain, поэтому проблема в том, что либо: данные теряются во время представления, либо я представляю неполное изображение, а RenderDoc просто долго ждалдостаточно с захватом, чтобы он был правильным.

Поэтому я предполагаю, что у вас проблема с синхронизацией. Способ работы этой системы выглядит следующим образом (почти полностью скопирован с vulkan-tutorial.com , за исключением того, что он учитывается в классах):

  • Я жду ограждения текущего фрейма
  • Я получаю следующее изображение, предоставляя семафор для этого фрейма
  • При необходимости я воссоздаю цепочку обмена
  • Я записываю командный буфер этого фрейма (повторная запись необходима, поскольку контекст меняется динамически)
  • Я сбрасываю забор этого фрейма
  • Я отправляю работу, используя семафор ожидания и сигнала
  • Я представляю результаты, используя семафор сигнала из предыдущего в качестве семафора ожидания
  • Я увеличиваю текущий кадр

Для каждого изображения swapchain есть один семафор и ограждение.

Поскольку это может быть проблемой с драйвером или ОС, вот мои спецификации: Я работаю на Windows 10 Pro, 64-разрядная версия (сборка 19041), графический процессор — GTX 1060 3 ГБ, а версия моего драйвера — 456.71. Программа разработана в Visual Studio 2019 Preview. Я могу связать репозиторий GitHub или захват RenderDoc.

Итак, краткое резюме: я получаю каждую форму правильно, но некоторые из них отображаются черным цветом (на самом деле 0,0,0, потому что добавление 0,5 к нему приводит к серому цвету), и некоторые из них отображаются правильно, но, согласно RenderDoc, данные верны, а цепочка обменаизображение после захвата правильное, поэтому проблема возникает во время презентации.

У кого-нибудь есть идеи, что может вызвать проблему? Действительно ли это синхронизация? Может ли это быть что-то еще? Я не думаю, что смогу привести минимально воспроизводимый пример, потому что исходный код довольно большой и сложный, но если вам что-нибудь нужно, спросите, и я добавлю детали.

Редактировать: это не было проблемой синхронизации. Код для обновления унифицированных буферов перезаписал весь буфер, и я понятия не имею, как RenderDoc показывал правильные данные, а некоторые дескрипторы все еще работали. Поэтому, если у вас есть подобная проблема, дважды проверьте vkMapMemory() , memcpy() и VkUnmapMemory() части вашего кода.

Комментарии:

1. какой загрузчик вы используете? glew или что? и для переноса буферов на карту, какую функцию вы использовали?

2. GLEW для управления окнами. Я использую VulkanSDK для доступа к уровням проверки и прочим. Униформа в основном использует когерентную и видимую память хоста и изменяется с использованием сопоставления памяти. (vkMapMemory, memset, vkUnmapMemory)

3. я не использовал материал vulkan, поэтому idk

4. У вас есть система контроля версий? Вы могли бы попробовать выполнить git bisect, чтобы найти прерывающий коммит. Сделайте git diff с предыдущей версией, чтобы точно определить изменение, которое нарушило ваш код.

5. Я использую GitHub. Однако это не так просто. Было огромное обновление, в котором сильно изменился интерфейс Vulkan, были изменены шейдеры, я исключил геометрический шейдер из конвейера PBR, и я на самом деле не пытался исправить эту проблему, так что это было бы проблематично.