Ритм кадров в играх: интервалы показа и задержка очередей

Назначение

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

Принцип работы

На дисплее с фиксированной частотой возможности показа возникают через дискретные интервалы. Режим Vulkan VK_PRESENT_MODE_FIFO_KHR ставит запросы презентации по порядку и обязателен для поддержки. VK_PRESENT_MODE_MAILBOX_KHR, если доступен, заменяет ожидающий запрос более новым до показа. Такая замена не удаляет работу, уже поставленную в другие очереди GPU.

Число изображений swapchain, одновременно обрабатываемые кадры приложения и очередь презентации описывают связанные, но разные ресурсы. Ограничение отправок с помощью объектов fence позволяет контролировать незавершённую работу. Платформенный регулятор может сочетать временные метки показа с ожиданиями синхронизации; библиотека Android явно решает проблемы раннего показа и переполнения очередей. Выбирайте политику по реальным возможностям поверхности и нагрузке.

Разобранный пример

Предположим фиксированную частоту дисплея 60 Гц и цель игры 30 кадров в секунду. Каждое обновление длится примерно 1000 / 60 ≈ 16.67 ms. Показ каждого игрового изображения в течение двух обновлений даёт интервал около 33.33 ms.

Если чередовать видимость на протяжении одного и трёх обновлений, интервалы будут близки к 16.67 ms и 50 ms. Средняя частота всё ещё может соответствовать цели, но ритм окажется заметно неравномерным. Это иллюстративное расписание, а не измерение или гарантия поведения конкретного экранного композитора.

Практический процесс

Регистрируйте время опроса ввода, отправки работы CPU, завершения GPU и фактической презентации, если платформа его предоставляет. Явно различайте домены часов: возврат из функции отправки не доказывает, что изображение уже показано. Исследуйте распределение интервалов и повторяемые изображения, а не только счётчик FPS.

Выберите поддерживаемый режим презентации, задайте достижимый ритм и ограничьте незавершённые кадры. Сравните задержку и пропуски сроков при изменении ограничения. Проверьте равномерную панораму камеры, намеренные всплески нагрузки и переходы между частотами дисплея. Сохраняйте достаточно параллельной работы для эффективной загрузки GPU, не накапливая устранимую задержку показа.

Ограничения и проверка

Регулятор ритма не завершит дорогой кадр раньше аппаратуры. Снижение цели может улучшить равномерность, но выбранный режим дисплея должен позволять нужный ритм. Дисплеи с переменной частотой дают другие временные возможности и ограничения; пример с фиксированной частотой нельзя переносить без изменений.

Mailbox-презентация может отбрасывать старые ожидающие изображения, но рендеринг лишних изображений всё равно расходует ресурсы. Проверьте длительное поведение, энергопотребление и задержку ввода на целевых устройствах. Сохраняйте режим, частоту экрана и настройки ритма вместе с каждой записью, чтобы плавный результат можно было воспроизвести.

Источники

• Android Frame Pacing library — Google, Android Developers
• VkPresentModeKHR — Khronos Group, Vulkan Documentation Project