Hmm hmm, bien sûr que c'est possible. Tu peux mmaper des buffers graphiques et y acceder depuis le CPU. Inversement, les GPUs font du DMA depuis la VM de la tâche utilisateur.
Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Tu pourrais refaire des tests sur ton ordi ?
Je referais le test dimanche, mais tu as teste avec quoi ? Perso mon test, c'est de lancer emacs dans Terminology sous Enlightenment et avoir un powertop dans un second tab dans Terminology pour voir la consomation. Je coupe aussi le Wifi/Bluetooth/Ethernet pour pas avoir de variation du a un quelconque traffic.
Il pourrait même faire usage des KMS planes ce qui ferait que bouger une fenêtre consommerait ~0W coté rendu.
L'utilisation des planes pourra effectivement aider enormement. Et pas uniquement lorsqu'on utilise OpenGL, car tres souvent le hardware qui gere les plans graphiques est decorele de celui qui fait l'acceleration OpenGL. Ceux-la ouvre des trucs tres interressant. Par exemple avec 5 plans graphiques pour une application full screen, tu peux parfaitement imaginer gerer une liste verticale a 60fps en software. Tu utilises 3 plans pour la liste, un pour l'overlay, un pour le background. A tout moment, tu n'affiches jamais que 2 plan pour la liste, le 3eme etant en preparation. Avec des plans de la bonne taille, tu as le temps de mettre a jour le 3eme avant que celui ne soit affiche et tu peux le faire dans un thread separe qui ne bloquera pas l'animation des autres plans en mouvement qui ne necessite pas de rendu. Ca demande beaucoup de logique dans le toolkit (identique que ce soit avec le GPU ou en soft qu'on remplisse les dit plan). C'est aussi quelque chose qui s'applique tres bien pour les navigateurs web.
Par contre Wayland n'expose pas encore un moyen pour les applications de savoir combien de plan son disponible et si c'est une bonne idee de les utiliser (Par exemple oui pour l'application qui a le focus, moins pour celle en background). Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Je referais le test dimanche, mais tu as teste avec quoi ? Perso mon test, c'est de lancer emacs dans Terminology sous Enlightenment et avoir un powertop dans un second tab dans Terminology pour voir la consomation. Je coupe aussi le Wifi/Bluetooth/Ethernet pour pas avoir de variation du a un quelconque traffic.
L'utilisation des planes pourra effectivement aider enormement. Et pas uniquement lorsqu'on utilise OpenGL, car tres souvent le hardware qui gere les plans graphiques est decorele de celui qui fait l'acceleration OpenGL. Ceux-la ouvre des trucs tres interressant. Par exemple avec 5 plans graphiques pour une application full screen, tu peux parfaitement imaginer gerer une liste verticale a 60fps en software. Tu utilises 3 plans pour la liste, un pour l'overlay, un pour le background. A tout moment, tu n'affiches jamais que 2 plan pour la liste, le 3eme etant en preparation. Avec des plans de la bonne taille, tu as le temps de mettre a jour le 3eme avant que celui ne soit affiche et tu peux le faire dans un thread separe qui ne bloquera pas l'animation des autres plans en mouvement qui ne necessite pas de rendu. Ca demande beaucoup de logique dans le toolkit (identique que ce soit avec le GPU ou en soft qu'on remplisse les dit plan). C'est aussi quelque chose qui s'applique tres bien pour les navigateurs web.
Par contre Wayland n'expose pas encore un moyen pour les applications de savoir combien de plan son disponible et si c'est une bonne idee de les utiliser (Par exemple oui pour l'application qui a le focus, moins pour celle en background). Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !