Comment mesurer le FPS dans les systèmes embarqués

Table des matières

Pourquoi mesurer le FPS dans les systèmes embarqués ?

La mesure du nombre de secondes par seconde dans les systèmes embarqués permet de quantifier la réactivité et la fluidité de l’interface utilisateur dans des conditions matérielles réelles. Elle fournit une mesure simple et comparable qui facilite la détection des problèmes de performance, l’évaluation des optimisations et la validation de la conformité du système à ses exigences.

Dans la pratique, le FPS est souvent utilisé comme un signal de retour rapide pendant le développement, mettant en évidence les problèmes liés à la charge du processeur, à la bande passante de la mémoire ou au débit de l’écran. Même s’il ne dit pas tout, il constitue un point de départ utile pour comprendre et améliorer les performances globales de l’interface utilisateur.

Comment mesurer le FPS dans les systèmes embarqués ?

Mesurer le nombre d’images par seconde (FPS) dans les systèmes embarqués n’est pas aussi simple que dans les environnements de bureau. Il n’y a généralement pas de profileur intégré, de compteurs GPU ou de pipeline de rendu standardisé. Au lieu de cela, le nombre d’images par seconde doit être dérivé de la manière et du moment où l’écran est réellement mis à jour.

En pratique, la mesure du SFP consiste à répondre à une question :

À quelle fréquence le système produit-il une image complète ?

La réponse dépend de la pile graphique, du modèle de rendu et de l’interface d’affichage.

Que signifie le terme "cadre" dans l'expression "embedded" ?

Avant de mesurer le nombre d’images par seconde, il est important de définir ce qu’est une « image ».

Dans les systèmes embarqués, un cadre peut signifier :

• mise à jour complète du framebuffer (fréquente dans le cas d’une double mise en mémoire tampon)
• mise à jour partielle (zones sales uniquement)
• affranchissement de l’affichage (transfert vers l’affichage)

Pour cette raison, le SPF peut être :

• Render FPS – fréquence d’affichage de l’interface utilisateur
• FPS d’affichage – fréquence d’envoi des pixels à l’écran

Ce ne sont pas toujours les mêmes.

Dans cet exemple, nous nous concentrerons sur le rendu FPS.

STM32 / Bare metal (approche générique)

Sur les systèmes MCU (par exemple STM32), le FPS est souvent mesuré à l’aide d’un minuteur ou d’un compteur de cycles.

Approche :

• incrémente le compteur d’images à la fin de la boucle de rendu
• mesurer le temps écoulé à l’aide du compteur de cycles SysTick ou DWT

Ensuite, dans une tâche périodique :

Ce qui est mesuré :

• Rendu FPS

Alternative (plus précise) :

Utilisez le registre DWT->CYCCNT pour mesurer le temps de trame exact en cycles CPU.

Une façon plus précise de mesurer le FPS sur le STM32 (et le Cortex-M en général) est d’utiliser le compteur de cycles DWT (DWT->CYCCNT), qui compte les cycles d’horloge du processeur au lieu de s’appuyer sur les tics système en millisecondes.

Fonctionnement :
Au début d’une trame, vous enregistrez la valeur actuelle de CYCCNT. À la fin de la trame, vous la relisez et calculez la différence. Vous obtenez ainsi le nombre exact de cycles de l’unité centrale consacrés au rendu d’une seule image. En connaissant la fréquence du processeur, vous pouvez calculer le nombre d’images par seconde (FPS) :

FPS = Fréquence CPU / cycles_par_image

Avantages :

• Très haute précision (précision au niveau du cycle)
• Idéal pour l’analyse et l’optimisation des performances
• Non affecté par les interruptions SysTick ou la gigue d’ordonnancement

Inconvénients :

• Nécessite une fréquence d’horloge connue et stable de l’unité centrale
• Non disponible sur tous les cœurs Cortex-M (par exemple M0/M0+)
• Légèrement plus complexe à mettre en place et à utiliser
• Le débordement du compteur doit être pris en compte dans les mesures plus longues

Moniteur de performance LVGL (LV_USE_PERF_MONITOR)

LVGL fournit un moyen intégré de surveiller la performance en activant l’option LV_USE_PERF_MONITOR dans la configuration (lv_conf.h). Lorsque cette option est activée, LVGL affiche une petite fenêtre à l’écran avec des mesures en temps réel.

Il s’agit généralement des éléments suivants

• FPS (images par seconde)
• Utilisation de l’unité centrale (temps consacré aux tâches LVGL)
• parfois des statistiques liées à la mémoire (en fonction de la configuration)

Le moniteur fonctionne en interne en suivant la fréquence d’exécution de la boucle de rendu et le temps passé à traiter les tâches et à dessiner.

Ce qui est mesuré :

• un mélange de FPS de rendu et de charge du système
• plus proche de la « performance de l’interface utilisateur » que de la vitesse d’affichage brute

Pourquoi c’est utile :

• installation sans effort (il suffit de l’activer dans la configuration)
• un retour d’information visuel immédiat pendant le développement
• idéal pour une validation rapide des performances et des contrôles de régression

Limites :

• ne mesure pas le temps de transfert réel de l’affichage (de l’affleurement à l’écran)
• Le FPS peut ne pas refléter les mises à jour en plein écran lorsque le redessin partiel est utilisé.
• ajoute un léger surcoût (devrait être désactivé en production)

En pratique, LV_USE_PERF_MONITOR est le moyen le plus rapide d’obtenir une compréhension approximative des performances du système, mais pour des mesures précises – en particulier lors de l’optimisation de la bande passante ou des pilotes d’affichage – il doit être combiné avec un chronométrage de niveau inférieur (par exemple, en mesurant les callbacks de rinçage).

LVGL fournit un moyen intégré de surveiller la performance en activant l’option LV_USE_PERF_MONITOR dans la configuration (lv_conf.h). Lorsque cette option est activée, LVGL affiche une petite fenêtre à l’écran avec des mesures en temps réel.

Il s’agit généralement des éléments suivants

• FPS (images par seconde)
• Utilisation de l’unité centrale (temps consacré aux tâches LVGL)
• parfois des statistiques liées à la mémoire (en fonction de la configuration)

Le moniteur fonctionne en interne en suivant la fréquence d’exécution de la boucle de rendu et le temps passé à traiter les tâches et à dessiner.

Ce qui est mesuré :

• un mélange de FPS de rendu et de charge du système
• plus proche de la « performance de l’interface utilisateur » que de la vitesse d’affichage brute

Pourquoi c’est utile :

• installation sans effort (il suffit de l’activer dans la configuration)
• un retour d’information visuel immédiat pendant le développement
• idéal pour une validation rapide des performances et des contrôles de régression

Limites :

• ne mesure pas le temps de transfert réel de l’affichage (de l’affleurement à l’écran)
• Le FPS peut ne pas refléter les mises à jour en plein écran lorsque le redessin partiel est utilisé.
• ajoute un léger surcoût (devrait être désactivé en production)

En pratique, LV_USE_PERF_MONITOR est le moyen le plus rapide d’obtenir une compréhension approximative des performances du système, mais pour des mesures précises – en particulier lors de l’optimisation de la bande passante ou des pilotes d’affichage – il doit être combiné avec un chronométrage de niveau inférieur (par exemple, en mesurant les callbacks de rinçage).

MPU/Linux

Sur les systèmes Linux, la mesure du FPS dépend de la pile graphique.

Simple framebuffer (fbdev)

Mesure le temps entre les échanges de tampons :

Wayland / Cadres d’interface graphique

Les options comprennent

• des outils intégrés (par exemple, le compteur Weston FPS)
• synchronisation au niveau de l’application
• Outils de profilage du GPU (le cas échéant)

Conclusions

Pour mesurer le nombre de secondes par seconde dans les systèmes embarqués, il faut comprendre ce qu’une « image » représente réellement dans un pipeline donné. Que vous mesuriez les boucles de rendu, les rappels de vidage ou les échanges de tampons, chaque méthode reflète un aspect différent de la performance. Les frameworks tels que LVGL ou les piles basées sur Linux fournissent des crochets utiles, mais c’est au développeur de choisir le bon point de mesure.

Dans la pratique, le nombre d’images par seconde ne suffit pas. La régularité de la fréquence des images, la latence et la largeur de bande de la mémoire ont souvent un impact plus important sur la performance perçue. Un taux de rafraîchissement stable et prévisible est généralement plus important que le taux de rafraîchissement le plus élevé possible.