Quatre actualités concernant la pile graphique de Linux

Posté par (page perso) . Édité par patrick_g, Xavier Claude et Nÿco. Modéré par tuiu pol. Licence CC by-sa
Tags :
61
12
fév.
2012
Serveurs d'affichage

Dans le prolongement du récent FOSDEM, voici une sélection de quatre actualités concernant la pile graphique de Linux :

Mesa 8.0 est sorti !

La version 8.0 de Mesa 3D (la bibliothèque graphique libre qui implémente OpenGL pour systèmes Linux et cousins) vient de sortir, apportant notamment le support de la version 3.0 d'OpenGL.

Pour le moment, les pilotes libres compatibles OpenGL 3.0 sont ceux des circuits HD Graphics intégrés au dernier processeur Intel (Sandy Bridge) et au prochain (Ivy Bridge), le pilote Nouveau nvc0 (Fermi) pour les cartes Nvidia GeForce 400 et 500 et le pilote Radeon R600g pour les puces AMD R600/700, Evergreen (R800) et Northern Islands.

Il ne reste qu'à attendre que tout cela arrive dans nos distributions pour en profiter.

Ce travail sur Mesa est principalement dû à Intel dont les récentes puces Sandy Bridge prennent en charge OpenGL 3.0. Gageons que ce support sera étendu avec la sortie des prochaines puces (Ivy Bridge dont la sortie est proche serait compatible OpenGL 3.1, et Haswell qui prévu pour début 2013 serait compatible OpenGL 3.2).

Rappelons que la dernière version d'OpenGL en date est la 4.2, parue le 8 août 2011.

Wayland 1.0 en approche

La version 1.0 de Wayland, le successeur attendu de X.Org, pourrait arriver plus tôt que prévu : dès ce semestre !

Cela ne signifie pas pour autant le remplacement immédiat du deuxième par le premier dans votre distribution préférée : il reste du travail pour assurer une transition douce, même si les principaux toolkits se mettent déjà à la page (GTK+3, Qt 5.0, EFL, Clutter, libva).

Pour le moment c'est la version 0.85 qui vient de sortir, accompagnée par Weston, le compositeur de référence qui facilitera les futures implémentations de Wayland.

Meurs Poulsbo, meurs !

Intel conçoit et produit ses propres puces graphiques depuis 1998. Il en publie les spécifications et propose des pilotes open source.

Cependant, depuis 2008, pour les systèmes mobiles/embarqués, Intel associe à ses processeurs Atom une puce graphique PowerVR, fabriquée sous licence d'Imagination Technologies, censée offrir de meilleures performances et un meilleur rendement électrique que son équivalent maison. Il s'agit du GMA 500 (alias Poulsbo) et de son successeur : le GMA 600. Cet accord de licence interdit toutefois à Intel de proposer un pilote open source et, de fait, ces puces sont très mal gérées sous Linux.

Les progrès réalisés depuis par Intel sur ses propres puces graphiques lui permettraient d'envisager de laisser tomber dès l'an prochain la solution d'Imagination Technologies qui n'aura été finalement que transitoire. C'est une très bonne nouvelle pour les utilisateurs de Linux !

Mali libéré

Toujours dans le domaine des systèmes mobiles/embarqués, des pilotes 3D libres pour les processeurs graphiques Architecture ARM Mali 200 et 400 (qui équipent notamment des smartphones sous Android tels que le Samsung Galaxy S2) sont en train d'être développés par rétro-ingénierie sous l'impulsion de la société Codethink (projet « Lima »).

Voilà, je trouve que ça fait pas mal de bonnes nouvelles tout ça pour bien démarrer l'année :-)

  • # Pour une transition douce depuis wayland

    Posté par (page perso) . Évalué à  10 .

    Histoire de pas tout casser, une couche de compatibilité X11/Wayland devrait être disponible: xwayland.

    xwayland c'est en gros un X11 un peu modifié (style XVfb) qui se comporte comme un client wayland plutôt que faire le rendu lui même. Ce qui est cool c'est que xwayland peut utiliser des pilotes accélérés (intel) ou un pilote "software" (wlshm).

    Plus d'infos sur:
    - http://cgit.freedesktop.org/~krh/xserver/log/?h=xwayland-1.10
    - http://cgit.freedesktop.org/~iksaif/xf86-video-wlshm/
    - http://xf.iksaif.net/dev/wayland/xwayland-flash.png (Xorg + compositeur wayland en qt + xwayland + firefox + flash)
    - http://xf.iksaif.net/dev/wayland/xwayland-xeyes.png (xwayland + dwm + xterm + xeyes)
    - http://xf.iksaif.net/dev/wayland/xhosted-mdi-3.png (Xorg + compositeur wayland en qt + client natif wayland + xterm avec xwayland)

    PS: ça fait 6 mois que j'ai pas touché au code de wlshm, c'est fortement possible que ça ne compile plus, mais ça devrait pas être impossible à réparer.

    • [^] # Re: Pour une transition douce depuis wayland

      Posté par . Évalué à  10 .

      Petite question : En tant qu'utilisateur, est-ce qu'il y a une différence majeure entre wayland et Xorg ? ou est-ce que c'est comme IPv6, simplement mieux mais sans grande révolution pour l'utilisateur ?

      • [^] # Re: Pour une transition douce depuis wayland

        Posté par (page perso) . Évalué à  3 .

        C'est pas vraiment la même chose, ça fonctionne avec une logique différente.
        Je te conseille de lire ceci
        http://kdubois.net/?p=1217

      • [^] # Re: Pour une transition douce depuis wayland

        Posté par (page perso) . Évalué à  3 .

        Très difficile de répondre sachant que wayland n'est clairement pas finit et ça dépendra de toute façon beaucoup des compositeurs, wayland n'étant que le protocole de communication. Mais l'architecture devrait permettre de meilleures performances, un démarrage plus rapide, reste à voir ce que ça va donner.

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  3 .

          OK pour les meilleurs performances (en local, quand tu as un pilote OpenGL de bonne qualité pour ton matériel et un toolkit qui supporte Wayland), mais un "démarrage plus rapide"??
          La je ne vois pas..

          • [^] # Re: Pour une transition douce depuis wayland

            Posté par (page perso) . Évalué à  3 .

            C'est le kernel qui fait tout, et t'as pas un driver Xorg qui essaye de tout contrôler lui aussi (y compris l'input). Bon c'était déjà mieux avec kms, mais là c'est encore plus radical.

            • [^] # Re: Pour une transition douce depuis wayland

              Posté par . Évalué à  4 .

              Pour moi, ça devrait être exactement la même chose qu'avec X et KMS (d'ailleurs il me semble que si tu n'as pas KMS tu n'as pas Wayland), pour l'input je ne vois pas trop ce que ça va changer au niveau temps de démarrage!

              • [^] # Re: Pour une transition douce depuis wayland

                Posté par (page perso) . Évalué à  2 .

                d'ailleurs il me semble que si tu n'as pas KMS tu n'as pas Wayland

                Il me semble que ça dépend des compositeurs (même si en pratique, c'est le cas pour tout les compositeurs actuellement).

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  10 .

          Le changement le plus important d'un point de vue utilisateur sera surtout benefique pour les tablettes et les portables. Actuellement comme le compositeur et X sont separe, il n'y a pas moyen de faire gerer la rotation de l'ecran ailleur que dans X. Resultat, c'est moche et lent. Avec wayland, le process qui gere les input et le process qui fait le compositing sont merge. Il devient donc possible de faire subir des rotations sur les input. D'ailleur comme il y a reecriture du protocole, il serait possible que la rotation soit negocie entre l'application et le compositeur. Ainsi une application bien ecrite pourrait gerer la rotation elle-meme. Et par exemple laisse la toolbar ou elle est et juste faire une rotation avec une joli animation des icones. C'est un exemple, mais c'est quelque chose qu'on ne peut pas faire et qu'on ne pourra jamais faire avec X.

          Le deuxieme point interressant et ca, c'est plus pour les developpeurs de X et de Wayland, c'est qu'il reparte avec une base propre et pas avec vingt ans d'historique. Ca va clairement aider a avoir un code plus propre, plus maintenable et plus simple. Mais ca n'apportera pas franchement de gain visible a l'utilisateur.

      • [^] # Re: Pour une transition douce depuis wayland

        Posté par (page perso) . Évalué à  4 .

        Non, du point de vue de l'utilisateur de bureau, ça ne changera pas grand chose. Mais peu à peu s'installera la sensation que ça va mieux, plus vite, plus fluide, etc. Par exemple on aura plus à attendre le lancement de X11 au démarrage, on aura des effets 3D "plus mieux", les jeux iront plus vite (enfin, ça dépend des pilotes). Bref, un peu plus de confort (pour simplifier grossièrement).

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  3 .

          Concernant les pilotes, cela reprends la structures de ce que l'on a actuellement, ou il faudra attendre la stabilisation de Wayland. Pour que les nvidia/amd/intel fassent des pilotes ?

          Wayland à comme objectif d'être aussi un serveur graphique pour l'embarqué ?

          • [^] # Re: Pour une transition douce depuis wayland

            Posté par (page perso) . Évalué à  3 .

            @Laurent Mouillart :
            1°) Wayland tire parti de toutes les innovations récentes des pilotes libres : DRI2, KMS etc.
            Pour les pilotes proprio, c'est le pb des AMD et NVIDIA.
            2°) Tizen est en train d'être adapté pour intégrer Wayland par exemple.

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par (page perso) . Évalué à  7 .

          Lorsqu'un jeux 3D sera en fullscreen le alt-tab fonctionnera ? parce que avec X c'est pas trop ça ..

          http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

          • [^] # Re: Pour une transition douce depuis wayland

            Posté par (page perso) . Évalué à  4 .

            Ça dépend de comment est fait le fullscreen. Ça marche avec certains jeux (et on peut le contourner, par exemple en utilisant le mode plein écran de Kwin au lieu de celui du jeu).

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Pour une transition douce depuis wayland

              Posté par (page perso) . Évalué à  4 .

              Je suis pas certains que le fullscreen via le gestionnaire de fenêtre soit la même chose que le fullscreen opengl surtout en perf. Sinon ce problème de alt-tab c'est un peu la honte face à windows :)

              http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

              • [^] # Re: Pour une transition douce depuis wayland

                Posté par . Évalué à  -1 .

                Je ne vois pas de quel problème de alt-tab tu parles.
                Personnellement je n'ai aucun problème.

                Peut-être tu veux parler du fait que si on change de mode/résolution alors ca change tout X, et du coup un alt-tab t'amène sur un bureau tout pixelisé ?

                Sinon, quand le alt-tab ne fonctionne juste pas, c'est bien souvent parce que l'appli elle-même bloque la combinaison.

            • [^] # Re: Pour une transition douce depuis wayland

              Posté par . Évalué à  3 .

              ça m'intéresse ! Je vais creuser un peu ce mode plein écran alors…

              Mais la question se pose aussi pour d'autres besoins pourtant très simple : augmenter ou baisser le son, changer de bureau, etc.

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  2 .

          Par exemple on aura plus à attendre le lancement de X11 au démarrage

          Je ne suis pas sûr de bien comprendre là. Il n'y aura pas de processus Wayland à lancer ? Ça fonctionne comment ?

          • [^] # Re: Pour une transition douce depuis wayland

            Posté par (page perso) . Évalué à  1 .

            Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
            Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. Weston can run as an X client or under Linux KMS and ships with a few demo clients. The Weston compositor is a minmal and fast compositor and is suitable for many embedded and mobile use cases.

            http://wayland.freedesktop.org/
            voir aussi la FAQ (le tout en anglais hélas)

            • [^] # Re: Pour une transition douce depuis wayland

              Posté par . Évalué à  3 .

              Si je comprends bien il faudra donc bien lancer un processus (The compositor can be a standalone display server) comme quand on démarre X en somme. Quand je lance X, j'ai le modesetting déjà fait par le noyau et evdev est déjà utilisé pour détecter mes périphériques. Je ne suis pas sûr de voir la différence au final du point de vue du lancement.

              • [^] # Re: Pour une transition douce depuis wayland

                Posté par . Évalué à  8 .

                Je ne suis pas sûr de voir la différence au final du point de vue du lancement.

                Il n'y en a pas de mon point de vue, mais je pense qu'il y a beaucoup de gens qui en ont tellement marre des problèmes d'IHM actuels qu'ils ont décidé que X c'était mal (même quand les problèmes sont causés par les toolkits ou par les pilotes) et espèrent que Wayland va résoudre tout les problèmes.
                Quelque chose me dit qu'ils vont être bien déçus..

                Pour répondre à Adrien, si c'est bien fait un utilisateur ne verra pas la différence à part une amélioration de la fluidité en local si tu as un bon pilote de carte graphique. Bon comme toute nouveauté, il y a un risque d'avoir des bugs a cause de l'introduction de nouveau code bien sûr.
                J'imagine que dans certains cas (embarqué) une distribution peut choisir de ne pas mettre la compatibilité X et là il y aura un impact oui: plus d'export display qui fonctionne et utilisation possible uniquement des applications utilisant un toolkit porté sur Wayland.

                • [^] # Re: Pour une transition douce depuis wayland

                  Posté par (page perso) . Évalué à  3 .

                  Il y avait cette conférence de Keith Packard qui disait en gros : Linux est partout mais pas X, il faut se demander pourquoi et offrir ce que les gens attendent. Ben voilà.
                  A part ça il y a aussi le côté maintenance : il semble qu'avec X ce soit devenu complexe donc c'est pas mal de repartir sur une base neuve pour les développements futurs, tout le monde y gagnera (sauf les autres Unices libres peut être...)

                  • [^] # Re: Pour une transition douce depuis wayland

                    Posté par . Évalué à  1 .

                    tout le monde y gagnera

                    Sauf ceux qui utilisent le coté transparence réseau d'X: au mieux ils auront juste une petite perte de performance (serveur X client Wayland), au pire ils beaucoup de problèmes: cas où les toolkits virent le support d'X(*) avant qu'un remplaçant pour la transparence réseau arrive.

                    *: coté compatibilité les logiciels libres ce n'est pas toujours leur point fort.

                    • [^] # Re: Pour une transition douce depuis wayland

                      Posté par . Évalué à  2 .

                      Je soupçonne que pour RedHat et les autres autres l'avenir du réseau est du côté de SPICE, bien que les fonctionnalités ne soient pas vraiment identiques (et qu'il soit difficile de trouver un comparatif entre SPICE, X11, RDP et VNC). De toute façon le protocole X11 a déjà du mal avec les applications modernes qui utilisent de l'OpenGL et des animations dans tous les sens.

                      Personnellement j'aimais bien ssh -X, mais en toute honnêteté je ne m'en suis plus servi depuis l'unif quand je m'en servais pour lancer sur mon PC le matlab de l'unif...

                      • [^] # Re: Pour une transition douce depuis wayland

                        Posté par . Évalué à  2 .

                        Ton lien vers SPICE est mauvais: http://en.wikipedia.org/wiki/SPICE_(protocol)

                        Ensuite je ne vois pas en quoi un protocole lié à la virtualisation est si intéressant que ça.. Est-ce possible d'utiliser SPICE sans virtualisation?

                        De toute façon le protocole X11 a déjà du mal avec les applications modernes qui utilisent de l'OpenGL et des animations dans tous les sens.

                        Bah, est-ce un problème d'X11 ou bien est-ce un problème plus générique?
                        N'importe quel affichage distant aura des problèmes avec de la vidéo ou un jeu à 60 FPS..

                        As-tu des exemples en LAN ou X11 marche mal mais un autre protocole marches bien?
                        X11 n'est pas fait pour le WAN, il y a NX/FreeNX qui est prévu pour ça mais j'ignore ses forces/faiblesses par rapport aux autres..

                        • [^] # Re: Pour une transition douce depuis wayland

                          Posté par . Évalué à  1 .

                          Est-ce possible d'utiliser SPICE sans virtualisation?

                          Oui.

                          Bah, est-ce un problème d'X11 ou bien est-ce un problème plus générique?

                          Le problème c'est que l'opengl bypasse X11 et que les animations provoquent le redessin (et donc la retransmission) de toute la fenêtre. Pour corriger ça, il faut éviter d'utiliser d'opengl et probablement avoir un mode simplifié pour la GUI, comme fait microsoft avec le RDP.

                          Après, je ne sais pas comment SPICE adresse ce problème.

                          X11 n'est pas fait pour le WAN

                          En même temps, à l'heure actuelle, un protocole de ce type qui n'est pas fait pour le WAN est tout simplement inutile. Et si, X11 marchait très bien en WAN avec des applis en motif par exemple. Le matlab dont je parlais tout à l'heure, je l'utilisais derrière une ADSL et ça marchait au poil pour ce type d'applications "laides" et peu dynamiques.

                          • [^] # Re: Pour une transition douce depuis wayland

                            Posté par (page perso) . Évalué à  2 . Dernière modification : le 14/02/12 à 14:46

                            Est-ce possible d'utiliser SPICE sans virtualisation?

                            Oui.

                            C'est intéressant, ça. Aurais-tu un HOWTO qui traîne quelque part ? Parce que j'avais vu un comparatif RDP/ICA/SPICE, et SPICE était même meilleur qu'ICA, du coup je serais bien intéressé, parce que RFB (VNC), c'est pas du tout ça, même par rapport à du simple RDP. Il y a bien xrdp, mais avec le backend VNC il est lent, et le backend X11rdp nécessite de recompiler Xorg (aaaaargh). J'avais demandé à Gogol si quelqu'un parlait d'utiliser SPICE en-dehors de QEMU/KVM, mais jusqu'ici, j'ai fait chou blanc :-(

                            Envoyé depuis mon PDP 11/70

                    • [^] # Re: Pour une transition douce depuis wayland

                      Posté par . Évalué à  3 .

                      D'après Daniel Stone (développeur xorg), à moins d'utiliser un toolkit "ancien", on devrait aussi gagner côté transparence réseau.
                      Les toolkits modernes dessinent dans un buffer qui est ensuite transmis au serveur X. Et comme le buffer n'est pas compressé, cela donne un résultat particulièrement inefficace.

                  • [^] # Re: Pour une transition douce depuis wayland

                    Posté par . Évalué à  3 .

                    il faut se demander pourquoi et offrir ce que les gens attendent. Ben voilà.

                    Ben voilà quoi ? On le sait ce que les gens attendent ? Parce remplacer une solution technique par une autre sans préciser la méthode de réflexion, pas sûr que ça réponde à la problématique.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Pour une transition douce depuis wayland

                      Posté par . Évalué à  3 .

                      J'ai l'impression que dans ce cas là, en disant "les gens", il parlait des industriels. "linux est partout, pas X" ça parle pas des utilisateurs qui utilisent tous X.
                      Ca parle des devices qui embarquent le noyau mais pas X.

                      Donc les industriels, il y a de fortes chance qu'intel sache ce qu'ils attendent (un truc plus léger, plus facile à embarquer, qui consomme moins?).

                      • [^] # Re: Pour une transition douce depuis wayland

                        Posté par (page perso) . Évalué à  1 .

                        • [^] # Re: Pour une transition douce depuis wayland

                          Posté par . Évalué à  2 .

                          Donc c'est bien les devices, c'est à 4mn dans la vidéo.

                          • [^] # Re: Pour une transition douce depuis wayland

                            Posté par (page perso) . Évalué à  1 .

                            Ben oui, j'ai pas remarqué autour de moi que Linux était partout sur le desktop :-)

                            • [^] # Re: Pour une transition douce depuis wayland

                              Posté par . Évalué à  9 .

                              linux sur le desktop = noyau linux + X
                              linux sur les devices = noyau linux + un autré mécanisme
                              conclusion: ne pissons pas contre le vent en essayant d'adapter X à ces nouveaux usages à cause de sa complexité inadaptée, développons un nouveau mécanisme adapté à ces nouveaux usages.
                              conclusion personelle: vu les emmerdes à travers lesquelles KDE et GNOME et maintenant UNITY veulent nous faire passer pour s'adapter aux nouveaux usages (les tablettes), je te dis pas la merde que ça va être quand c'est le système graphique tout entier qui va être refait et rerefait régulièrement. Rajouter par dessus une couche de drivers graphiques à des états de fonctionnement différents et bonjour l'angoisse.
                              Note pour plus tard: prendre une distro conservatrice pour pulseaudio a plutot bien marché, faire pareil pour éviter wayland pendant 2 ou 3 ans.

                • [^] # Re: Pour une transition douce depuis wayland

                  Posté par (page perso) . Évalué à  5 .

                  D'après la conférence au Fosdem, un des problèmes, c'est que X n'est plus utilisé pour ce pour quoi il a été prévu. Par exemple, il était prévu que chaque périphérique ait son propre pilote, maintenant tout le monde utilise evdev. On arrive aussi à des situations où les développeurs d'applications doivent utilisé une fenêtre de X pour chacun de leur widget dans la fenêtre (pour éviter que toute la fenêtre soient redessinée à chaque modification du widget). Ce n'est pas vraiment optimal.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: Pour une transition douce depuis wayland

                    Posté par . Évalué à  5 .

                    Par exemple, il était prévu que chaque périphérique ait son propre pilote, maintenant tout le monde utilise evdev.

                    Oui, X (ré)implementait beaucoup de chose pour maximiser la portabilité, à l'inverse Wayland est actuellement Linux-only.
                    Pas sûr que je considère ça comme un point fort pour Wayland!

                    On arrive aussi à des situations où les développeurs d'applications doivent utilisé une fenêtre de X pour chacun de leur widget dans la fenêtre (pour éviter que toute la fenêtre soient redessinée à chaque modification du widget).

                    Il y a une extension XDamage pourtant?

                    Note bien que personne ne dit qu'X est optimal, par contre passer de X11 à Wayland plutôt que de faire un X12, hum: on n'a pas jeter X quand l'extension "shared memory" a été créer, je ne vois pas en quoi l'ajout de "shared GPU memory" (ce que fait Wayland en fait) serait fondamentalement différent..

                    • [^] # Re: Pour une transition douce depuis wayland

                      Posté par (page perso) . Évalué à  1 .

                      par contre passer de X11 à Wayland plutôt que de faire un X12

                      Sauf que personne ne veut faire d'X12 parce que ce serait beaucoup trop de travail. Alors qu'il est plus simple de repartir de zéro tout en réimplémentant les fonctionnalités intéressantes (par exemple, la transparence réseau, même si ça ne sera pas là tout de suite).

                      Je pense que si quelqu'un se lançait dans le développement de X12 avec un résultat aussi rapide que Wayland tout en offrant les mêmes fonctionnalités, Wayland ne décollerait tout simplement pas. Seulement, ça n'intéresse personne.

                      (ce que fait Wayland en fait)

                      Il fait bien plus que ça, ce n'est qu'un effet collatéral.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: Pour une transition douce depuis wayland

                        Posté par . Évalué à  1 .

                        Il fait bien plus que ça, ce n'est qu'un effet collatéral.

                        Hum, pour moi c'est la raison principale pour laquelle Wayland devrait être plus performant qu'X (l'autre raison étant la fusion des serveur, gestionnaire de fenêtre et compositeur dans un même processus), alors appeler ça un effet collatéral me parait "un peu court".

                        • [^] # Re: Pour une transition douce depuis wayland

                          Posté par (page perso) . Évalué à  2 .

                          J'appelle le multi-gpu un effet collatéral parce qu'il n'a pas été prévu pour ça à la base mais son architecture le permet.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                          • [^] # Re: Pour une transition douce depuis wayland

                            Posté par . Évalué à  2 .

                            On ne parle pas de la même chose, ce que j'appelais "shared GPU memory", c'est que dans Wayland ton application fait son rendu directement dans la mémoire du GPU puis passe une référence vers ce buffer (qui reste donc dans la mémoire du GPU) au compositeur, donc le client et le compositeur se partage la mémoire du GPU.

                            Le support du multi-GPU par Wayland c'est effectivement un effet collatéral, un bénéfice de la jeunesse de Wayland.

                  • [^] # Re: Pour une transition douce depuis wayland

                    Posté par . Évalué à  4 .

                    Je doute quand meme qu'il y ait encore beaucoup de toolkit moderne qui fasse ca, c'est tout de meme assez peu efficace. Je pense pas me tromper en disant que au moins Qt avec son scenegraph et les EFL avec Evas ne fonctionne absolument plus comme ca depuis quelques temps.
                    La technique utilise par tous les toolkits moderne consiste a ne plus utiliser X pour autre chose que uploader des pixels deja calcule et non utiliser les primitives graphique de X qui sont limite et peu rapide. Et ces toolkits fonctionneront exactement de la meme maniere avec Wayland, donc il n'y aura pas de changement de ce cote la.

                    • [^] # Re: Pour une transition douce depuis wayland

                      Posté par (page perso) . Évalué à  2 .

                      C'est vrai que maintenant que tu le dis, ça me revient. Il avait expliqué que Wayland fonctionnait comme les applications utilisent X actuellement.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  8 .

          Etant donnee les benchmark frame buffer vs X, j'ai un gros gros doute sur cette solution miracle. Il y a des marges de gains de performance phenomenale dans les toolkit graphiques, bien plus importante que ce que l'on pourrait potentiellement gagner avec un passage a Wayland. Avoir un toolkit avec un pipeline de rendu asynchrone et multi threade permet d'avoir des gains, meme en OpenGL de 70%. Alors que la difference entre X et le frame buffer, ca reste inferieur a 5%.
          De la meme maniere, faire demarrer X plus vite lorsque c'est gdm ou lightdm qui prend le plus de temps au demarrage, ca va clairement pas aider grand chose. Wayland est une amelioration, c'est certain, mais ce n'est pas ca qui va changer la face du monde en terme de performance. Les gains pour un toolkit moderne et optimise seront dans les 5% grand max. Pas de quoi en faire un fromage.

      • [^] # Re: Pour une transition douce depuis wayland

        Posté par (page perso) . Évalué à  3 .

        Je crois me souvenir que ça permettra également de manipuler facilement différentes cartes graphiques (par exemple, accélération via le CPU / accélération via le GPU). Alors que pour le moment, il faut recourir à des bidouilles immondes pour avoir cette gestion.

        Je crois que le principal mérite de Wayland est de faire table rase du passé tout en bénéficiant de l'expérience acquise afin de proposer un service qui répond aux besoins modernes.

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  3 .

          En fait, avec wayland, il devrait etre possible de gerer les overlay de maniere plus efficace. Cela peut etre tres interressant sur un systeme embarque ou Wayland pourra decider de donner un plan graphique a une application qui prend tous l'ecran et est tres active. De cette maniere, le compositeur n'aura plus a faire le compositing, car la tache sera faire en hard et le systeme consommera moins de batterie. Il y a sur les SoC souvent 4 ou 5 overlays qui sont automatiquement mixe ensemble sans passer par le GPU et en consommant moins de batterie. Ils peuvent servir de maniere transparente a de la video ou a du graphisme. Ils ne peuvent pas par contre etre deforme ou subir de rotation, juste etre positionne verticalement et horizontalement.

          Avec un bon driver, on peut meme imaginer qu'une application puisse etre migre dynamiquement d'un overlay au GPU et vice et versa en fonction de l'activite et des animations a afficher. Le tout pour minimiser la charge cote compositeur et donc consommer moins de batterie infine. Wayland est veritablement concu pour resoudre les problemes de l'embarque et etre utilise dans des scenario qui n'ont jamais ete envisage a la creation de X.

      • [^] # Re: Pour une transition douce depuis wayland

        Posté par . Évalué à  3 .

        Petite question : En tant qu'utilisateur, est-ce qu'il y a une différence majeure entre wayland et Xorg ?

        Une différence majeure: X est présent sur tout les Unix, wayland ne sera pour le moment disponible que pour Linux.

        Sinon dans certains configuration (rendu de la fenêtre entièrement par l'application) Wayland devrait permettre de redimensionnement une fenêtre sans "tearing", pour certains c'est une différence majeure (ils doivent passer leur temps a redimmensioner leurs fenetres!!), note que cette configuration n'est pas sans inconvénient potentiel: si une application est occupée, elle peut mettre du temps à répondre a une demande d'iconification ou de fermeture..

        Note que la configuration rendu client uniquement n'est pas celle choisie par le projet KDE: http://blog.martin-graesslin.com/blog/2011/08/kwin-at-desktop-summit/

        • [^] # Re: Pour une transition douce depuis wayland

          Posté par . Évalué à  2 .

          Euh, je suis sous X et je n'ai pas de tearing. Le tearing apparait lorsqu'il n'y a pas de prise en compte de la synchronisation verticale. Normalement, ton compositeur graphique, si il utilise OpenGL et qu'il demande la synchro verticale, faira que tu n'auras pas de tearing.

  • # Support de Wayland seulement sur les Fermi ?

    Posté par (page perso) . Évalué à  4 .

    En tant que dev nouveau, je suis étonné de voir que le support de wayland sur les geforce 8+ n'est pas disponible.

    Il me semble bien que ca marche, j'avais teste ça il y a un an. Quelle source dit que Wayland ne tourne pas sur toutes les cartes récentes ?

    Sinon, pour le driver Lima, l'impulsion vient de Luc Verhaegen, pas de codethink qui fourni "uniquement" une source de financement si je me souviens bien.

    Quoi qu'il en soit, il faut espérer que ARM prenne le support du driver à sa charge.

  • # Poulsbo ou Poulspabo

    Posté par . Évalué à  1 .

    J'ai un netbook en Poulsbo, et je confirme l'horreur que c'est. Déjà j'ai l'impression que le pilote change de nom tous les ans, et repart de zéro... Avant on était en psb-gfx, puis on est passés en emgd, et là on repasse en psb-gfx.

    Et le pire est que ça ne marche toujours pas.

    • [^] # Re: Poulsbo ou Poulspabo

      Posté par (page perso) . Évalué à  4 .

      Depuis que j'ai écrit mon article fin 2009, ça a pas mal bougé avec le gros travail d'Alan Cox sur le pilote gma500.
      https://linuxfr.org/news/intel-ne-maintient-plus-le-pilote-linux-poulsbo-depuis-un-an-et

      Ce pilote évoque petit à petit au fil des versions du noyau Linux. Le pilote quitte d'ailleurs le dossier "staging" pour entrer dans le noyau officiel dans la version 3.3 (en cours de développement).
      The GMA500 graphics driver for Intel's US15W and some Hyper V drivers have matured in the staging area and were moved to the subsystems responsible for these kind of drivers.
      http://www.h-online.com/open/features/Kernel-Log-Linux-3-3-goes-into-testing-1418516.html

    • [^] # Re: Poulsbo ou Poulspabo

      Posté par (page perso) . Évalué à  1 .

      J'ai aussi un "poulsbo", et il marche très bien avec les drivers inclus dans Mandriva 2010. Et les performances, y compris en 3D, sont plutôt satisfaisantes surtout ramenées à la faible consommation.

      Pour ce que j'en sais, ce driver est libre et open source, et provient en fait des sources de Moblin. Seulement, il n'y a personne pour le maintenir...

      Du coup j'ai gardé ces "vieux" drivers et la version de X qui va avec et mis à jour le reste de la distribution (vers Mageia).

  • # Wayland vs le monde propriétaire

    Posté par . Évalué à  10 .

    Je n'y connais rien en pile graphique, mais j'ai une question.

    Comment se positionne Wayland par rapport au monde proprio ?
    Est-ce que le paradigme de Wayland est le même sur les autres systèmes (MacOS X et Windows) ?

    Si j'ai bien compris Wayland se contente de récupérer les buffers des différentes applications et les passe au Compositeur lorsqu'ils sont prêts. Quelle est la différence avec les piles graphiques des autres systèmes actuellement sur le marché ?

    • [^] # Re: Wayland vs le monde propriétaire

      Posté par . Évalué à  1 .

      Si j'ai bien compris Wayland se contente de récupérer les buffers des différentes applications et les passe au Compositeur lorsqu'ils sont prêts. Quelle est la différence avec les piles graphiques des autres systèmes actuellement sur le marché ?

      Non. X récupère les buffers et les file au compositeur. Wayland est un protocole qui permet aux applis de filer directement l'adresse des buffers au compositeur.

  • # Wayland 1.0 en 2012 ?

    Posté par (page perso) . Évalué à  5 .

    Wayland 1.0 prévu la première moitié de 2012, rien n'est moins sûr... Durant sa présentation, Kristian Høgsberg avait dit cela avant d'être corrigé par une autre personne de l'équipe, qui parlait plutôt de début 2013... Après j'ai peut être mal compris et c'est peut être le protocole Wayland en 1.0 avant mi-2012, mais l'implémentation de référence, Weston, ne sera pas en 1.0 avant 2013. Dès que les vidéos du FOSDEM seront en ligne, ce sera plus simple.

    Edit:
    Vu dans le forum Phoronix de l'article en question:

    I thought he said, they will freeze the 0.85 api now(ish), release a 0.90 (aka 1.0 beta) pretty soon, followed by an 0.9x release candidate a few months later and a 1.0 around late 2012/ early 2013, despite the slides stating otherwise.

    Et un autre utilisateur:

    I confirm that he said 1.0 would be released in late 2012 or early 2013.

    A la décharge de Phoronix, mi-2012 était la date sur les diapos, début 2013 à été communiqué à l'oral pendant sa présentation.

    • [^] # Re: Wayland 1.0 en 2012 ?

      Posté par (page perso) . Évalué à  4 .

      Pour ceux qui veulent, la vidéo de la présentation est là ici en webm

    • [^] # Re: Wayland 1.0 en 2012 ?

      Posté par . Évalué à  3 .

      Tant que les principaux desktop n'auront pas implemente le support pour Wayland, on ne pourra clairement pas dire que c'est une version 1.0. Il faut valider l'API et le protocol en utilisation reel.

      Vu la jeunesse de Wayland, je pense effectivement que 2013, n'est vraiment pas deconnant comme date. Il y a beaucoup de boulot pour passer du prototype a un remplacant potentiel de X. Et aujourd'hui, on est encore bien plus proche du prototype que du remplacant...

      • [^] # Re: Wayland 1.0 en 2012 ?

        Posté par (page perso) . Évalué à  2 .

        Le but de la version 1, ce n'est pas de dire que tout sera porté mais de stabiliser les API (c'est-à-dire qu'on ne retire ou ne modifie le comportement de rien (sauf cas exceptionnel évidemment), les version 1.x apporteront uniquement des nouvelles fonctions à l'API. Ça permettra d'encourager le portage des applications

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Wayland 1.0 en 2012 ?

          Posté par . Évalué à  3 .

          C'est bien ce que je dis. La version 1.0 n'est possible que si tous les toolkits principaux et les composite manager sont porte. Avant ton API, tu ne peux pas etre sur qu'elle est correcte, generique et couvre tous les use case de tout le monde.

  • # "Wayland - Beyond X" sur http://www.h-online.com

    Posté par (page perso) . Évalué à  5 .

  • # Meurs Poulsbo, meurs !

    Posté par (page perso) . Évalué à  2 .

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.