#windows #sdl #direct3d11
#Windows #sdl #direct3d11
Вопрос:
Я использую SDL 2.0.13 в Windows 10, и я синхронизировал вызовы с SDL_RenderPresent . После длительного теста я вижу, что ровно 1 из 62 кадров занимает 16 мс вместо ожидаемых 1-2 мс. При загрузке библиотеки SDL с помощью debug я проследил это до вызова BitBlt() , так что это Windows / OS / Driver /… проблема не в SDL. Очевидно, что здесь должно быть что-то, связанное с vsync. Проблему можно увидеть с помощью Direct3D 11 или программных средств визуализации. И, похоже, на нее не влияет SDL_RENDERER_PRESENTVSYNC .
Первоначально спрашивалось здесь https://discourse.libsdl.org/t/sdl-renderpresent-bitblt-16ms-pause/28070 но поскольку это не проблема SDL, я разместил вопрос шире.
Что происходит? Могу ли я остановить это или избежать этого?
Комментарии:
1. Что вы имеете в виду, на это не влияет vsync — разве у вас не должно быть (в идеале) каждого кадра с частотой 16,6 мс при включенной vsync (на мониторе с частотой 60 Гц)? Пробовали ли вы другую рабочую нагрузку (т. Е. Отдельно тестировали с одним clear amp; present, с несколькими розыгрышами amp; present и с большим количеством розыгрышей amp; present) — у вас все еще тот же результат? Какой у вас графический процессор и драйвер?
2. Привет, есть опция SDL SDL_RENDER_PRESENTVSYNC, которая предназначена для управления vsync, но ее установка (или нет) не влияет на мою статистику. Основное приложение выполняет множество обновлений растрового изображения, но фактический renderpresent — это всего лишь один последний прямоугольник в окне [рабочий стол]. 98,4% времени BitBlt занимает 1-2 мс, а 1,6% времени — 16 мс. Никогда никаких промежуточных значений
3. Может ли быть так, что настройки вашего графического драйвера переопределяют vsync? Все это зависит от конкретной реализации, но я мог легко представить ситуацию, когда драйвер иногда блокируется до следующей vsync, даже если vsync обычно отключен. Если ваши требования не очень специфичны — я бы сказал, что, как правило, лучшим решением является фактическое включение vsync, поэтому каждый кадр будет составлять 16,6 мс.
4. Эффект кажется независимым от графического процессора — наблюдается на NVidia [Quadro] и интегрированном Intel HD. Я вижу, что драйвер может блокироваться до vsync, что не имеет смысла, так это задержка ЛИБО «0 мс», либо «16 мс» — никогда никаких промежуточных значений. В идеале я не хочу задержки в моем основном приложении, поскольку требуется выполнить другую обработку. Я просто хочу передать настоящее / blt, чтобы это произошло «как только …»
5. Я думаю, что глубоко внутри SDL есть ошибка. Под капотом частота обновления монитора не является целыми числами, это рациональные числа. 60 Гц монитора, на который я смотрю прямо сейчас, выдает 59997/1000 = 59,997 Гц. При использовании достаточно низкоуровневых API, таких как DXGI (Windows) или DRM /KMS (Linux), вы можете получить точное рациональное значение. Уверен, что где-то глубоко внутри SDL они округляют эти рациональные числа до целых чисел.