Exactement. Sachant qu'un gestionnaire de fenêtre est actif h24 et que 70% du parc informatique est mobile (smartphone+tablettes+notebook), le fait de solliciter le composant le plus juste (performance/consommation) pour réaliser une opération est essentiel. On a longtemps utilisé le cpu pour faire tout sauf ce pour quoi il a été conçu : du calcul séquentiel.
Si la vie etait si simple :-) Le CPU est plus efficace que le GPU quand tu dois mettre a jour qu'une petite partie de l'ecran (genre curseur qui clignote). Cas d'utilisation le plus courant. Il n'y a que quand une surface tres importante de l'ecran devient anime, que le GPU devient plus efficace (cout des transferts de donnees et des calculs supplementaires necessaires compense par la puissance brute necessaire a accomplir l'ensemble de la tache). Resultat, tu as envie d'avoir un rendu CPU la majorite du temps, avec un petit boost par GPU de temps en temps.
Sauf que la vie, elle a decide de t'embeter. L'initialisation et les transferts initiaux rendent impossible le dit scenario (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait). Tu te retrouves donc a devoir faire un choix. Etre plus efficace en batterie de maniere general et avoir une interface qui lag un peu de temps en temps, ou utiliser plus de batterie et ne pas avoir de lag. Il est donc impossible de solliciter automatiquement le composant le plus juste.
L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Si la vie etait si simple :-) Le CPU est plus efficace que le GPU quand tu dois mettre a jour qu'une petite partie de l'ecran (genre curseur qui clignote). Cas d'utilisation le plus courant. Il n'y a que quand une surface tres importante de l'ecran devient anime, que le GPU devient plus efficace (cout des transferts de donnees et des calculs supplementaires necessaires compense par la puissance brute necessaire a accomplir l'ensemble de la tache). Resultat, tu as envie d'avoir un rendu CPU la majorite du temps, avec un petit boost par GPU de temps en temps.
Sauf que la vie, elle a decide de t'embeter. L'initialisation et les transferts initiaux rendent impossible le dit scenario (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait). Tu te retrouves donc a devoir faire un choix. Etre plus efficace en batterie de maniere general et avoir une interface qui lag un peu de temps en temps, ou utiliser plus de batterie et ne pas avoir de lag. Il est donc impossible de solliciter automatiquement le composant le plus juste.
L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.