Non, c'est faux. On a uniquement besoin de xshm pour les applications qui n'utilisent pas le GPU ou la pile graphique pour rendre son buffer. Les autres GPUs doivent utiliser GEM pour allouer et partager leurs buffers graphiques.
On parlait uniquement du cas software ici, donc on est d'accord :-)
D'après mon expérience, avec un compositeur software, quand je bouge une fenêtre, mon PC consomme 30W contre 9W en hardware. Tu parles de pas faire de copies tout le temps, mais un compositeur sw fait ça en permanence…
On n'a clairement pas le meme laptop :-) Le mien tourne a 7W quand je code avec le compositeur software de E17 et Terminology, ca monte a 9W avec le compositeur GL. Mais il n'utilise pas l'extention de partial swap de Intel, peut etre qu'en l'implementant cela changerait la donne. Le compositeur sw va faire une copie que des zones qui ont change, alors qu'en OpenGL, tu es oblige de tout redessiner a l'ecran (Donc tu fais plus de boulot et tu utilises plus de hard). Pour ce qui est des copies de buffer, elles sont inherente a X et on ne peut s'en passer que avec une extention te permettant de controller directement les buffers et la mise a jour partiel. Malheureusement, je n'ai pas ce genre de fonctionnalite sur mon laptop, uniquement sur du SoC ARM et je ne peux alors que te donner des chiffres de Android vs X.
Tu as utilise quoi comme compositeur sw, car a part E17, je n'en connais aucun autre ? Et non, llvmpipe n'est pas une reponse valable pour moi. C'est une solution completement inadapte pour faire un compositeur avec un minimum de performance. C'est bien pour tester une stack GL, mais pas pour autre chose.
Je te conseille vraiment d'étudier xdamage, ça devrait te prouver que tu as une mauvaise vision des flux entre les applications et X.
Je connais xdamage, merci :-) Et je pense que j'ai une petite idee de comment les flux passes entre X et les applications. Maintenant, j'ai clairement une experience plutot oriente SoC, donc avec des optimisations non disponible pour les GPU discrets.
Je trouve que tu as tendance à inventer des chiffres comme bon te semble, je me trompe? Si ton compositeur plante, met à jour ta distro car ça fait un bon moment que ça n'a arrive plus à part avec Nouveau si la carte est mal supportée.
Alors dans la vraie vie, les cartes a base de Radeon ont en general un driver bugge jusqu'a la moelle par exemple. C'est une des raisons pour lesquels avant de debugger le moindre bug report lie au compositeur dans Enlightenment, on demande sur quel carte graphique le probleme se pose. Pour l'histoire, fut un temps, le compositing ne pouvait marcher avec les drivers officiels de ATI que lorsque le process s'appele compiz… Et depuis, la situation ne s'est pas franchement ameliore chez eux. Chez NVidia, on n'a pas eu de probleme rapporte depuis quelques annees maintenant, mais leur driver genere des memcpy inutiles supplementaire qui font tourner le CPU pour rien lors de l'upload de texture entre autre chose (Je n'ai aucun retour d'utilisateur de Nouveau, ca veut dire que ca doit marcher :-)). Et chez Intel, ca semble etre bon avec les derniers drivers (Il y avait des dead lock en sorti de blank screen avant). Donc sauf a etre sur une Arch ou Gentoo, a peu pres personne n'a un driver correct.
Participant au developpement d'un compositeur, celui d'Enlightenment, j'ai une petite experience de l'etat du parc de driver posant probleme sur Linux. C'est sur, je ne vois que les gens qui viennent se plaindre ! Mais la situation est globalement mauvaise du cote des drivers Linux, c'est bien pour ca qu'il est succidaire de s'appuyer uniquement sur un compositeur hardware.
Le développeur principal de Wayland travaille chez Intel, tu crois vraiment qu'il ferait un truc pas utilisable sur leur plateforme?
Il va falloir que je me remette a jour sur Wayland, mais ma comprehension du truc, c'est que l'application controle les buffers et qu'elle peut faire du double buffer en utilisant une combinaison de wl_surface_attach, wl_surface_damage et wl_surface_commit. Ce qui devient un chemin sans copie sur SoC, et se resoud par un DMA vers le GPU cote serveur Wayland sur un GPU discret. Mais ca, c'est dans mes souvenirs, ca fait bien un an que je n'ai pas regarde. Ca serait domage que ce ne soit plus le cas.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
On parlait uniquement du cas software ici, donc on est d'accord :-)
On n'a clairement pas le meme laptop :-) Le mien tourne a 7W quand je code avec le compositeur software de E17 et Terminology, ca monte a 9W avec le compositeur GL. Mais il n'utilise pas l'extention de partial swap de Intel, peut etre qu'en l'implementant cela changerait la donne. Le compositeur sw va faire une copie que des zones qui ont change, alors qu'en OpenGL, tu es oblige de tout redessiner a l'ecran (Donc tu fais plus de boulot et tu utilises plus de hard). Pour ce qui est des copies de buffer, elles sont inherente a X et on ne peut s'en passer que avec une extention te permettant de controller directement les buffers et la mise a jour partiel. Malheureusement, je n'ai pas ce genre de fonctionnalite sur mon laptop, uniquement sur du SoC ARM et je ne peux alors que te donner des chiffres de Android vs X.
Tu as utilise quoi comme compositeur sw, car a part E17, je n'en connais aucun autre ? Et non, llvmpipe n'est pas une reponse valable pour moi. C'est une solution completement inadapte pour faire un compositeur avec un minimum de performance. C'est bien pour tester une stack GL, mais pas pour autre chose.
Je connais xdamage, merci :-) Et je pense que j'ai une petite idee de comment les flux passes entre X et les applications. Maintenant, j'ai clairement une experience plutot oriente SoC, donc avec des optimisations non disponible pour les GPU discrets.
Alors dans la vraie vie, les cartes a base de Radeon ont en general un driver bugge jusqu'a la moelle par exemple. C'est une des raisons pour lesquels avant de debugger le moindre bug report lie au compositeur dans Enlightenment, on demande sur quel carte graphique le probleme se pose. Pour l'histoire, fut un temps, le compositing ne pouvait marcher avec les drivers officiels de ATI que lorsque le process s'appele compiz… Et depuis, la situation ne s'est pas franchement ameliore chez eux. Chez NVidia, on n'a pas eu de probleme rapporte depuis quelques annees maintenant, mais leur driver genere des memcpy inutiles supplementaire qui font tourner le CPU pour rien lors de l'upload de texture entre autre chose (Je n'ai aucun retour d'utilisateur de Nouveau, ca veut dire que ca doit marcher :-)). Et chez Intel, ca semble etre bon avec les derniers drivers (Il y avait des dead lock en sorti de blank screen avant). Donc sauf a etre sur une Arch ou Gentoo, a peu pres personne n'a un driver correct.
Participant au developpement d'un compositeur, celui d'Enlightenment, j'ai une petite experience de l'etat du parc de driver posant probleme sur Linux. C'est sur, je ne vois que les gens qui viennent se plaindre ! Mais la situation est globalement mauvaise du cote des drivers Linux, c'est bien pour ca qu'il est succidaire de s'appuyer uniquement sur un compositeur hardware.
Il va falloir que je me remette a jour sur Wayland, mais ma comprehension du truc, c'est que l'application controle les buffers et qu'elle peut faire du double buffer en utilisant une combinaison de wl_surface_attach, wl_surface_damage et wl_surface_commit. Ce qui devient un chemin sans copie sur SoC, et se resoud par un DMA vers le GPU cote serveur Wayland sur un GPU discret. Mais ca, c'est dans mes souvenirs, ca fait bien un an que je n'ai pas regarde. Ca serait domage que ce ne soit plus le cas.