Wayland est un protocole pour serveur graphique qui se veut, à long terme, le remplaçant de X. Il est récemment sorti en version 1.0 et continue son développement. Le développement de Wayland est accompagné du développement du compositeur de référence (implémentant le protocole), Weston.
Weston sans 3D
Une des grandes critiques de Wayland était que le compositeur par défaut nécessitait des pilotes graphiques prenant en charge les opérations 3D, ce qui limitait le nombre de cartes graphiques pouvant être utilisées. C'est une critique en train de devenir obsolète, un patch récent permet d'utiliser Weston dans un serveur X, sans ces pilotes 3D, mais en utilisant une bibliothèque ne nécessitant qu'un CPU. Et ce code va être adapté pour qu'il soit utilisable en natif, sans serveur X.
Compiz ne migrera pas vers Wayland
Le développeur principal de Compiz a annoncé qu'il ne migrera pas son compositeur vers Wayland, non pas parce qu'il trouve que c'est un mauvais projet mais parce qu'il pense qu'il vaut mieux implémenter les fonctionnalités de Compiz dans Weston plutôt que de fragmenter encore plus le monde des compositeurs Wayland et d'augmenter la complexité de Compiz en le rendant compatible avec Wayland. Il continuera toutefois à maintenir Compiz pour X.
Les applications arrivent
Petit à petit, de plus en plus d'applications sont nativement compatibles avec Wayland, voici par exemple un backend Wayland pour mplayer2. Attention si vous voulez l'essayer, il requiert une version assez récente de FFMPEG, n'oubliez de lire les instructions.
Wayland pour Android
La version de Wayland pour Android n'est pas oubliée avec le développement de wayland-java : une interface entre la bibliothèque d'arrière-plan libwayland et le langage Java. Il est donc maintenant possible de développer des applications Java pour Wayland. Ce développement est encore récent et jugé expérimental.
NdA : merci à Nÿco, reno, Jarvis et fravashyo pour leurs contributions à cette dépêche.
Aller plus loin
- Weston sans 3D (307 clics)
- Compiz et Wayland (233 clics)
# Weston sans 3D
Posté par alpha_one_x86 (site web personnel) . Évalué à 6.
Je +1. Très bonne initiative.
J'attends que KDE support pleinement Qt5 pour passer à wayland.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Weston sans 3D
Posté par ariasuni . Évalué à 6.
+1 aussi, parce que j'en ai chié des pilotes pour cartes ATI qui marchent pas.
KDE 5 arrivera dans à peu près 1 ans donc ça laisse du temps pour qu'ils passent à Qt5… Mais j'apprécie qu'ils ne fassent pas dans la précipitation.
Mais ne faut pas non plus oublier que (Kwin va avoir besoin d'un peu de travail)https://community.kde.org/KWin/Wayland. Néanmoins l'architecture de Kwin fait que de nombreuses parties sont indépendantes de X11.
De toute façon il va falloir un peu de temps avant de voir arriver Qt5, et beaucoup plus avant qu'arrive Wayland. Donc autant ne pas se précipiter.
Écrit en Bépo selon l’orthographe de 1990
# Compiz ne migrera pas vers Wayland
Posté par Atem18 (site web personnel) . Évalué à -7.
Ubuntu va enfin redevenir une distribution utilisable au quotidien. Parce que depuis que Compiz à été porté en C++, c'est une vraie merde. J'attends donc avec impatience Unity + Wayland.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Astaoth . Évalué à 8.
Installe FVWM/E17/XFCE/"n'importe quoi de léger" comme interface graphique, ca marchera mieux. Si tu trouves qu'un programme fait ramer ton ordi, rien ne t'empêche de le désinstaller et de le remplacer par autre chose de plus léger, pour rendre ta distribution préférée utilisable.
Emacs le fait depuis 30 ans.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Nonor . Évalué à 10.
Sauf que compiz, côté WM qui dépote au niveau fonctionnalités et performance, c'est un peu une référence. Donc oui, n'avoir le droit qu'à une réécriture qui n'assure pas, ça fait mal. Et proposer un quelconque WM ou DE dont le profil fonctionnel n'a absolument rien à voir en remplacement, je vois pas l'intérêt.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Gabin II . Évalué à 10.
Ou Gnome-shell voire KDE. Ou alors le Lenovo de 4 et demi que j'ai sous les yeux est une machine de guerre avec ses 2go de ram et son GMA4500 integrée.
Si il y a bien un truc de lourd, ce sont ces moules qui propagent des trolls moisis et qui osent proposer du FVWM en 2012.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par zerkman (site web personnel) . Évalué à 2.
Tu as raté le passage en 2013 ?
Et puis bon une machine de 4 ans, c'est pas encore trop dépassé, mais quand tu commences à chercher dans le matériel de 8 ou 9 ans, c'est une autre histoire.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Astaoth . Évalué à 1.
Euuuuuhhhhhhhh j'utilise fvwm en fait.
Emacs le fait depuis 30 ans.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Gabin II . Évalué à -1. Dernière modification le 18 janvier 2013 à 11:14.
J'imagine bien et cela n'a rien d'impossible ou d'extraordinaire.
J'utilise Awesome sur des machines légères ou sans accélération OpenGL mais quand je dis "légères" ce n'est pas tant due à un manque de puissance mais plus par limitation en dépendances logicielles car ces machines sont plus spécifiques, après, c'est juste une question de bon sens ou de pragmatisme, diront certains.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Atem18 (site web personnel) . Évalué à -3.
Non merci, je suis passé sous Elementary OS, qui est basée sur Ubuntu 12.04. Et même si c'est une beta 1, tout marche parfaitement et aucun problème de performances. Donc Compiz est bel et bien la source des problèmes d'Ubuntu. N'en déplaise à ceux qui m'ont moinser.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Maxime (site web personnel) . Évalué à 8.
Ce que tu sembles pas comprendre c'est que tu peux utiliser Ubuntu sans utiliser Unity. Donc si Compiz est pour toi un problème, tu le remplaces par autre chose et puis voilà. On change pas de distro juste pour changer de window manager.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Kekun (site web personnel, Mastodon) . Évalué à 3.
Au fond ce n'est pas VRAIMENT changer de distro puisqu'ils utilisent les dépôts d'Ubuntu + un PPA, et quelques optimisations. C'est un plus un "spin".
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Misc (site web personnel) . Évalué à 7.
En même temps, quand les gens présentent Kubuntu comme étant différente de Ubuntu ( qui se présente elle même comme étant totalement différente des autres distros qui intègrent les mêmes softs ), forcément que les plus débutants qui sont sous Ubuntu font pas la différence.
Tenter de lutter contre ça, c'est trop tard.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Atem18 (site web personnel) . Évalué à -5.
Ce que les gens ne semblent pas comprendre, c'est que je suis lassé des DE "batards". Pour moi, c'est soit Gnome ou KDE. Les autres étaient cools dans les années 2000, mais c'est terminé à présent.
Le Gnome d'Ubuntu n'est plus ce qu'il était autrefois. Il n'y a que sous Fedora que je me suis senti bien à cause de son aspect "Vanilla", car aucun patch farfelu n'entre par dessus les releases upstream.
Pour Kubuntu, je n'en dirais pas plus. Juste que je me suis lassé de KDE à force.
Donc de mon point, si, on change de distro si l'intégration est foireuse. Par chance, j'ai trouvé Elementary OS dont le WM n'est pas bugé à fond. Donc continuez à faire vos fanboys Ubuntu ou Unity ou Compiz si ça vous chante, mon point de vue ne changera pas;Compiz en C++ est de la merde et même son développeur l'a dit : Apology
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Maxime (site web personnel) . Évalué à 3.
Tu sais que t'es en train de traiter de fanboy "Ubuntu ou Unity ou Compiz" un utilisateur de Debian qui utilise Awesome WM ?
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Atem18 (site web personnel) . Évalué à -5.
Et? J'ai encore le droit de donner mon avis, non? Si tu te sent concerné par mes propos, ce n'est pas de ma faute.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Maxime (site web personnel) . Évalué à 3.
Mais tu réponds à mon message par "Donc continuez à faire vos fanboys Ubuntu ou Unity ou Compiz si ça vous chante, mon point de vue ne changera pas", c'est normal que je me sente concerné non ?
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Atem18 (site web personnel) . Évalué à -6.
Pas forcement. Tu utilises Compiz sous Debian? Tu contribues au code Compiz, etc. ? Si non, je ne vois aucune raison de te sentir visé.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par ariasuni . Évalué à 2.
Unity c'est un plugin de Compiz. Je ne savais pas à quel point j'avais raison quand j'ai dit que c'était problématique comme architecture. Defective by design.
Toujours est-il qu'il sera toujours possible de faire tourner X.org dans Wayland, donc c'est pas encore trop grave. Et a priori les perfs de X.org dans Wayland seraient meilleure que celles de X.org tout court.
Mais Compiz, c'était exceptionnel avec les fenêtre qui prenaient feu en se fermant… Quelqu'un pour faire le même effet avec Kwin? A priori c'est pas trop dur mais c'est très largement en dehors de mes compétences. Quoiqu'un effet de feu doit être assez compliqué!
Quant à Compiz en lui-même, oui c'est un peu la merde, beaucoup de paquets avec certains un peu abscons, pas réussi à le faire fonctionner sur Arch, Canonical n'a peut-être pas œuvré qu'à l'amélioration de compiz… /troll
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Shuba . Évalué à 1.
Une des manières de faire un effet de feu peut-être en utilisant de la génération procédurale. Dans mes souvenirs, tu pars d'une fractale bien choisie, avec de la randomisation pour ne pas obtenir quelque chose d'uniforme, et tu te sers des valeurs de cette fractale pour contrôler une densité de points et la couleur de ces points, et en jouant sur les paramètres tu peux obtenir quelque chose de joli. Il existe des livres listant quel type de fractale convient à quel effet.
Voilà ça c'est la théorie, du moins ce dont je me souviens de mes cours, après pour l'implémentation ce serait une autre histoire.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 5.
Use the source Luke!
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/compiz-plugins-extra/precise-proposed/files/head:/firepaint/
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par ariasuni . Évalué à 1.
Super idée, par contre les plugins de Kwin sont en Javascript. J'imagine que du coup c'est plus simple.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Mali (site web personnel) . Évalué à 4.
J'ai du mal à imaginer que cela puisse être plus rapide en rajoutant des couches au mille feuilles …
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Sufflope (site web personnel) . Évalué à 8.
Et pourquoi pas ? Y a bien les VM XP qui tournent plus vite vu que l'hôte Linux gère mieux le cache disque, etc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Xaapyks . Évalué à -3.
Bad OS spotted.
J'ai du mal à croire à ton argumentation. Si le XP est plus lent alors qu'il a le droit d'utiliser toute la ram pour lui tout seul… mais que dans une VM le Linux hote arrive à maintenir ses propres caches ainsi que ceux de la VM tout en maintenant de meilleures perfs, alors le problème est au niveau d'XP…
Mais ca ne m'étonne pas, de toute façon le writeback des OS Microsoft c'est quelques nano secondes à peine, ils ne peuvent pas se permettre de mettre plus : Entre les boulets qui arrachent les clés USB à peine le transfert terminé et le noyau qui plante quand ça lui chante… C'est le seul moyen de garantir de retrouver ses données (là tu peux dire troll spotted)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Xaapyks . Évalué à 2.
Le système hôte n'honore peut être pas les écritures en temps réel par défaut, mais il commit bien sur son fichier disque de temps en temps quand même… Donc on en revient au principe de période de writeback dirty, qui sur windows est très très courte, alors que sur linux elle est bien plus longue de base… Passer par une VM rajoute juste un temps de writeback artificiel à XP qui lui est donc favorable car mal configuré de base.
D'ailleurs tu peux très bien avoir configuré ta VM (qemu le fait : "media=disk,cache=none") pour mapper directement les I/O de ton guest sur le fichier disque dur de ton hôte, et donc dans ce cas ce que tu racontes est erroné.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Xaapyks . Évalué à 4. Dernière modification le 15 janvier 2013 à 12:49.
Pourquoi tu tournes ça au fanboyisme Linux ?
D'ailleurs, Virtual Box aussi permet de désactiver le cache, dans Configuration->stockage il y a une case "Utiliser le système de cache E/S de l’hôte"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 2.
Si tu parle d'un problème de performance, note que coté performance il n'est pas sûr que le passage à Wayland apporte grand chose: avec l'extension DRI2 X permet déjà d'avoir un transfert efficace de buffer entre un client et le serveur comme Wayland(perfectible cependant puisque j'ai lu que certains voudraient faire évoluer l'extension), là où il y aura des gains c'est qu'avec Wayland le serveur d'affichage inclue le compositeur donc moins d'IPC, à voir si ça apporte une réelle amélioration sur les perfs ou pas.
Wayland c'est d'abord et avant tout pour simplifier la maintenance de la pile graphique ce qui apportera des gros bénéfices pour les développeurs, je ne sais pas si les utilisateurs verront beaucoup de changement..
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par ariasuni . Évalué à 2.
A priori on aura quand même un gain (mais de quel ordre?) Faudra tester.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Arkem . Évalué à 2.
J'ai entendu parler d'un important gain de sécurité aussi, mais je ne suis pas expert…
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Didrik Pining . Évalué à 8.
Et moi j'ai entendu parler d'un gain important au niveau du chou-fleur. Mais je suis pas expert, faudrait gouter.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par ariasuni . Évalué à 8.
En effet, faire un keylogger pour Xorg est d'une simplicité effarante, il est facilement possible de faire un verrouillage d'écran non-déverrouillable, et pleins d'autres trucs car Xorg isole les utilisateurs mais pas les applications d'un même utilisateur.
J'ai retrouvé cet article de LWN, très intéressant qui raconte les détails.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 10.
C'est cool de se voir cité :)
Pour information, on refera une présentation à la FOSDEM sur la sécurité de la pile graphique.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 10.
DRI2 X ne marche que pour les applications OpenGL. Avec Wayland, toutes les applis utiliseront l'équivalent de DRI2.
Pour vous faire une idée de l'amélioration des performances, vous pouvez forcer qt à utiliser raster plutôt que le rendu par la XLib. Dans le mode xlib, Qt envoie à X les commandes via une socket pour rendre sa fenêtre. Dans le mode raster, il utilise son moteur interne pour faire le rendu puis il envoie les modifs complètes via la socket vers X. Je n'arrive pas à retrouver les benchmarks mais le résultat est étonnant :) J'utilise ça en permanence sur ma KDE.
Avec wayland, ça ira encore plus vite car on aura même plus besoin de sérialiser les commandes ou l'image finale dans une socket et traiter le rendu de toutes les applis dans une thread unique (X). Avec Wayland, les applis font leur propre rendu puis envoient l'handle GEM/DMABUF ("le pointeur vers le buffer") au compositeur qui n'a plus qu'à faire son travail, le compositing ("mettre dans l'écran l'ensemble des fenêtres à la bonne place"). Plus de sérialisation du rendu, plus d'utilisation d'un toolkit 2D très limité (X11/XRender).
J'espère que c'est plus clair maintenant! :)
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 3.
Si le toolkit gère OpenGL, l'application devient OpenGL de facto, non?
Je pense à GTK+ et Cairo (je ne pense pas que Qt ai l'équivalent).
Pour pinailler un peu: il y a un exemple de client Wayland utilisant la mémoire partagée, mais on peut espérer que ce soit rare en pratique en effet.
Où en mémoire partagée en local.
Il me semble que dans le mode Qt/raster ou OpenGL(DRI2), il n'y ni sérialisation, ni utilisation d'un toolkit 2D puisque dans les 2 cas, le client peut écrire dans son buffer lui-même et envoyer le résultat par mémoire partagée(Qt raster) ou buffer vidéo (DRI2), non?
Après le compositing est sérialisé, mais bon c'est aussi le cas pour Weston.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 10.
Qt, gtk+ et cairo (cairo-gl) peuvent en effet utiliser OpenGL pour le rendu. Mais c'est pas forcement ce qui est le plus performant. De plus, le nombre de contextes hardware est limité sur certains hw/drivers. C'est une question sur laquelle nous travaillons depuis 2011 sans avoir de véritable réponses. On a vraiment à faire un trade-of entre la sécurité et les performances quand on atteind la limite :s
Je doute que pour certains rendus, un contexte OpenGL apporte quoi que ce soit (si ce n'est des perfs en moins). Je pense que ça va être quelque chose que les applis vont devoir choisir.
Oui, en effet. Pour être honnête, j'avais zappé cette amélioration :)
Par mémoire partagé, pour sûr. Par BO, je doute, à vérifier. Dans le cas de la mémoire partagée, c'est sous optimal comparé à l'utilisation de buffers GEM car la mémoire partagée nécessite au minimum de placer le buffer partagé dans la GART ce qui est lent et augmente la pression sur cette zone. Dans le cas de buffers GEM, ils sont probablement déjà en VRAM, donc ça va plus vite :)
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 4.
Il reste que le protocol X (Xlib ou Xcb) est toujours serialise dans une socket. Ok, il y a moins de requete dedans, si on n'utilise pas Xrender, mais ca n'empeche que le cout de la serialisation dans un socket est la. Une amelioration simple serait d'utiliser un buffer shm pour communiquer avec X et de n'envoyer dans la socket que l'index ou commence dans le buffer shm de la serie de commande X. Cela serait plus efficace a mon avis pour les communications locales. Je me demande d'ailleur, comment est implementer cette partie la du protocol Wayland, je crois que ca passe tout dans la socket.
Ca depend. Si on fait du rendu soft, que le GPU utilise la meme memoire que le CPU et que le backend soft comprend le format du GPU alors oui. Sinon la vie est plus complique.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 9. Dernière modification le 15 janvier 2013 à 12:11.
Hmm, actuellement, les buffers ne sont pas copiés dans le cas de DRI2 et, pour les applis 2D, à priori, ils utilisent xshm. Ça permet de référencer/partager des buffers sans les copier. Dans Wayland, le même protocole existe (c'est même le seul chemin autorisé) et il ne faut pas espérer quel que soit d'autre.
Ah ah, très très mauvaise idée :D Déjà, toute la VRAM n'est pas accessible au CPU. De deux, il y a des tonnes de formats de tilling et de compression. C'est chercher la merde que d'essayer de faire un accès CPU dessus. Et pour finir, c'est lent! Il vaut mieux utiliser les moteurs de copies asynchrones proposés par le GPU.
Tout ça pour dire, si tu fais un rendu CPU, y'a pas de problèmes, faut juste le faire des un BO référencé par la GART et il sera uploadé en VRAM par le compositeur si nécessaire.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 3.
Xshm te donne une position et une taille, donc il y a bien une copie a ce moment la. Si tu as un GPU discret (discrete GPU ?), c'est effectivement une bonne chose de ne pas reuploader toute ta fenetre et de t'appuyer sur un DMA pour faire la copie. Par contre, si tu es sur la meme memoire, cas des SoC et de Intel, il vaudrait mieux completement eviter le DMA en accedant directement a la surface video. La plupart des SoC et Intel supporte de faire les operations depuis une surface non tile/compresse avec une faible perte de performance qui dans la pratique devient un gain du fait de l'absence de copie et de cas de rendu direct (pas de compositing, car fenetre au dessus ou plein ecran).
Par contre, ton point sur Wayland m'ennuie. Je sais que la partie rendu soft n'est pas vraiment au point (quid d'une appli OpenGL avec un compositing software par exemple). Mais bon, dans le pire des cas, tu dois pouvoir utiliser l'api EGL en maintenant le rendu en soft pour obtenir le meme resultat, non ?
Les GPU Intel et la plupart des SoC tombe pourtant dans cette categorie. Apres c'est vrai que pour NVidia et ATI, ce n'est pas le cas, mais c'est pas la majeur partie du parc. C'est bien pour ca que j'avais fait une petite liste de condition ;-)
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 4.
SHM ne nécessite pas de copie en soit. C'est juste du partage de pages mémoire physiques. Du coup, je suis pas sûr de saisir ce que tu veux dire.
On est d'accord.
C'est assez étonnant d'entendre parler de SoC Intel car la mémoire est toujours séparée, tout comme le chipset et les deux sont toujours indispensable. Du coup, c'est pas vraiment un System On Chip. Je suppose que tu fais un abus de langage SoC/puce.
Alors, je suppose que tu as dans l'idée d'avoir un compositeur software (pour une raison qui m'échappe). Tu veux donc pouvoir récupérer les données depuis le GPU. Dans le cas d'un GPU discret, tu dois récupérer le buffer depuis la VRAM en programmant la GART (soit en laissant le CPU accéder à la VRAM via la GART, soit en demandant au GPU de copier le buffer dans la RAM ce qui est bien plus performant!) puis tu peux faire ton compositing comme bon te semble mais avec une mémoire lente un processeur pas du tout parallèle. Dans le cas d'un GPU intel, le CPU peut directement bliter le buffer de l'application sur le framebuffer. Si l'application est en plein écran, elle peut directement rendre dans le framebuffer (attention à ne pas faire rendre toutes les applis dans le fb directement car sinon, on retrouve la merde de DRI1).
Cela dit, il faut une collaboration entre le driver GPU et le CPU pour pouvoir faire ça. Mais au fond, tu veux en venir où? Ce que tu proposes est sous optimal dans pratiquement tous les cas, et ne change rien dans d'autres (GPU avec mémoire partagée only).
C'est parfaitement possible de mixer le rendu logiciel et hardware. Cela dit, avoir une appli accélérée mais un compositeur software, ça me semble stupide. Tu as un cas en tête?
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 3.
Vu que tu travailles plutot avec des GPU discret, la copie dont je parle se fait a coup de DMA dans ce cas la et est effectivement impossible a eviter sur ces GPU.
Hum, en fait, je n'ai jamais regarde en detail les i7 et i5 avec GPU integre, mais de ce que j'ai compris sur leur SoC, tu partage le meme controleur memoire. Certe tu dois negocier avec le GPU pour mapper la memoire dans l'adresse space du CPU. Mais cela devient directement accessible et ne genere pas de copie quand tu "unmap" ta memoire pour la rendre de nouveau utilisable par le GPU. Tu peux donc avoir ton rendu software qui va cycler sur un certain nombre de buffer directement utilisable par le GPU. Je n'ai pas travaille assez longtemps sur SoC Intel pour etre sur du comportement, mais sur SoC Qualcom et Samsung, tu as clairement ce comportement. Je soupsonne que c'est le cas pour toutes les SoC qui supporte Android.
C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la. Pour les GPU a memoire partage, tu gagnes une copie memoire, ce qui a un impact direct sur les performances et se repercute principalement sur la consomation de la batterie (Le hard moderne tenant facilement les 60fps, c'est surtout la batterie qui montre les soucis de performance). Ce qui est logique, car toute operation que tu ne fais pas, ne consome pas de batterie :-) D'un point de vue difference, une stack X qui fait du xshm vs Android consomme plus de batterie aux environs de 30% (Mais ce chiffre dependra de ce que tu benchmark bienentendu).
Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ? Je n'ai besoin de basculer mon compositeur en OpenGL que lorsque je fais du multiscreen. Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin. Mais vu que je fais souvent de l'OpenGL, c'est pas mal de pouvoir quand meme avoir ce cas qui marche… Et ca, c'est sur un desktop, sur une tablette ou un telephone, le cas se presente encore plus frequement (consomation eleve de memoire du au context OpenGL, switch de context entre le compositeur et l'appli qui n'est pas forcement un moment joyeux, …).
Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 4.
Désolé pour le retard, j'avais totalement zappé de te répondre.
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.
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…
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 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.
Le développeur principal de Wayland travaille chez Intel, tu crois vraiment qu'il ferait un truc pas utilisable sur leur plateforme? De plus, Wayland a pour cible l'embarqué qui a une mémoire partagée. Je suis désolé, mais Wayland est ce que l'on peut faire de plus optimal sans faire de partage de framebuffer (à la DRI1 où les applications faisaient elles même le rendu sans passer par le compositeur).
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . É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.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 6.
La grosse amelioration de Wayland, c'est surtout le control du buffer video par l'application. Avec X, meme lorsqu'on evite d'utiliser Xrender pour le rendu, on est encore force d'uploader des buffers de pixels via xshm. Cela genere des memcpy inutile. Avec Wayland, l'application/le toolkit utilise deux buffers video et fait automatiquement les delta sur deux frames. Cela evite le memcpy inutile.
Mais techniquement, il n'y a rien la dedans qui ne serait pas impossible a faire avec X. En fait pour obtenir les meme perf, il suffirait de pas grand chose dans DRI (peut etre dans la version 3). Support de la mise a jour partiel et recuperation des buffers d'une fenetre. Du cote compositeur, il n'y a pas de changement a faire. Ce genre de fonctionalite serait aussi tres utile dans OpenGL, Intel a une extention pour ca, mais ca marche moyen.
Donc on peut encore corriger X pour etre aussi efficace que Wayland… Le seul truc qu'on ne peut pas, c'est le rendre sur. Ca, c'est la seule chose impossible sans changement d'architecture et c'est vraiment la ou Wayland vaut le cout.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 3.
Euh, même avec DRI2? Ce n'est pas ce que j'avais cru comprendre en lisant la description, après la documentation de DRI2 est vraiment pas terrible..
Effectivement quand je parlais de bénéfice pour l'utilisateur, je pensais uniquement aux performances, qu'on ne pourra réellement mesurer qu'une fois les KDE ou Gnome seront portés, mais la sécurité potentiellement amélioré de Wayland est aussi un bénéfice important.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 7.
Faudrait que je bouge mon cul encore un peu sur cet aspect. J'ai publié une première version des patchs pour augmenter la sécu DRM et j'ai modifié libdrm, libdri2proto, xserver, nouveau-ddx et mesa pour pouvoir en tirer parti. J'ai pas essayé encore de le faire marcher avec Wayland. Faudrait que je le fasse!
Cependant, la sécurité coté DRM n'est pas encore bonne et pour rendre ça propre, il me faudra modifier ttm et gem, ce qui ne m'enchante guère surtout que j'ai jamais mis les mains là dedans :D Bon, pour être honnête, j'avais jamais les mains dans le xserver, le ddx et mesa avant de faire mon patchset render nodes non plus…
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 4.
C'est en effet la seule modification, mais de taille.
Alors, ce que tu dis est une possibilité. Wayland supporte en effet ce qui était l'extension XDamage. Cependant, on est pas obligé de l'utiliser! Dans une vidéo ou un jeu vidéo, il vaut mieux ne pas se faire chier avec ça!
Tu auras toujours un blit à faire, ça change pas grand chose à part que le buffer ne peut pas être en VRAM.
Je ne suis pas d'accord. Changer X en Wayland, c'est casser la compatibilité avec la majorité des applications X actuelles. Si tu parles uniquement de l'aspect graphique, tu es pas loin de la vérité cela dit. Tout ce qui est dans Wayland est déjà dans X depuis des années mais uniquement pour les applications qui utilisent la 3D. Mais y'a un truc que X supporte pas, c'est que les applications rendent leurs buffers en avance et disent au compositeur de faire un flip sur un buffer à un temps donné. Ça permet aux applis vidéo de décode X images, se rendormir puis recommencer à rendre un peu avant que le compositeur n'ait plus d'images à rendre.
Ça c'est clair, on peut pas le rendre sûr sans casser des applis. Autant garder les 2 modèles et faire une transition au rythme de chacun.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 1.
pour les applications utilisant ou ayant un toolkit qui utilise OpenGL: ces applications pouvant faire de la 3D ou de la 2D, OpenGL n'impliquant en rien qu'on fait de la 3D, un rectangle texturé à plat sur une fenêtre pour moi c'est une image 2D même si ça utilise une interface prévue pour la 3D au départ.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 3.
Tu pinailles, à part glamor, personne n'utilise opengl uniquement pour la 2D. Mais oui, tu as raison.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par reno . Évalué à 2.
Je pinaille parce que quand tu parles d'application 3D ça fait penser à un jeu, alors qu'en fait une application normale peut utiliser DRI2 'automagiquement' si elle a le bon toolkit configuré pour ça..
Sinon pour [à part glamor, personne n'utilise opengl uniquement pour la 2D], Cairo est décrit comme 'designed to provide primitives for 2-dimensional drawing across a number of different backends' et il a une backend OpenGL donc ça en fait au moins 2 il me semble..
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Si moi! http://devnewton.bci.im/projects/newton_adventure
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # 2D en OpenGL
Posté par jihele . Évalué à 2.
Teeworlds !
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 5.
Si les Enlightenment Foundation Library font tout a fait ca ! L'inconvenient est que le code de redimensionnement des fenetres X avec OpenGL est particulierement lent (on peut limite compter en seconde). Cela limite donc son utilisation a des machines types telephone, tablette ou tv. La ou l'utilisateur ne peut pas jouer avec la taille de la fenetre.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Le canvas des applis QT/QML peut utiliser OpenGL, même si les applis ne sont qu'en 2D.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par Martin Peres (site web personnel) . Évalué à 4.
Qt/QML sait aussi faire de la 3D et la mixer avec la 2D. Mais qu'on soit clair, allouer un contexte OpenGL sur la carte graphique pour rendre une appli 2D, c'est une grosse connerie. Le context switching sur une carte graphique, c'est rarement contrôlable (implémentation hardware) + très lent (plusieurs centaines de Ko de contexte à quelques Mo si on veut du vrai préemptif)! Et c'est sans compter la limite hardware sur le nombre de contexte.
Nous sommes en train d'étudier la solution à ce problème dans Nouveau et c'est pas mignon!
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . Évalué à 2.
Ce qui reste un cas particulier avec un seul rectangle :-) Tu me l'accordera, mais tu passes quand meme pas mal de temps devant ton ecran a regarder des applications statiques ou seule un petit curseur de 10 par 20 pixels clignotes. Si tu travailles sur ton laptop avec un compositing et des applications incapable de faire du partial update, tu vas y perdre une bonne partie de ta batterie a rien faire d'autre que de redessiner la meme chose a l'ecran. C'est d'ailleur une des optimisations d'Android, les applis sont en rendu direct la plus part du temps et font au tant que possible du partial update. La difference de consommation avec un X/Toolkit classique qui ne fait pas attention est de l'ordre de 50% de conso supplementaire sur des simples zone de texte qui clignote par exemple.
Je me suis peut etre pas exprime assez clairement. Mais il est completement possible d'implementer au niveau des compositeurs X, l'equivalent de ce que fait le protocol Wayland. C'est d'ailleur surement le chemin que vont suivre la plus part des desktops linux en implementant Wayland en parallele de leur compositeur X. Bien entendu, ca, c'est en oubliant le probleme de securite. Mais l'interet sera d'avoir une adoption plus rapide de Wayland et un test grandeur nature des limites du protocol aussi. Il y a encore quelques trucs necessaire pour faire un desktop Linux complet avec Wayland et tant que ce ne sera pas la, ca avancera doucement.
# Re: Petites brèves autour de Wayland
Posté par Gof (site web personnel) . Évalué à 10.
Qu'est-ce que ça veux dire ?
Est-ce que on ne confonds pas Wayland et Weston dans cette phrase ?
[^] # Re: Petites brèves autour de Wayland
Posté par reno . Évalué à 4.
Oui, tu as raison.
[^] # Re: Petites brèves autour de Wayland
Posté par claudex . Évalué à 3.
Corrigé, merci.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Typo
Posté par Spack . Évalué à 10.
Wayland est un protocole, un des serveurs est Weston.
[^] # Re: Typo
Posté par claudex . Évalué à 3.
Corrigé, merci. Je savais bien que j'aurais dû attendre un peu plus avant de le publier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Typo
Posté par Pierre Tramonson . Évalué à 3.
protocol => protocole
des pilotes graphique => des pilotes graphiques
cartes graphique => cartes graphiques
[^] # Re: Typo
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigées, merci.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par cedric . Évalué à 0.
En general avec de l'ATI, tu pars quand meme avec un bon handicap… Tu peux toujours tenter des environnements plus leger, mais il ne faut pas croire au miracle.
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par Xaapyks . Évalué à 4.
Passe aux pilotes libres…
Même si wayland s'impose, j'ai du mal à croire qu'on verra des catalyst compatibles avant quelques années…
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par Albert_ . Évalué à 2.
Il me semble que les pilotes libres pour ATI ont un gros manque concernant la gestion d'energie. Et sur mon laptop si je tente d'utiliser la carte ATI ca chauffe du coup beaucoup.
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par Xaapyks . Évalué à 1.
C'est pas parfait mais ça marche.
http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options
Comme dit dans le wiki, dynpm fonctionne mais tu risques de voir un très léger flash quand la fréquence change…
Sinon tu forces à "low" au démarrage et basta, mais attention ton GPU va être un veau…
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par dinomasque . Évalué à 2.
Il y a peut-être un problème autrepart. Avec une Fedora brut de décoffrage, GNOME 3 est tout fluide chez moi sur une 2400XT (bas de gamme) et un Core2 à 2.4Ghz (et en plus c'est un iMac)
BeOS le faisait il y a 20 ans !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par Xaapyks . Évalué à 2.
Je connais peu Gnome, mais si compositing il y a, essaye si possible d'utiliser un backend Xrender et surtout pas OpenGL, sur KDE le compositing OpenGL est catastrophique de lenteur, même avec les derniers mesa et un GPU puissant (HD 6870 inside)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.