Martin Peres a écrit 413 commentaires

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.

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.

le backend soft comprend le format du GPU

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.

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.

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…

La grosse amelioration de Wayland, c'est surtout le control du buffer video par l'application.

C'est en effet la seule modification, mais de taille.

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.

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!

Cela évite le memcpy inutile.

Tu auras toujours un blit à faire, ça change pas grand chose à part que le buffer ne peut pas être en VRAM.

Mais techniquement, il n'y a rien la dedans qui ne serait pas impossible a faire avec X.

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.

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.

Ç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.

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).

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.

Avec Wayland, toutes les applis utiliseront l'équivalent de DRI2.

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.

Oui, en effet. Pour être honnête, j'avais zappé cette amélioration :)

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).[coupé] Plus de sérialisation du rendu, plus d'utilisation d'un toolkit 2D très limité (X11/XRender).

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?

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 :)

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! :)

C'est cool de se voir cité :)

Pour information, on refera une présentation à la FOSDEM sur la sécurité de la pile graphique.

Euh comme je le mettais, la plupart des langages ayant un GC "stop the world", avoir une thread dédié a l'affichage n'est pas suffisant à moins de désactiver (enfin au moins partiellement) le GC en début de redimensionnement ce qui parait assez raisonnable..

Oui, c'est un comportement possible. Je comprend mieux ta remarque sur le GC "temps réel".

Mais pour troller un peu, je dirai juste que ça ne rendra pas les applications Java plus mal intégrées qu'elles ne le sont déjà par défaut ;)

Avec X, le redimensionnement est toujours lent alors qu'avec Wayland, il est vraiment plus rapide à moins que l'appli soit bloquée.

Certes, mais l'être humain aime la régularité: être uniformément lent est mieux accepté que rapide-lent-rapide.

Le coup du GC, c'est totalement valide. Comme tu disais, ça va forcer les applications à pas faire les connes et à avoir un thread dédié à l'affichage.

Merci pour le retour.

Ça veut dire quoi loin de la gaulle? J'hésite à redonner une conf comme ça à la FOSDEM cette année. Sinon, pour la vidéo de 3h, le son m'avait paru bon. Je vais voir pour augmenter le volume des 2 vidéos et écouter pour plus pour comprendre où est le problème).

Le journal a été publié trop tôt et j'ai pas eu le temps de retoucher l'audio…

? La 2D étant un cas particulier de la 3D, je ne comprends pas trop ce que tu veux dire par là..

En hardware, la 2D est en effet un cas particulier de la 3D. Dans X, ça n'a rien à voir car la 2D est accélérée par le DDX qui accélère seulement quelques opérations nécessaires à XRender.

Dans tout les cas, je ne vois pas trop pourquoi tu insiste sur la 3D: l'utilisation normale de Wayland(*) (comme DRI2 d'ailleurs) c'est le partage de buffer dans la mémoire vidéo du GPU entre un client et le serveur d'affichage, quel rapport entre les interfaces 2D ou 3D pour dessiner dans ces buffers?

Dans Wayland, plus de différence entre une appli 3D et 2D. Les 2 font ce qu'elles veulent. Elles doivent juste présenter le contenu des fenêtres "à la DRI2". Dans X, c'est pas du tout le même chemin. Quand tu fais de la 2D, tu passes par X -> ddx -> (mesa) -> libdrm -> GPU -> compositeur. Pour la 3D, y'a plusieurs cas. Soit tu accèdes à mesa en direct rendering et dans ce cas là, tu as globalement, application -> mesa -> libdrm -> GPU -> compositeur. Si tu es en indirect rendering, tu passes par X et AIGLX entre application et mesa (oui, c'est le bordel).

Il n'y aura plus d'interface d'accélération 2D totalement dépassée.

Oui, euh j'aimerai bien mais certains pilote propriétaire ne fournissent une interface accélérée que pour la 2D, pareil pour la virtualisation donc 'dépassée', ça dépend beaucoup de la situation!

Comme t'as déjà répondu Xavier Claude, c'est l'interface qui est dépassée, pas l'accélération 2D.

Mais ce n'est pas fini. Wayland simplifie aussi la gestion des fenêtres et promet un redimensionnement pixel-perfect!

C'est un avantage en effet, mais je trouve dommage de ne pas préciser le prix a payer: si le client est lent à fournir une fenêtre l'animation peut être "saccadée" alors que si le redimensionnement est fait par le serveur d'affichage on a juste le contenu qui est moche quand le client est lent..
Après, paradoxalement, ça peut être perçu comme un "avantage" car ça pousse une conception "à la BeOS" ou chaque client a (au moins) un thread dédié à la fenêtre, m'enfin d'ici que ce design se réalise (*SI* il se réalise) on aura des animations saccadées par moment, bof c'est cher comme prix à payer..

Avec X, le redimensionnement est toujours lent alors qu'avec Wayland, il est vraiment plus rapide à moins que l'appli soit bloquée. Cela dit, même dans X, quand une appli est bloquée, ça te fait pas quelque chose d'utilisable. Alors faut pas confondre features et habitudes ;) Personnellement, je préfère voir le dernier buffer valide qu'un tas informe de pixels tel qu'on a dans X.

Je te conseille de faire un test. Redimensionne une appli dans X et regarde le décalage moyen entre, ton curseur, la fenêtre telle que présentée par le compositeur et ce que l'application a véritablement rendu. Refait le test dans Wayland et regarde la différence :)

Alors, je suis totalement d'accord sur le fait que DRI2 et Wayland sont très proches. Cela dit, DRI2 c'était seulement pour le rendu d'applications 3D. Pour la 2D, tu passes toujours par XCB/XLib donc, pour accélérer le rendu, tu dois soit envoyer les commandes X11/XRender soit rendre toi même le buffer et l'envoyer via la XLib. Pour info, c'est ce que fait Qt en mode raster et c'est plus rapide que le mode X11 alors que ça tourne sur le CPU.

Avec Wayland, les applis GL et 2D seront traitées pareillement. Il n'y aura plus d'interface d'accélération 2D totalement dépassée. Les applications utiliseront l'API de rendu qu'ils désirent. Dans les faits, ça sera probablement cairo/cairo-gl.

Mais ce n'est pas fini. Wayland simplifie aussi la gestion des fenêtres et promet un redimensionnement pixel-perfect! En demandant au client d'être responsable de son propre buffer, Il n'y a plus besoin d'autant de synchronisation entre le serveur X et Wayland tel que c'est le cas actuellement. Pour information, il se dit qu'il y aurait une dizaine d'échange de message entre X et un client X lors du redimensionnement. C'est dû au fait que le serveur X est responsable de maintenir la taille du buffer dans lequel l'application doit rendre.

Donc, pour résumer, on devrait pas voir d'amélioration significative des perfs dans Wayland pour la 3D, mais le gestionnaire de fenêtre devrait être plus réactif ainsi que les applications qui peuvent du coup utiliser l'API optimisée pour leurs besoins (et pas un API inventée il y a 25 ans pour le besoin des mainframes).

Ça te va?

Aucun. C'était un problème du serveur http d'octopress qui faisait pas bien son boulot.

Du coup, j'ai uploadé les vidéos en mp4 mais du coup, j'ai pas augmenté le volume sonore (j'avais rajouté 6dB pour rendre le son plus audible par défaut). Je renverrai les vidéos demain depuis le boulot (vive les connexions 100MBit) avec le son augmenté mais sans modification de la vidéo.

Merci Thomas!

Je suis en train de transcoder les vidéos en webm pour les mettre sur ma page recherche. Le mp4 est pas génial pour le seeking.

Ah ah, merci Patrick :D

Du coup, je crois qu'on pourra poster une dépêche quand les vidéos seront disponibles.

Je pense qu'il voulait parler de l'ABI avec l'espace utilisateur. Pas l'ABI interne qui n'est en aucun cas stable.

Une solution pour ça serait par exemple d'autoriser le changement de l'ABI uniquement tous les x kernels ou une fois par an. Pour pas empêcher le développement de certains projets, faudrait que seulement certaines parties soient considérées comme stables. Typiquement, ça serait les parties qui sont des dépendances de drivers propriétaires ou plus généralement, "out of the tree".

Je n'ai personnellement aucun besoin d'avoir une ABI stable mais je peux comprendre que ça gène certains. Cette gène est peut-être aussi bénéfique car elle pousse les constructeurs à contribuer upstream si ils ne veulent pas continuellement porter leur code.

Question bête : sur une carte (une 8800 gt en occurrence) où le ventilo d'origine à été remplacé par un système passif, est-ce-qu'utiliser le pilote nouveau peut être risqué ?

Non, pas du tout risqué ;)

et c'est quoi tes outils ?

Ils sont ouverts. Il y a tout d'abord les mmiotraces qui permettent d'espionner ce qui passe par le port PCIE puis il y a valgrind-mmt qui permet de tracer tous les appels systèmes fait pour une application puis de tracer l'utilisation des buffers graphiques. On a aussi nvafakebios qui permet d'envoyer un bios modifié sur la carte sans flasher la ROM. Pour le reste, je te conseille d'aller voir la liste des programmes que l'on a dans le dépôt envytools.

Ma carte chauffe carrément moins, le ventilo est bien mieux géré (j'ai ENFIN un pc silencieux)

Hmm, on a pas encore de gestion du ventilateur. Je te conseille de regarder la température de ta carte ($ sensors) avant qu'elle ne fasse une combustion spontanée.

Pareil pour moi: Archlinux, et openarena se lance bien mais j'ai un écran noir

je serai bien intéressé par ton install. Ça me semble étonnant quand même. Tu peux mettre sur pastebin la sortie de "$ LIBGL_DEBUG=verbose glxinfo"? Je doute que nouveau-dri soit installé/utilisé.

C'est Flash qui a accès à X, pas les applis Flash.

J'avoue qu'avec le nombre de failles dans ce genre d'applis (Flash, Java), j'ai du mal à faire la différence ;)

Demander au userspace de faire de la sécurité, c'est se tirer une balle dans le pied. Je préfère l'approche du sandboxing de chrome. Demander au kernel de dropper des privilèges pour toujours!

Non c'es sandboxé.

Par qui? Pas par chromium/firefox car Flash peut accéder à VDPAU pour faire de l'accélération vidéo ;)

Ça veut dire que n'importe quelle application malicieuse (y compris une saloperie en flash ?) peut avoir accès à toutes les entrées clavier et les sorties écran n'importe quand ?

Rien ne l'empêche dans X et dans le kernel en tout cas. Le seul contrôle existant est trop large.

Le travail de retro-engineering sur des drivers proprio doit être quelque chose de très complexe, et cela m'épate que l'on puisse y arriver !

C'est pas complexe du tout quand on a les bons outils. Par contre c'est lent et très ennuyeux si on aime pas les challenges ;)

Donc tes avancées devraient au contraire lui être plus qu'utiles !

Comme tu dis, dans le futur ça sera utile! On y arrive ;)

j'oubliais dans les paquets installés : libgl, et xf86-video-nouveau

Hey hey, il te manque nouveau-dri pour avoir l'accel 3D. Actuellement, tu utilises ton CPU (swrast ou llvmpipe), donc ça ira pas vite :)

Pour vérifier, tu peux faire: glxinfo | grep "OpenGL vendor string".