Analyse approfondie du système Adaptive Performance dans le développement de jeux mobiles sur le moteur Unity

Dans l'écosystème moderne du développement de jeux mobiles, l'augmentation géométrique des capacités matérielles a ouvert la voie à l'exécution sur des appareils portables de jeux repoussant les limites graphiques. Cependant, contrairement aux systèmes de bureau ou de console, les plates-formes mobiles sont dépourvues de mécanismes de refroidissement actif (ventilateurs ou systèmes de refroidissement liquide). Dans une architecture System-on-Chip (SoC), l'unité centrale de traitement (CPU), l'unité de traitement graphique (GPU), les contrôleurs de mémoire et les modules réseau se trouvent regroupés dans un espace millimétrique.¹ L'exécution continue de ces composants à des vitesses d'horloge élevées (clock speed) entraîne inévitablement la production d'une quantité massive de chaleur résiduelle.

Lorsque la température de l'appareil atteint des seuils critiques, le système d'exploitation active un mécanisme de défense appelé « Thermal Throttling » (étranglement thermique) afin de protéger le matériel contre les dommages physiques et d'empêcher la dégradation de la structure chimique de la batterie.² Ce mécanisme réduit soudainement et agressivement les fréquences d'horloge du CPU et du GPU. Pour les développeurs de jeux, cela se traduit par une chute brutale du nombre d'images par seconde (FPS), une augmentation de la latence d'entrée (input lag) et une altération globale de l'expérience du joueur.³ C'est précisément à ce stade qu'intervient le système Unity Adaptive Performance, qui vise à jeter un pont entre le logiciel et le matériel pour permettre au moteur de jeu de s'adapter de manière proactive à la dynamique thermique de l'appareil. Ce rapport examine, avec une profondeur académique et professionnelle, l'architecture fondamentale du paquet Adaptive Performance, ses algorithmes de mise à l'échelle, ses stratégies d'intégration et ses avantages en matière d'optimisation, en commençant par l'anatomie des avertissements de configuration fréquemment rencontrés lors du processus de développement.

Causes profondes de l'avertissement « Adaptive Performance Settings » et solutions de configuration

Lorsqu'un nouveau projet mobile est lancé dans le moteur de jeu Unity ou qu'un projet existant est configuré pour être compilé sur des plates-formes mobiles (Android, iOS), l'avertissement suivant ou un message dérivé apparaît fréquemment dans la console : « No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings ».⁴ La cause fondamentale de cet avertissement, qui interrompt les flux de travail des développeurs, réside dans le principe de fonctionnement du système de gestion de paquets modulaires et de la couche d'abstraction matérielle (Hardware Abstraction Layer) d'Unity.

Unity inclut le paquet de base Adaptive Performance de manière préinstallée (pre-installed) lors de la création d'un projet avec des modèles tels que « Mobile 2D », « Mobile 3D » ou « Universal Render Pipeline (URP) ».⁵ Cependant, le paquet de base ne possède pas en soi de bibliothèques natives capables de lire les données du matériel de l'appareil ou d'interagir avec le système d'exploitation. Pour que le paquet devienne fonctionnel, un module « Provider » (Fournisseur) spécifique au système d'exploitation ciblé (Android, etc.) ou à l'environnement de test doit être ajouté au projet et configuré.⁶ En l'absence de module fournisseur, le paquet de base ne peut pas accéder aux capteurs matériels lors de l'exécution (runtime) et émet cet avertissement pour en informer le développeur. La résolution de l'avertissement et les étapes de configuration présentent des différences méthodologiques importantes selon la plate-forme cible du développement et la version d'Unity utilisée.

La résolution de cet avertissement rencontré au cours du processus de développement doit être traitée en fonction de la plate-forme. Les permissions d'accès aux API matérielles des systèmes d'exploitation étant différentes, les solutions proposées par Unity varient également.

Plate-forme cibleCause technique de l'avertissementMéthodologie de solution à appliquerAndroidAbsence dans le projet du plugin natif devant communiquer avec l'ADPF ou le Samsung GameSDK.Le paquet Adaptive Performance Android Provider ou, en cas de cible spécifique, le paquet Samsung (Android) Provider doit être installé via le gestionnaire de paquets Unity Package Manager.⁶ Ensuite, le fournisseur correspondant doit être activé depuis le menu Edit > Project Settings > Adaptive Performance.⁶iOS (Apple)Inexistence d'un fournisseur (provider) de matériel officiel pris en charge par Unity pour Adaptive Performance dans l'écosystème iOS.⁴Lorsque l'ensemble de fonctionnalités Mobile est ajouté au projet, Adaptive Performance est inclus en tant que dépendance (dependency) et ne peut pas être supprimé. Pour les compilations iOS, cet avertissement est inoffensif et peut être ignoré (ignore), ou le module Mobile peut être supprimé du gestionnaire de paquets pour rompre la dépendance.⁴Éditeur de bureau (PC/Mac)Absence de capteurs thermiques spécifiques aux appareils mobiles et d'architectures SoC sur les systèmes d'exploitation Windows ou macOS.Pour simuler les conditions mobiles sur l'ordinateur de développement, le fournisseur Simulator (Desktop) Provider doit être installé et un environnement thermique virtuel doit être créé à l'aide de la fenêtre Device Simulator.²Unity 6 (Build Profiles)Oubli d'une configuration spécifique au profil en plus des paramètres Adaptive Performance du projet principal dans les profils de compilation (Build Profiles) introduits avec Unity 6.Dans le menu File > Build Profiles, le bouton Add Settings > Adaptive Performance Settings doit être cliqué pour la plate-forme sélectionnée afin d'attribuer le fournisseur. L'omission de ces paramètres dans les versions d'Unity 6.000.x entraîne l'erreur « No default loader found ».⁹

Cet avertissement n'est fondamentalement pas une erreur de compilation (compile), mais une notification de manque d'optimisation. Le développeur peut ignorer cet avertissement et faire fonctionner le jeu sur l'appareil ; cependant, dans ce cas, le jeu fonctionnera en étant totalement aveugle (blind) quant à l'état thermique du matériel et subira inévitablement les interventions impitoyables d'étranglement thermique du système d'exploitation.

Architecture du système Adaptive Performance et écosystème des fournisseurs (Providers)

Adaptive Performance établit un pont de communication bidirectionnel entre les mécanismes de prise de décision du moteur de jeu et le matériel physique. La couche de collecte de données de cette architecture est constituée par les fournisseurs (providers). La structure extrêmement fragmentée (fragmented) de l'écosystème Android rendant impossible le fonctionnement d'une seule API matérielle sur tous les appareils, Unity résout ce problème à l'aide de fournisseurs spécifiques intégrés à différents cadres matériels (frameworks).

Intégration d'Android Dynamic Performance Framework (ADPF)

Le module de base « Android Provider » d'Unity est construit sur l'architecture Android Dynamic Performance Framework (ADPF), introduite par Google avec le système d'exploitation Android 12 et les versions ultérieures.² L'ADPF est un ensemble d'API révolutionnaire qui permet d'établir un dialogue direct entre les jeux et la gestion thermique du système d'exploitation. Dans les approches traditionnelles, le système d'exploitation essaie de deviner quelle image (frame) du jeu nécessite quelle puissance de processeur, et ces estimations se traduisent souvent par l'attribution de vitesses d'horloge CPU incorrectes.

Le fournisseur Android d'Unity Adaptive Performance, quant à lui, fournit un flux continu de données au système d'exploitation par le biais de la « Performance Hint API » (Interface d'indication de performance).⁶ À chaque rendu d'une image, le moteur signale au système ADPF la durée cible de cette image (par exemple 16,6 millisecondes si 60 FPS sont visés) et la durée réelle (actual duration) que le CPU et le GPU ont passée pour l'achever.⁶ Grâce à cette boucle de rétroaction précise, le système d'exploitation Android n'augmente la fréquence des cœurs de CPU que dans la mesure des besoins du jeu. Lorsque l'appareil commence à chauffer, le système d'exploitation renvoie les alertes thermiques à Unity, de sorte que les metteurs à l'échelle graphiques intra-moteur s'activent avant qu'un ralentissement au niveau du matériel ne se produise.⁶ Les versions 1.2 et ultérieures du fournisseur Android, qui constituent sa version stable (dépassant la limitation des appareils Pixel), sont prises en charge à partir d'Adaptive Performance 5.0 et d'Unity 2021.3.⁶

Samsung GameSDK et optimisations matérielles spécifiques

En raison de sa part de marché parmi les plus importantes de l'écosystème Android, Samsung propose une interface matérielle personnalisée appelée GameSDK afin de pouvoir repousser les limites de son propre matériel. Le fournisseur Adaptive Performance Samsung (Android) d'Unity permet d'aller au-delà des fonctionnalités ADPF standard pour obtenir des métriques plongeant directement au cœur des SoC Samsung.²

Le fournisseur Samsung couvre une vaste gamme d'appareils fonctionnant sous Android 10 et les versions ultérieures, et prenant en charge GameSDK 3.2 et les versions plus récentes. Cette zone de couverture s'étend des appareils d'entrée de gamme aux produits phares, offrant aux développeurs un très large champ d'optimisation.

Séries Samsung Galaxy prises en chargeModèles (GameSDK 3.2+ / Android 10+)Série Galaxy SS9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Série Galaxy NoteNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Série Galaxy Z (Pliables)Z Fold2¹³Série Galaxy AA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Série Galaxy XcoverXcover 4s, Xcover Pro¹³

L'un des avantages matériels les plus importants offerts par ces appareils est la technologie de « Fréquence de rafraîchissement variable » (Variable Refresh Rate - VRR).¹³ La prise en charge du VRR est actuellement utilisée activement sur les appareils Galaxy S20, S21, S22 et Note 20.¹³ Lorsqu'Adaptive Performance détecte que l'appareil atteint ses limites et décide de réduire la valeur FPS du jeu de 60 à 45 par exemple, il envoie une commande à l'API VRR de Samsung pour abaisser également la vitesse de rafraîchissement physique de l'écran à 45 Hz.¹⁶ Cette synchronisation empêche les déchirures d'écran (screen tearing), évite une consommation d'énergie excessive du panneau d'affichage et contribue de manière significative à un refroidissement plus rapide de l'appareil. De plus, le fournisseur Samsung offre également la possibilité d'accéder aux données « Cluster Info », qui indiquent la répartition de la charge des grands et petits cœurs de l'architecture big.LITTLE du processeur sur les appareils équipés de GameSDK 3.5 (Android 12) et versions ultérieures.¹³

Métriques thermiques et algorithmes de détection des goulots d'étranglement (Bottleneck)

L'ingénierie qui sous-tend la capacité d'Adaptive Performance à offrir une optimisation proactive repose sur des systèmes d'analyse de capteurs qui collectent des données en continu. L'interface IAdaptivePerformance générée lors de l'exécution du jeu lit un ensemble de données provenant du matériel selon deux catégories principales : la rétroaction sur l'état thermique (Thermal State Feedback) et la synchronisation des images (Frame Timing). Sur la base de ces données, il est décidé quel est l'élément principal (goulot d'étranglement) qui limite la performance du système à ce moment précis.

Rétroaction thermique et niveaux d'avertissement

L'état thermique de l'appareil n'est pas évalué uniquement à partir d'une simple lecture en degrés Celsius. La dynamique thermique est surveillée à l'aide de trois métriques différentes, normalisées et traitées de manière analytique ² :

La première métrique, TemperatureLevel (Niveau de température), est une valeur à virgule flottante (float) normalisée entre 0,0 et 1,0 (0,0 représentant la température ambiante/de fonctionnement standard, et 1,0 le seuil thermique maximal absolu).² Les développeurs peuvent utiliser cette valeur pour présenter l'état de chauffage de l'appareil au joueur sous forme de barre graphique dans l'interface du jeu ou pour concevoir leur propre logique d'optimisation personnalisée.

La deuxième métripue, plus prédictive, TemperatureTrend (Tendance de la température), varie entre -1,0 et 1,0

et représente la dérivée mathématique de la température, c'est-à-dire sa vitesse de variation. 2 Une valeur de 1,0 indique que l'appareil chauffe extrêmement rapidement, tandis qu'une valeur de 0 indique que la température reste stable et -1,0 montre qu'une période de refroidissement agressive est amorcée. La détection de ces tendances par le système et l'obtention d'une moyenne valide nécessitent généralement un processus d'analyse d'environ dix secondes. 2 La troisième métrique, et la plus critique, est une classification catégorielle appelée WarningLevel (Niveau d'avertissement), qui détermine la réaction du système d'exploitation face à l'état thermique. 2

Niveau d'avertissement (WarningLevel)État du système d'exploitationRéaction d'Adaptive Performance dans le moteur de jeuNoWarning (0) L'appareil est à des températures optimales. Aucun ralentissement thermique n'est à déplorer. Le rendu du jeu est autorisé à la résolution, à la fréquence d'images et à la qualité visuelle les plus élevées ciblées. 2 ThrottlingImminent (1) La capacité thermique est sur le point d'être atteinte. Le système d'exploitation n'a pas encore réduit les fréquences matérielles, mais le danger est très proche. Une intervention proactive commence. Des metteurs à l'échelle à faible impact visuel sont activés (par exemple, la réduction de la distance des ombres) pour tenter d'empêcher l'appareil de passer à la phase suivante. 2 Throttling (2) Le matériel a atteint une température critique et le système d'exploitation a réduit de manière agressive les fréquences d'horloge du CPU/GPU pour se protéger. La facture d'optimisation la plus agressive est payée. La fréquence d'images cible (Target FPS) est spectaculairement abaissée, la résolution de rendu principale est restreinte et des concessions radicales sont faites pour permettre à l'appareil de retrouver une température normale. 2

Timing des trames et détection des goulots d'étranglement (Bottleneck)

Le fait qu'un jeu ne parvienne pas à atteindre 60 images par seconde peut provenir de plusieurs insuffisances matérielles. Déterminer si le problème provient d'une insuffisance du processeur graphique (GPU) ou de l'épuisement de la puissance de calcul du processeur principal (CPU) est la première règle de l'optimisation. Adaptive Performance suit à chaque trame les données averageFrameTime (temps de trame moyen total) et averageGpuFrameTime (temps de fonctionnement GPU moyen) afin d'effectuer cette analyse. 17 Le temps CPU englobe les processus au cours desquels le thread principal (main thread) de Unity exécute la logique du jeu et le thread de rendu (render thread) prépare les données à envoyer au GPU (batching des draw calls, etc.). 17 Un détail important est que les blocages au niveau du système d'exploitation ou les temps d'inactivité/d'attente (idle/wait times) pendant lesquels le CPU attend que le GPU termine son travail ne sont pas inclus dans la mesure du temps CPU. 17 À la suite de l'analyse de ces durées, le système attribue le goulot d'étranglement actuel (PerformanceBottleneck) à l'une des quatre catégories suivantes : ● CPU : Les algorithmes d'intelligence artificielle en jeu, les calculs de physique complexes ou un nombre excessif d'instanciations d'objets (instantiation) étouffent le processeur. 20

● GPU : Les effets de transparence multicouches (overdraw), la lecture de textures haute résolution et les effets lourds de post-traitement (post-processing, par exemple SSAO ou Bloom) limitent l'unité graphique. 22

● TargetFrameRate (Fillrate) : Le système a déjà atteint le taux d'images cible, il n'y a pas de saturation matérielle et le matériel suffit même s'il fonctionne en dessous de son potentiel. 2

● Unknown : Il s'agit d'états intermédiaires où la source de la latence ne peut pas être déterminée avec certitude.

En s'abonnant à l'événement PerformanceStatus.PerformanceBottleneckChangeEvent (via le pattern delegate), les développeurs peuvent intercepter les moments où l'état du goulot d'étranglement change pendant le jeu et y répondre par des réactions algorithmiques appropriées. 23 Par exemple, lorsque le goulot d'étranglement bascule soudainement vers le CPU, la fréquence de balayage du champ de vision (raycast) des unités d'IA dans un monde ouvert peut être réduite de 60 fois à 15 fois par seconde, allégeant ainsi instantanément la charge mathématique sur le processeur.

Moteur de prise de décision et d'exécution : Indexer et ajusteurs d'échelle (Scalers)

Le mécanisme qui permet au système Adaptive Performance de fonctionner de manière autonome repose sur le fonctionnement en parfaite harmonie de deux composants fondamentaux : le cerveau appelé « Indexer » (Indexeur) et les organes d'exécution appelés « Scalers » (Ajusteurs d'échelle).

Mécanisme de l'Indexer (Indexeur)

L'Indexer est le coordinateur central qui calcule l'« Indice de qualité » actuel du jeu en passant continuellement à travers un filtre mathématique les tendances thermiques complexes et les données de goulot d'étranglement obtenues depuis l'appareil. 19 La tâche principale de l'Indexer est d'éviter de créer une instabilité visuelle (oscillation) en modifiant constamment la qualité du jeu à chaque petite fluctuation de température ou de FPS du matériel. Pour assurer cette stabilité, le Thermal Action Delay (Délai d'action thermique) et le Performance Action Delay (Délai d'action de performance) peuvent être définis en secondes dans Project Settings. 23 Même si le système détecte un goulot d'étranglement, il s'assure que la situation est permanente pendant ce délai défini, prend ensuite une décision d'action et envoie un signal aux ajusteurs d'échelle connectés pour réduire la qualité (StateAction.Decrease). 23

Analyse de l'impact mathématique et visuel des ajusteurs d'échelle (Scalers)

Les ajusteurs d'échelle (Scalers) sont des scripts qui modifient au moment de l'exécution (runtime) les fonctionnalités spécifiques du Render Pipeline (Pipeline de rendu) de Unity ou du moteur physique. 19 Le niveau (Level) par défaut de chaque ajusteur d'échelle est zéro. À chaque signal « réduire la qualité » provenant de l'Indexer, ce niveau augmente ; à mesure que le niveau augmente, le détail de la fonctionnalité contrôlée par l'ajusteur d'échelle diminue. 19 Le moment et l'ordre dans lesquels les ajusteurs d'échelle entrent en jeu sont déterminés par une matrice de décision tridimensionnelle 19 :

1. Cible du goulot d'étranglement (Targeting Bottleneck) : Si l'analyse détermine que le goulot d'étranglement est le GPU, l'Indexer ignore les ajusteurs d'échelle qui optimisent le CPU et force directement ceux qui ciblent le GPU (par exemple la résolution).

2. Niveau le plus bas (Lowest Level) : La priorité est accordée aux fonctionnalités dont le niveau n'a pas encore été augmenté (conservant leur qualité d'origine).

3. Impact visuel (Visual Impact) : Il s'agit de la probabilité que le joueur remarque une baisse de qualité de la fonctionnalité. Il est classé comme Bas (Low), Moyen (Medium) ou Élevé (High). 19 Le système commence toujours par réduire d'abord les fonctionnalités ayant un impact visuel Bas.

Le système offre une gamme extrêmement large d'ajusteurs d'échelle, tant pour le pipeline de rendu standard que pour l'Universal Render Pipeline (URP). Le tableau ci-dessous détaille les cibles matérielles de ces ajusteurs d'échelle et leurs effets théoriques au sein de l'application.

Classe d'ajusteur d'échelle Cible du goulot d'étranglement Impact visuel Effet théorique et pratique dans le pipeline de rendu (Render Pipeline) AdaptiveFramerat e CPU / GPU / Fillrate Élevé Modifie la variable Application.targetFr ameRate du jeu entre les limites. Particulièrement efficace lorsque VSync est désactivé. Une baisse de 60 FPS à 30 FPS augmente le temps d'inactivité de tous les composants sur la puce, créant une période de refroidissement radicale. 19 AdaptiveResolutio n GPU / Fillrate Élevé Réduit dynamiquement l'échelle de résolution du rendu de l'écran (Resolution Scale). 19

Dans les projets URP, il fonctionne via Render Scale. Comme il réduit géométriquement le taux de remplissage de pixels (fillrate), c'est l'arme la plus puissante pour briser la charge thermique du GPU, mais il dégrade directement la netteté de l'image. 15 AdaptiveLOD CPU / GPU Moyen Manipule les distances de transition (LOD bias) du niveau de détail (Level of Detail - LOD) des modèles 3D dans la scène. 18 Même si la caméra s'approche des modèles, il permet aux versions à faible nombre de polygones de rester à l'écran, réduisant ainsi les draw calls du CPU et les calculs de sommets (vertex) du GPU. 18 AdaptiveShadow mapResolution GPU Moyen/Bas Dans URP, il réduit la résolution en pixels de la carte d'ombres (shadow map). Comme la pixellisation des bords d'ombre lorsqu'il y a beaucoup de mouvement à l'écran est cognitivement difficile à percevoir, cela soulage la bande passante de la mémoire GPU sans compromettre la qualité. 19 AdaptiveShadowC ascade CPU / GPU Moyen Réduit le nombre de cascades dans les lumières directionnelles URP. Chaque cascade d'ombres nécessite que les objets projetant des ombres dans la scène soient rendus une fois de plus (draw call). La réduction du nombre de cascades soulage directement le goulot d'étranglement du CPU. 19 AdaptiveViewDist ance CPU / GPU Élevé Réduit le plan de coupe lointain (far clip plane) de la caméra principale, garantissant que les objets éloignés ne sont en aucun cas inclus dans le flux de rendu (frustum culling). 19 C'est l'une des étapes d'optimisation les plus critiques, en particulier dans les jeux en monde ouvert. 15 AdaptiveLayerCull ing CPU / GPU Moyen Au lieu de réduire la distance de vue générale, il ajuste la distance de visibilité de certaines couches Unity (Layers). 2

Par exemple, en restreignant la distance de rendu de la couche des détails environnementaux (herbe, petits décors), les structures imposantes autour du joueur sont préservées tandis que les minimes détails sont supprimés, améliorant ainsi les performances. 16 AdaptivePhysics CPU Élevé Allège la charge CPU en modifiant les étapes de mise à jour (fixedDeltaTime) ou le nombre d'itérations du moteur physique de Unity (PhysX ou Box2D). 2 Les calculs physiques sont parmi les principaux coupables des goulots d'étranglement liés au CPU. 21 AdaptiveBatching CPU Bas Contrôle les processus de traitement par lots dynamique (Dynamic Batching). Il soulage le CPU dans les situations qui ne nécessitent pas de calculs excessifs de sommets (vertex). 19 AdaptiveDecals CPU / GPU Bas Dans le système URP, il réduit la charge d'overdraw lors de la phase de rendu des matériaux en limitant la distance de rendu ou le nombre d'autocollants/décalcomanies (decals) tels que les impacts de balles ou les taches de sang sur les murs. 2

Les développeurs ne sont pas obligés de se limiter uniquement aux ajusteurs d'échelle par défaut. Développer des « ajusteurs d'échelle personnalisés » (Custom Scalers) adaptés aux mécaniques spécifiques du jeu est une pratique fortement recommandée. 2 Pour écrire un ajusteur d'échelle personnalisé, il suffit d'hériter de la classe AdaptivePerformanceScaler et de surcharger (override) la méthode OnLevel(), en plus des propriétés de base telles que VisualImpact, Target et MaxLevel. 19 Par exemple, dans un jeu se déroulant dans un environnement brumeux, un ajusteur d'échelle personnalisé peut être écrit pour augmenter la densité du brouillard à mesure que la température augmente (Adaptive Fog). Ainsi, la distance de vue du joueur se rétrécit naturellement, tandis qu'en arrière-plan, la distance de rendu de la caméra est raccourcie, créant une illusion d'optimisation majeure. 15

Modes de contrôle des performances et gestion de la fréquence d'horloge (Clock Frequency)

Adaptive Performance ne se contente pas de réduire les fonctionnalités graphiques au sein du moteur de jeu, mais possède également la capacité d'intervenir directement ou indirectement sur la puissance électrique et les fréquences d'horloge fournies par le système d'exploitation au CPU et au GPU. Le fonctionnement des processeurs à leurs fréquences d'horloge maximales crée une inefficacité asymptotique ; autrement dit, en échange d'une faible quantité de puissance de calcul supplémentaire gagnée, une quantité gigantesque d'énergie est consommée et de chaleur est produite. 17

Pour gérer cet équilibre énergétique, l'interface d'Adaptive Performance propose trois modes de contrôle (PerformanceControlMode) différents : Système, Manuel et Automatique. 20

1. Mode Système (System Performance Control) : C'est le mode par défaut valable sur les systèmes autres que le fournisseur Android (par exemple la simulation de bureau). Le système d'exploitation détermine lui-même les fréquences CPU/GPU à l'aide de méthodes traditionnelles, Adaptive Performance n'intervient pas sur le matériel, il réduit uniquement les graphismes au sein de l'application. 20

2. Mode Manuel (Manual Performance Control) : C'est le mode dans lequel le développeur peut attribuer directement les variables Instance.DevicePerformanceControl.CpuLevel et GpuLevel entre 0 et le niveau maximum. 23 L'utilisation de ce mode de contrôle n'est absolutely pas recommandée en dehors de tests de benchmark très spécifiques. 17 Si un développeur n'ayant pas une connaissance approfondie des contraintes thermiques et des caractéristiques de décharge de la batterie du matériel mobile maintient constamment le niveau CPU à un niveau élevé, l'appareil va rapidement surchauffer, le système d'exploitation déclenchera des mécanismes de défense enfermant le jeu dans la phase de « Throttling », et la batterie sera inutilement épuisée. 20

3. Mode Automatique (Automatic Performance Control) : C'est le mode de contrôle le plus sûr, le plus efficace et dont l'utilisation est fortement recommandée. 17 Tout ce que le développeur a à faire est de définir le taux d'images cible du jeu (par exemple 30 ou 60) avec Application.targetFrameRate. 23 Le mode automatique analyse en arrière-plan la température de l'appareil, le temps de rendu et l'environnement d'exécution (si l'on se trouve dans un menu ou en jeu). 20 Si le jeu atteint très facilement l'objectif de 60 FPS, au lieu de faire tourner inutilement le processeur à pleine capacité, il réduit silencieusement les fréquences d'horloge du CPU et du GPU. Le taux d'images reste à 60, mais le matériel consomme beaucoup moins d'électricité, ce qui permet au jeu de rester frais et à la batterie de durer des heures (Battery Life Preservation). 20

Surcharge temporaire de puissance : Le mode Boost (Mode Renfort)

Dans certains moments des jeux mobiles, une très grande capacité de traitement ponctuelle est nécessaire plutôt qu'une performance durable. Pour ces scénarios spécifiques, Adaptive Performance intègre l'API « Boost » (Renfort). 23 Lorsque le mode Boost est appelé, la fréquence de fonctionnement minimale du CPU ou du GPU est temporairement égalisée à la fréquence de fonctionnement maximale, forçant le matériel à fonctionner à son plein potentiel. 23

Les endroits où le mode Boost doit être utilisé de manière stratégique sont les suivants 23 :

● Réduire au minimum les temps de chargement (load time) des modèles lourds à charger en mémoire sur les écrans d'attente (Loading Screens) au lancement du jeu ou des niveaux.

● Éliminer les temps d'attente survenant lors de l'extraction de grands paquets téléchargés sur le réseau (Network) ou durant des opérations de traitement de données asynchrones.

● Éviter les micro-ralentissements d'une seconde (hitches) que le joueur pourrait subir lors des phases de compilation de Shader (Shader Compilation) ou de génération de contenu procédural.

Cependant, l'activation du mode Boost tire un courant massif de la batterie de l'appareil et fait monter instantanément la température du SoC. 23 Si le système d'exploitation est déjà entré dans la phase de Throttling (bridage thermique) (si l'appareil est extrêmement chaud), afin d'éviter d'endommager le matériel, la demande de Boost de Unity ou les commandes d'ajustement manuel des niveaux CPU/GPU sont directement rejetées par le système d'exploitation, transférant de force le contrôle au « Mode Système ». 23 Il est vital pour les développeurs d'utiliser cette interface uniquement sur les écrans de chargement où le joueur attend de manière passive, et pendant des durées de quelques secondes.

Interface Développeur : Utilisation de l'API C# et Visual Scripting

La flexibilité du paquet Adaptive Performance permet aux développeurs d'utiliser le système de manière autonome sans écrire une seule ligne de code s'ils le souhaitent, ou de concevoir une logique personnalisée qui plonge au cœur du jeu.

Programmation événementielle (Event-Driven) via l'API C#

Les développeurs qui souhaitent accéder par programmation aux données thermiques du système y accèdent via l'objet Singleton UnityEngine.AdaptivePerformance.Holder.Instance (ou Mobile.AdaptivePerformance.Holder dans les versions plus récentes) créé avec le paquet. 18 Notamment, pour détecter si l'appareil est sur le point d'entrer en goulot d'étranglement (ThrottlingImminent), l'événement IThermalStatus.ThermalStatus.ThermalEvent (delegate) est écouté. 2

Lorsqu'un événement est déclenché (par exemple, lorsqu'une alarme de surchauffe se déclenche), l'état est analysé avec une structure switch-case pour intervenir sur les mécaniques de jeu. 2 Si le niveau d'alerte est Throttling, la fréquence d'images passe de 60 à 15 ou 30 ; s'il n'y a pas d'alerte, elle revient à l'objectif de 60. 2 De même, si le goulot d'étranglement se situe du côté du CPU, certains des agents d'intelligence artificielle actifs sur la carte peuvent être désactivés avec un script personnalisé (script), ce qui soulage instantanément le processeur. 2

Intégration de Visual Scripting

Pour les artistes techniques non-programmeurs (technical artists) et les concepteurs de jeux, un support complet de l'API C# via les paquets Visual Scripting a été introduit à partir d'Unity 5.0 et des versions ultérieures. 29

Une fois le paquet Visual Scripting inclus dans le projet, le chemin Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units doit être suivi pour s'assurer que les nœuds (nodes) d'Adaptive Performance sont ajoutés à l'interface Fuzzy Finder. 27

Grâce à cette intégration, l'accès à un ensemble de nœuds personnalisés est fourni 30 :

● Nœuds thermiques : Le nœud On Thermal Metric est déclenché instantanément lorsque le niveau d'alerte thermique de l'appareil, le pourcentage de température (Temperature Level) et la tendance de la température (Trend) changent. La broche de sortie de ce nœud peut être connectée directement à une logique qui désactivera une source lumineuse lourde ou un système de particules dans la scène.

● Nœuds de performance : Le nœud On Bottleneck signale si le goulot d'étranglement est le CPU, le GPU ou le Fillrate ; les nœuds Frame Timing et FPS sont idéaux pour afficher les données de performance en temps réel sur l'écran du jeu. Grâce au nœud Cluster Info, les charges de cœur de l'architecture big.LITTLE peuvent être lues.

● Nœuds de boost et de niveaux : En ajoutant le nœud Set Boost au début des blocs de chargement de scène dans le graphique de script visuel, les vitesses de chargement peuvent être maximisées sans écrire de code ; l'état actuel du processeur peut être lu avec Get Performance Level.

Méthodologie de test, de profilage et d'optimisation

L'ajout du système Adaptive Performance au projet ne résout pas tous les problèmes à lui seul ; un système mal configuré peut gâcher la qualité graphique du jeu trop tôt ou s'avérer totalement inutile. Le processus de développement doit reposer sur une méthodologie scientifique de mesure et de comparaison (profiling and benchmarking).

Création d'une référence (Baseline) et test A/B

Selon les pratiques d'optimisation conjointes des ingénieurs de Google et d'Unity, la première étape à franchir est de mesurer les performances du jeu avant d'activer ADPF ou Adaptive Performance (Baseline). 6 Le jeu doit être chargé sur un appareil mobile physique doté des configurations minimales requises ciblées (min-spec) et être joué pendant environ vingt minutes jusqu'à ce que l'appareil chauffe. 21 Pendant ce test, l'outil Unity Profiler doit être connecté à l'appareil via un réseau sans fil (Wi-Fi) (Autoconnect Profiler) afin d'enregistrer les minutes où les FPS commencent à chuter et les valeurs de Frame Time. 1

Ensuite, le système Adaptive Performance est activé dans le projet avec les régleurs par défaut et le même scénario de test est exécuté depuis le début. 6 Via le nouvel onglet "Adaptive Performance" du module Profiler, il convient d'examiner côte à côte avec le premier test la minute exacte où l'appareil a émis l'alerte ThrottlingImminent, le régleur activé par le système (AdaptiveResolution par exemple) et l'impact de cela sur les temps CPU/GPU. 2 Si le développeur arrive à des conclusions telles que "Le jeu fournit toujours 60 FPS à la 10e minute mais la résolution baisse trop", il doit modifier les pondérations des régleurs dans l'Indexer et effectuer un réglage fin (fine-tuning) spécifique au jeu. 6

Simulation en environnement de bureau : Device Simulator

Bien que les tests sur appareil soient essentiels, attendre qu'un téléphone physique chauffe et refroidisse réduit la vitesse d'itération pendant la phase de codage. Pour surmonter ce problème, le fournisseur Simulator (Desktop) Provider a été développé. 2 En ouvrant la fenêtre Window > General > Device Simulator sur l'ordinateur de développement de bureau, le niveau de batterie, la tendance thermique et les goulots d'étranglement de l'appareil virtuel peuvent être déclenchés artificiellement (artificial bottlenecks). 2 Le développeur peut faire passer l'état de l'appareil virtuel à la phase de Throttling en un seul clic et tester instantanément en quelques secondes comment les régleurs personnalisés qu'il a écrits (Custom Scalers) modifient la densité de brouillard ou les détails des modèles (LOD) dans le jeu. 2

Synergie avec les approches d'optimisation traditionnelles

Adaptive Performance n'est pas un algorithme miracle ; il ne peut pas sauver à lui seul un jeu dont les bases sont mal conçues. Le système crée un effet multiplicateur massif lorsqu'il est combiné avec les pratiques d'optimisation mobiles classiques. 1

● Les textures (textures) du jeu doivent être conçues dans des dimensions de puissances de deux (POT - Power of Two) et des formats de compression matérielle mobile tels que ASTC et ETC2 doivent être utilisés. 8

● Les options Read/Write Enabled des modèles et des textures qui ne seront pas modifiés au moment de l'exécution doivent être désactivées pour empêcher la conservation de copies inutiles dans la mémoire CPU et GPU. 31 La consommation de mémoire (memory bandwidth) est l'une des plus grandes sources de chaleur. 1

● Si le capteur d'accéléromètre (accelerometer) sur le matériel mobile n'est pas activement utilisé par le jeu (par exemple, s'il ne s'agit pas d'un jeu de course), la réduction ou la désactivation de la fréquence de balayage de l'accéléromètre via les Paramètres du joueur libère le système d'exploitation d'un fardeau considérable et élargit l'enveloppe thermique (thermal envelope). 31

● Les matrices de sélection des caméras (Occlusion Culling) doivent être soigneusement cuites (baked) et des dizaines de milliers de modèles polygonaux qui ne sont pas dans le champ de vision de la caméra mais qui restent derrière les murs doivent être éliminés sur le CPU avant d'être envoyés au processeur graphique (draw call). 3

Lorsqu'un jeu dont le temps de surchauffe a été porté à 15 minutes grâce à toutes ces mesures traditionnelles est soutenu par les régleurs AdaptiveResolution ou AdaptiveFramerate d'Adaptive Performance, qui constituent la dernière ligne de défense, il se transforme en un chef-d'œuvre mobile parfait et durable, où les chutes de 60 FPS à 45 FPS s'étendant sur des heures ne sont jamais remarquées par le joueur.

L'absence de ventilateurs de refroidissement sur le matériel mobile oblige les développeurs de jeux à jouer aux échecs avec les limites thermiques du silicium. Ce voyage technique, qui commence par un simple avertissement d'installation de fournisseur tel que « Paramètres de performance adaptatifs », atteint la maîtrise de l'accès aux vannes de gestion de l'énergie du système d'exploitation, de la lecture des dérivés de l'analyse thermique et de la manipulation en temps réel des algorithmes de qualité du pipeline de rendu. Lorsque le processus d'optimisation se concentre sur la durabilité d'une fréquence d'images fluide (sustained performance) plutôt que sur l'atteinte de performances maximales (peak performance), il maximise à la fois la satisfaction des joueurs et ouvre la voie au succès à long terme sur les plateformes mobiles.

*Information : Les visuels ont été générés par Google Gemini.