отрисовки такая:
1) Жду фенс текущего кадра
2) Получаю изображение через vkAcquireNextImageKHR
3) Жду фенса полученного изображения
4) Сбрасываю фенс кадра через vkResetFences
5) Делаю vkQueueSubmit с только что сброшенным фенсом
6) Делаю vkQueuePresentKHR
В определённый момент, судя по nsight'у, получаю длительность выполнения vkQueuePresentKHR в 11 секунд. Это не первый и не последний кадр, на самом кадре 1 треугольник. Далее, если по прошествии этих 11 секунд попытаться закрыть приложение, ловлю лок намертво в vkDeviceWaitIdle. Мне кажется, что причина в том, что пока vkQueuePresentKHR висит 11 секунд, CPU успевает насовать ему вагон новых сабмитов, потому как фенс сбрасывается до сабмита, а не после презента.
Если добавить после vkQueuePresentKHR vkQueueWaitIdle, то проблема лока уходит, но проблема 11 секунд на презент — нет.
В общем вопроса два: как лечить спайк презента и правильно это синхронизировать, чтобы даже в случае спайка не получить лок? По поводу синхронизации мысль ждать семафора от vkQueuePresentKHR самым первым пунктом, но не уверен, что это правильно.
проверь тот ли фенс ждёшь, включи валидацию
Проверил, тот. В целом фенсы работают как надо, виснет только на vkDeviceWaitIdle, который я зову перед уничтожением всего.
Ты используешь validation layers? Если нет, то первым делом их включи. Иначе смысла 0 задавать вопросы здесь.
если почитать подальше, то можно обнаружить, что чел действительно написал, что использует
да. Читаю. Непонятно, действительно ли они работают. Если они совсем молчат, то это вероятно.
Обсуждают сегодня