#vulkan
Вопрос:
Если я проверю состояние ограждения с помощью функции vkGetFenceStatus (), это займет около 0,002 миллисекунды. Это может показаться не таким уж долгим временем, но такое количество времени в рендеринге или игровом движке-очень долгое время, особенно когда ожидание заборов во время выполнения других запланированных заданий скоро увеличится до времени, быстро приближающегося к миллисекунде. Если статусы ограждения сохраняются на стороне хоста, почему требуется так много времени, чтобы проверить их и сбросить? Получают ли другие люди аналогичное время при вызове этой функции?
Комментарии:
1. » особенно когда ожидание на заборах во время выполнения других запланированных заданий скоро приведет к тому, что время быстро приблизится к миллисекунде «. Зачем вам делать это чаще, чем пару раз за кадр?
2. @NicolBolas Ну, честно говоря, я не знаю, сколько раз я буду это делать, думаю, это зависит от того, сколько времени это займет. Сколько времени должны занимать эти работы?
Ответ №1:
В идеале время, необходимое для проверки установленного ограждения, не должно иметь значения. Хотя занимать 0,02% кадра со скоростью 120 кадров в секунду не идеально, в конце концов, это не должно быть так уж важно. Идеальный сценарий работает следующим образом:
В принципе, вы должны построить свою логику забора вокруг идеи о том, что вы собираетесь проверять забор только в том случае, если он почти наверняка уже установлен.
Если вы отправляете рамку 1, вам не следует проверять забор, когда вы начинаете строить рамку 2. Вы должны проверять это только тогда, когда начинаете создавать фрейм 3 (или 4, в зависимости от того, какую задержку вы готовы терпеть).
И самое главное, если он не установлен, это должно представлять случай, когда либо процессор выполняет недостаточно работы, либо графическому процессору было предоставлено слишком много работы. Если процессор опережает графический процессор, это нормально, что процессор ждет. То есть производительность процессора больше не имеет значения, так как вы привязаны к графическому процессору.
Так что время, необходимое для проверки забора, более или менее не имеет значения.
Если вы находитесь в сценарии, в котором вы выполняете диспетчеризацию задач, и вы хотите запустить графическую задачу как можно скорее, но у вас есть другие задачи, доступные, если графическая задача еще не готова, вот где это может стать проблемой. Но даже в этом случае это будет проблемой только в течение этого небольшого промежутка времени между первой проверкой готовности графической задачи и моментом, когда у вас закончатся другие задачи для запуска, и процессору необходимо начать ждать готовности графического процессора.
В этом сценарии я бы предложил проверять забор только дважды за кадр. Проверьте его при первой возможности; если он не установлен, выполните все остальные задачи, которые вы можете. После того, как эти задачи будут отправлены/выполнены… просто подождите с графическим vkWaitForFences процессором . Либо забор установлен, и функция немедленно вернется, либо вы ждете, пока графический процессор будет готов к получению дополнительных данных.
Существуют и другие сценарии, в которых это может стать проблемой. Если в графическом процессоре отсутствуют выделенные очереди передачи, возможно, вы тестируете один и тот же забор для разных целей. Но даже в этих случаях я бы предложил проверять забор только один раз за кадр. Если загрузка данных не завершена, вам либо придется выполнить жесткую синхронизацию, если эти данные необходимы прямо сейчас, либо вы отложите их использование до следующего кадра.
Если это по-прежнему вызывает озабоченность, и ваша реализация Vulkan допускает семафоры временной шкалы, рассмотрите возможность их использования для отслеживания хода выполнения очереди. vkGetSemaphoreCounterValue может быть быстрее , чем vkGetFenceStatus , так как это просто считывание числа.