Lien d'origine : http://blog.uwa4d.com/archives/presentandsync.html
WaitForTargetFPS, Gfx.WaitForPresent et Graphics.PresentAndSync sont les paramètres qui nous sont souvent demandés. Vraisemblablement, vous qui lisez cet article avez souvent rencontré ces surcharges CPU excessives dans Profiler. À cet égard, parlons aujourd'hui des significations spécifiques et des règles de déclenchement de ces paramètres.
WaitForTargetFPS
Ce paramètre apparaît généralement lorsque la surcharge du processeur est trop faible et que la fréquence d'images cible est définie (Application.targetFrameRate) . Lorsque l'image précédente est inférieure à la fréquence d'images cible, un temps d'attente d'inactivité WaitForTargetFPS sera généré dans cette image pour maintenir la fréquence d'images cible.
Analyse : cet élément est en fait exécuté en premier dans la boucle principale du moteur Unity, c'est-à-dire que le moteur maintient en fait le FPS en cours d'exécution à la valeur cible en complétant WaitForTargetFPS dans l'image actuelle en fonction de la consommation de temps CPU de l'image précédente. Par exemple, si la fréquence d'images cible est de 30 images par seconde et que la dernière image a pris 15 ms, alors le WaitForTargetFPS dans l'image actuelle sera de 18 (33-15) ms, mais l'autre temps dans cette image est de 28 ms, puis dans Profiler this La durée totale d'une trame devient 46 (18+28) ms.
Par conséquent, le phénomène de surcoût élevé du profileur causé par cette valeur est en fait une "illusion" chronophage, et vous pouvez "fermer les yeux" pendant le processus d'optimisation.
Gfx.WaitForPresent && Graphics.PresentAndSync
Ces deux paramètres ont souvent une utilisation élevée du processeur dans Profiler et ne peuvent être vus que dans la version finale. La raison est en fait causée par la synchronisation verticale (VSync) entre le CPU et le GPU. La raison pour laquelle il y a deux paramètres est principalement liée au fait que le projet autorise le rendu multi-thread . Lorsque le rendu multithread est activé pour le projet, ce que vous voyez est Gfx.WaitForPresent ; lorsque le rendu multithread n'est pas activé pour le projet, ce que vous voyez est Graphics.PresentAndSync .
Graphics.PresentAndSync fait référence au temps d'attente de la présentation du thread principal et au temps d'attente de la synchronisation verticale. La signification littérale de Gfx.WaitForPresent est également le temps d'attente pour Present, mais beaucoup de contenu est en fait omis ici. Sa véritable signification devrait être le temps que le thread principal actuel (MainThread) doit attendre pour se présenter dans le thread de rendu (Rendering Thread) . Cela ressemble toujours à une bouchée, alors expliquons-le en détail.
Lorsque le projet démarre le rendu multi-thread, le moteur met autant que possible Present et d'autres travaux connexes sur le thread de rendu, c'est-à-dire que le thread principal n'a besoin que d'appeler le thread de rendu via des instructions et de le laisser effectuer Present, réduisant ainsi la pression sur le fil principal. Cependant, lorsque le CPU veut effectuer une opération Present, il doit attendre que le GPU termine le dernier rendu. Si la surcharge de rendu GPU est élevée, l'opération Present du CPU sera toujours en attente, et le temps d'attente est le temps Gfx.WaitForPresent de l'image actuelle, comme illustré dans la figure ci-dessous.
De même, lorsque le projet n'autorise pas le rendu multi-thread, le moteur effectuera Present dans le thread principal (la plupart des jeux mobiles utilisent actuellement cette opération).Bien sûr, l'opération Present doit également attendre que le GPU termine le dernier rendu . Si la surcharge de rendu GPU est élevée, l'opération Present du processeur sera toujours en attente et le temps d'attente correspond à l'heure Graphics.PresentAndSync de l'image actuelle, comme illustré dans la figure ci-dessous.
Nous avons fait un exemple plus extrême pour montrer cette situation. Sur la version Unity 5.3.3, créez 60 UIPanels plein écran, activez et désactivez respectivement le rendu multithread et ne définissez pas TargetFPS. Ensuite, la surcharge CPU de ce paramètre sur le périphérique Samsung S6 est la suivante :
Lorsque le rendu multithread est activé :
Lorsque le rendu multithread est désactivé :
Ainsi, si la consommation de temps CPU de Gfx.WaitForPresent ou Graphics.PresentAndSync est très élevée dans votre projet, ce n'est pas qu'ils effectuent eux-mêmes des opérations mystérieuses, mais que votre tâche de rendu actuelle est trop lourde et que la charge GPU est trop élevée. Cordialement .
Dans le même temps, pour les projets qui permettent la synchronisation verticale, Gfx.WaitForPresent et Graphics.PresentAndSync auront également une utilisation élevée du processeur. Avant d'expliquer ce genre de problème, prenons "tout le monde prend le métro" comme exemple. D'une manière générale, le temps pour que le métro atteigne chaque station est moyen et certain, en supposant qu'un groupe de passagers est pris en charge toutes les 10 minutes. Mais peu de passagers peuvent arriver à l'heure. Si vous arrivez deux minutes plus tôt, vous n'avez qu'à attendre deux minutes pour monter dans le métro. Quelques minutes pour prendre le métro.
Nous rencontrons souvent la situation ci-dessus. Dans le pipeline de rendu du GPU, le principe de fonctionnement de la conversion du tampon avant et du tampon arrière est en fait le même que "prendre le métro". Vous pouvez simplement imaginer le pipeline GPU comme une rame de métro. Pour les appareils mobiles, la fréquence d'images du GPU est généralement de 30 images par seconde ou 60 images par seconde, c'est-à-dire que VSync "arrive une fois" toutes les 33 ms ou toutes les 16,6 ms, et le présent du CPU est "les passagers prennent le métro" , puis accédez aux destinations respectives. Semblable à l'arrivée anticipée et à l'arrivée tardive des passagers, le CPU Present aura également des situations similaires, telles que :
La surcharge côté CPU est très faible. Present est exécuté très tôt, mais à ce moment VSync n'est pas encore arrivé, et il y aura un temps d'attente élevé, c'est-à-dire que la surcharge CPU de Gfx.WaitForPresent et Graphics.PresentAndSync semble être drogué. La figure ci-dessous montre l'utilisation du processeur de Graphics.PresentAndSync sur un appareil Samsung S6 dans la version Unity 5.3.3, lorsqu'une scène vide n'active pas le rendu multithread et ne définit pas TargetFPS.
La surcharge côté CPU est élevée, de sorte que le Present manque l'opération VSync pendant l'exécution. De cette façon, le Present devra attendre l'arrivée de la prochaine VSync, ce qui entraînera une surcharge CPU élevée de Gfx.WaitForPresent et Graphics.PresentAndSync. Cette situation est particulièrement susceptible de se produire lorsque des ressources excessives sont chargées côté CPU, telles que WWW chargeant un gros AssetBundle, Resource.Load chargeant un grand nombre de textures, etc.
Grâce à l'explication ci-dessus, nous espérons que vous avez une compréhension approfondie de Gfx.WaitForPresent et Graphics.PresentAndSync en ce moment. Peu importe la quantité de CPU occupée par ces deux paramètres, ce n'est en fait pas un problème de ces deux paramètres eux-mêmes, mais causé par d'autres parties du projet. À cet égard, nous ferons un résumé pour faciliter votre impression ultérieure.
Il y a trois raisons principales à l'utilisation élevée du CPU de ces deux paramètres :
L'overhead CPU est très faible, donc le CPU attend que le GPU termine le travail de rendu ou l'arrivée de VSync ; l'
overhead CPU est élevé, de sorte que le Present manque le VSync de l'image actuelle, c'est-à-dire qu'il doit attendez que la prochaine VSync arrive ;
la surcharge du GPU est élevée et le CPU doit attendre la fin d'une trame de travail de rendu sur le GPU.
Enfin, comment optimiser et réduire l'utilisation CPU de ces deux paramètres ? Autrement dit, ignorez les deux paramètres Gfx.WaitForPresent et Graphics.PresentAndSync, optimisez tout ce que vous pouvez optimiser !
Avez-vous le sentiment d'avoir été trompé pendant longtemps, mais heureusement, Yuhu-kun vous a sauvé ~