Frame pacing dans les jeux : maîtriser la cadence de présentation et la latence des files

Finalité

Un jeu peut afficher une fréquence d'images moyenne satisfaisante tout en présentant un mouvement saccadé. Le rendu visible dépend du moment où les images terminées atteignent l'écran et de la durée pendant laquelle chacune reste affichée. Le frame pacing coordonne cette livraison avec l'écran, au lieu de traiter chaque rendu terminé comme un ordre de présentation immédiate. Il limite aussi le travail inutilement mis en file d'attente, qui oblige une modification d'entrée à attendre derrière des images plus anciennes.

Fonctionnement

Sur un écran à fréquence de rafraîchissement fixe, les occasions de présentation reviennent à intervalles discrets. Le mode VK_PRESENT_MODE_FIFO_KHR de Vulkan place les requêtes de présentation en file dans l'ordre ; c'est le mode dont la prise en charge est obligatoire. VK_PRESENT_MODE_MAILBOX_KHR, lorsqu'il est disponible, remplace une requête en attente par une requête plus récente avant la présentation. Cette politique de remplacement ne supprime pas le travail déjà mis en file ailleurs sur le GPU.

Le nombre d'images de la swapchain, les images d'application en vol (frames in flight) et la file de présentation désignent des ressources voisines mais distinctes. Une limite de soumission fondée sur des fences permet de contrôler le travail en cours. Un pacer de plateforme peut combiner des horodatages de planification et des attentes de synchronisation ; la bibliothèque d'Android traite explicitement la présentation trop précoce et le queue stuffing (engorgement de la file). Choisissez la politique en fonction des capacités réelles de la surface et de la charge de travail.

Exemple détaillé

Supposons une fréquence d'affichage fixe de 60 Hz et une cible du jeu de 30 images par seconde. Chaque rafraîchissement dure environ 1000 / 60 ≈ 16.67 ms. Afficher chaque image du jeu pendant deux rafraîchissements donne une cadence d'environ 33.33 ms.

Si l'on alterne en revanche une image visible pendant un rafraîchissement, puis la suivante pendant trois, les intervalles sont proches de 16.67 ms et de 50 ms. La fréquence moyenne peut toujours correspondre à la cible, alors que la cadence est visiblement irrégulière. Il s'agit d'un calendrier illustratif, non d'une mesure ni d'une garantie concernant un compositeur d'affichage particulier.

Démarche pratique

Capturez l'échantillonnage des entrées, la soumission côté CPU, l'achèvement côté GPU et les horodatages de présentation effective, là où la plateforme les expose. Gardez les domaines d'horloge explicites : le retour d'un appel de soumission ne prouve pas que l'image a déjà été affichée. Examinez la distribution des intervalles et les images répétées, plutôt que de vous fier uniquement à un compteur de FPS.

Choisissez un mode de présentation pris en charge, fixez une cadence réalisable et bornez le nombre d'images en cours. Comparez la latence et les échéances manquées en faisant varier cette borne. Testez un panoramique de caméra régulier, des pics de charge délibérés et les transitions entre modes de rafraîchissement de l'écran. Conservez suffisamment de travail en parallèle pour exploiter efficacement le GPU, sans accumuler de délai de présentation évitable.

Limites et vérification

Une bibliothèque de pacing ne peut pas terminer une image coûteuse avant que le matériel ne l'ait achevée. Abaisser la cible peut améliorer la régularité, mais le mode d'affichage choisi doit prendre en charge la cadence visée. Les écrans à rafraîchissement variable offrent d'autres possibilités et d'autres limites de timing ; l'exemple à fréquence fixe ne doit pas leur être appliqué tel quel.

La présentation en mode mailbox peut écarter des images en attente plus anciennes, mais le rendu d'images inutiles consomme tout de même des ressources. Vérifiez le comportement soutenu, la consommation d'énergie et la latence d'entrée sur les appareils cibles. Consignez le mode sélectionné, la fréquence de rafraîchissement et les paramètres de pacing avec chaque capture, afin de pouvoir reproduire un résultat fluide.

Sources

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