Sommaire
Voici un journal un peu bizarre : je crois avoir l’idée de projet libre qui tue, mais je n’ai pas le temps de l’exécuter moi‐même ! Alors la voici, dans l’espoir que quelqu’un la prenne…
Un peu de contexte
L’idée est de mettre au point un nouveau type de serveur d’affichage, donc un remplacement de (la partie affichage de) X ou de Wayland.
Le serveur d’affichage est la partie d’un système d’exploitation qui a le monopole de l’écran. Il permet à des clients (des applications GUI par exemple) d’afficher des informations à l’écran.
Les serveurs d’affichage traditionnels (ceci inclut X et Wayland) fonctionnent sur le principe du framebuffer. Chaque fenêtre soumet un gros bitmap qui représente son contenu. Le serveur d’affichage se charge de les porter à l’écran, généralement en utilisant un compositeur.
Pour éviter des bugs graphiques si une fenêtre change son contenu pendant que le compositeur le porte à l’écran, on a recours a du multi‐buffering : chaque fenêtre dessine dans un premier framebuffer appelé le backbuffer, puis le soumet au serveur d’affichage, dans une file (FIFO) de framebuffers, dont le dernier, appelé frontbuffer, est porté à l’écran. La longueur de la file varie, en fonction du compromis voulu entre latence et fluidité : typiquement 3 (triple buffering), mais jusqu’à une dizaine pour un pipeline vidéo.
Ce modèle a des avantages : une certaine simplicité, une stricte séparation du code graphique entre les applications et le système d’exploitation. Mais il a aussi des inconvénients.
Un problème : la latence
Le plus gros inconvénient est qu’il peut s’écouler un certain temps entre le moment où une fenêtre met à jour son contenu, et le moment où ce contenu apparaît à l’écran. On appelle ça la latence.
Récemment on a vu émerger de nouveaux pipelines plus complexes qui viennent se superposer à l’existant. Par exemple, les pages Web sont devenues si complexes, consistant en de nombreuses couches, que le navigateur doit exécuter son propre compositeur pour obtenir le rendu final de sa fenêtre, avant de la présenter au serveur d’affichage. On a ainsi deux systèmes superposés, ce qui double la latence d’affichage !
Dans le cas de pipelines complexes, par exemple une page Web utilisant WebGL dans un navigateur a exécution distante de commandes graphiques comme Chrome, la latence peut facilement excéder un frame. Ainsi l’utilisateur voit toujours un frame en retard ! Ce qui peut suffire à rendre une plateforme comme le Web non compétitive pour certains types d’applications (jeux en 3D rapides).
Un autre problème : la fluidité d’animation
Les « vieux » parmi nous nous souvenons de la fluidité saisissante des animations ce certains anciens jeux vidéo qui programmaient directement le CRTC (les programmeurs d’Epic Pinball avaient bien réussi leur coup !). Plus près de nous, difficile de ne pas voir que les animations paraissent parfois plus fluides dans un jeu en plein écran que dans une fenêtre, ou dans un jeu natif plutôt que dans un jeu WebGL, ou sur une console de jeux plutôt que sur un PC. Il y a une bonne raison à tout ça, et ça nous amène un peu plus près de ce dont je veux parler.
La fluidité apparente d’une animation dépend de plusieurs facteurs. On parle souvent de framerate, le nombre d’images par seconde, mais le cerveau humain ne mesure pas un nombre d’images par seconde. Ce qui compte vraiment, c’est que la trajectoire réelle de l’image à l’écran soit régulière. Avoir un bon framerate est une condition nécessaire, pas suffisante. Il faut aussi que l’application positionne correctement les éléments animés par rapport à la date réelle où l’image sera portée à l’écran.
Le problème est bien entendu que la date d’affichage à l’écran peut être très différente de la date de rendu par l’application… la différence entre les deux est la latence dont nous avons parlé plus haut !
Si cette latence est parfaitement constante, l’animation devrait quand même paraître fluide. Mais si la latence est variable, ce qui devient inévitable avec la complexité des applications d’aujourd’hui, il peut être impossible pour l’application de présenter une animation vraiment fluide ! Avec des systèmes de plus en plus complexes (WebGL est un exemple), on est de plus en plus dans ce cas de figure. Les navigateurs tentent de compenser en fournissant au requestAnimationFrame callback une date faussée, pour compenser. Mais ce calcul est bien difficile et bien fragile, et le résultat est rarement parfait.
Encore un autre problème : gâchis de bande passante mémoire
Prenez un jeu en 3D. D’un frame au suivant, la scène est presque la même, mais tous les pixels ont légèrement changé de couleur : il faut redessiner un nouveau framebuffer, et lui faire traverser à nouveau tout le pipeline. Serait‐il possible d’imaginer un système où ce qui doit traverser tout un pipeline est quelque chose qui change moins d’un frame au suivant ? D’autre part, un framebuffer est gros : typiquement 10M aujourd’hui. Pourrait‐on espérer avoir un modèle où ce qui traverse tout le pipeline à chaque frame est un objet plus compact ?
Un problème plus abstrait : empiètement entre deux systèmes client‐serveur entrecroisés
Un paradigme client‐serveur tel que celui du serveur d’affichage a tendance a bien marcher tant que tout le système obéit à son modèle. Mais il y a environ 20 ans, quelque chose a commencé à changer :
OpenGL (de même que Direct3D) s’est popularisé vers 1996, et est lui aussi un système client‐serveur. Ici, le serveur est le pilote OpenGL qui a le monopole de la carte graphique (tandis que le serveur d’affichage a le monopole de l’écran), et le client est tout processus émettant des commandes OpenGL. Ainsi on a deux systèmes client‐serveur entrecroisés :
1 - clients = processus appelant OpenGL, serveur = pilote OpenGL
2 - clients = fenêtres des applications, serveur = serveur d’affichage
Sans rentrer dans les détails, cette situation transforme le paradis originel que devaient être les serveurs d’affichage en un enfer de complexité pour les applications qui ont besoin d’interagir efficacement dans les deux systèmes. Certains cas courants sont bien pris en charge (un jeu en 3D) mais dans le cas d’un navigateur Web, devoir jongler entre ces deux paradigmes cause beaucoup de complexité.
L’idée !
Voici l’idée que je voudrais voir quelqu’un qui a le temps, mettre en œuvre.
En une phrase, pour ceux qui connaissent : il faut inventer un nouveau type de serveur d’affichage où la communication entre client et serveur se fait non plus en termes de framebuffers mais en termes de command buffers.
Explication
Une évolution récente des API graphiques (Vulkan, Direct3D 12, Mantle, Metal…) est de permettre à l’application d’assembler des command buffers, représentant un ensemble de commandes graphiques susceptibles d’être exécutées plus tard. Jusqu’à présent, les API graphiques géraient ceci de façon implicite : les appels étaient bien asynchrones, mais l’application n’avait pas de contrôle là‐dessus.
Certaines applications comme Chrome n’ont pas attendu ces nouvelles API pour mettre en œuvre ce genre d’idées : dans Chrome, chaque processus assemble des command buffers puis les envoie à un GPU process pour être traduit en vraies commandes OpenGL, ce qui permet de centraliser les commandes graphiques dans un seul processus, ce qui est un moyen de contourner plusieurs limitations de OpenGL.
Les successeurs d’OpenGL, comme Vulkan, généralisent cette idée de command buffers. L’idée est de rendre explicite, sous le contrôle de l’application, l’idée que les commandes graphiques sont généralement exécutées plus tard qu’elles sont assemblées.
Ci‐dessus, quand nous parlions de latence, le problème était justement que les commandes graphiques sont exécutées trop longtemps en amont de leur affichage réel à l’écran.
Tant que le serveur d’affichage exige que chaque fenêtre lui présente un framebuffer déjà finalisé, ce problème est inévitable.
Alors, peut‐on envisager un autre système, où le serveur d’affichage recevrait de la part de chaque un autre type d’objet qu’un framebuffer ? Que serait ce type d’objet ?
… un command buffer, pardi !!!
Ainsi, les applications n’exécuteraient plus leurs propres commandes graphiques. Au lieu de ça, elles les communiqueraient sous forme de command buffers au serveur d’affichage qui
Il s’agit du coup bien entendu d’un projet très lourd, qui supposerait d’écrire un remplacement de X/Wayland, et qui demanderait aux applications et toolkits d’êtres adaptés !
Ce qui me fait espérer que ce projet ait quand même une chance de réussir, c’est qu’il offrirait des avantages uniques, bien visibles pour l’utilisateur.
Avantage : latence minimale
Cet avantage est une conséquence immédiate du modèle ! En différant l’exécution des commandes graphiques à la dernière minute dans le serveur d’affichage lui‐même, on minimise la latence entre ce moment et celui où l’image atteint l’écran.
Bien entendu, il faut que l’application soit bien écrite pour en tirer partie : concrètement, il faut que les vertex shaders, qui positionnent les objets à l’écran, lisent une date fournie dans une variable par le système d’affichage lui‐même, pour adapter le positionnement des objets graphiques à cette date « tardive ».
Avantage : fluidité quasi‐parfaite
C’est probablement ce qui sauterait aux yeux si on avait une démo d’un tel système. Le système décrit ci‐dessus, où les vertex shaders positionneraient les objets en fonction d’une date fournie par le serveur d’affichage lui‐même, résout le problème de fluidité en donnant intrinsèquement des dates très proches de la date réelle d’affichage à l’écran, et, encore plus important, avec une latence quasi‐constante car tout désormais se passe du même côté, dans le serveur d’affichage.
Avantage : bande passante mémoire
Un command‐buffer est typiquement bien plus compact en mémoire que le framebuffer qui est son résultat, donc ce serait plus économique d’avoir un pipeline de command‐buffers qu’un pipeline de framebuffers.
Encore mieux : typiquement, même un jeu 3D rapide peut être structuré pour que les command buffers restent presque identiques d’un frame au suivant. On pourrait donc imaginer un système de mises à jour partielles qui réduirait encore plus le coût.
Avantage plus abstrait : simplification des grosses applications et frameworks
Ceci fait écho au problème « abstrait » mentionné ci‐dessus. Le code graphique de Firefox lié ci‐dessus, ainsi que le code équivalent dans Chrome, se simplifierait beaucoup si on n’avait pas à gérer des pipelines de framebuffers.
Récemment, on voit aussi des systèmes d’exploitation faire des pas dans cette direction (CoreAnimation dans Mac OS X permet à une fenêtre de présenter une animation au serveur d’affichage). Adopter le paradigme décrit ici permettrait d’offrir une solution aux mêmes problèmes de façon moins ad hoc, demandant moins d’adaptation spécifique de chaque application, couvrant bien plus de cas d’utilisation.
P.‐S. sur la sécurité
Je sais bien que ça ne va pas être évident de rendre cette approche viable question sécurité. Mais, ayant travaillé sur les débuts de WebGL à Mozilla, j’ai l’impression d’avoir déjà vu une situation de ce type. Je vois plusieurs problèmes de sécurité à résoudre et plusieurs façon de les résoudre, mais je ne pense pas que ça soit très utile d’en parler maintenant. Ça serait mettre la charrue avant les bœufs : si on n’avait que des questions de sécurité à résoudre, on serait heureux !
Pour le moment, dans ce projet, on n’a rien du tout, et comme je l’ai dit au début, je n’ai pas le temps de le faire moi‐même en ce moment. J’espère vraiment que ce journal inspirera quelqu’un ici.
Si vous voulez vous lancer, laissez‐moi suggérer un nom pour ce projet : frameless. Un nom plus descriptif serait « framebuffer‐less » mais frameless fait plus court et un peu mystérieux : ira‐t‐on jusqu’à abolir un jour la notion de frame ? Y a‐t‐il une analogie avec un noyau tickless ?
À vous de jouer !
# Vulkan
Posté par NumOpen . Évalué à 2.
Au fait, il y a des implémentations de Vunlkan ?
https://www.khronos.org/vulkan/
[^] # Re: Vulkan
Posté par reno . Évalué à 3.
Non, la spec n'est même pas encore sortie..
[^] # Re: Vulkan
Posté par Plume . Évalué à 2.
Si je ne m'abuse le plan serait d'attendre que les constructeurs aient implémentés des drivers avant de sortir la spec.
[^] # Re: Vulkan
Posté par Davy Defaud . Évalué à 2.
http://www.nextinpact.com/news/98692-la-shield-android-tv-nvidia-passe-a-android-6-0-et-a-vulkan.htm
# La charrue…
Posté par lolop (site web personnel) . Évalué à 10. Dernière modification le 28 janvier 2016 à 08:44.
Sur la sécurité:
AMA si ça n'est pas pensé au moment de la conception, ça sera un nid à emmerdes pour l'ajouter ultérieurement (et très probablement un truc bancale).
Sinon, il me semblait que X11 c'est à la base une API basé sur du RPC… en bref des commandes envoyées par le client vers le serveur d'affichage (le côté "bitmaps" composés étant venu plus tard pour avoir les zolis effets qui plaisent tant).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: La charrue…
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Je n'aurais pas dû mettre ce P.S. alors, car le but était justement d'éviter de laisser ce genre de commentaire faire dévier la conversation. Je ne voulais pas répondre à ce commentaire, mais difficile de faire autrement maintenant qu'il est "Évalué à 10 (+17/-0)".
Il n'y a pas quelque chose de magique dans la sécurité qui fait que c'est toujours sage de faire passer cet aspect en premier. Dans le cas présent, il y a tellement d'inconnues par ailleurs qu'on peut difficilement avoir une conversation précise sur les aspects de sécurité, pour le moment. Et dans la mesure où je vois un peu comment tout ceci pourrait prendre forme, cela ressemble à des situations similaires (en particulier le GPU process dans Chrome) qui marchent bien d'un point de vue de sécurité.
# BeOS le faisait il y a 15 ans!
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Les applications envoient des commandes au serveur graphique, qui se charge de les exécuter et de faire le rendu. C'est comme ça que marche l'app_server de BeOS, et celui de Haiku (sans support de l'accélération 3D pour le moment). Bon, il y a quand même un framebuffer côté serveur. Pour BeOS, le rendu 2d est partiellement accéléré par la carte graphique (copies de blocs, opérations simples comme le tracé de lignes horizontales ou verticales, curseur de souris). Pour Haiku, ce n'est plus le cas: l'"accélération" 2D sur les cartes modernes est tombée en désuétude, et elle est souvent plus lente qu'un rendu par le CPU (et en plus, sans faire d'antialiasing et ce genre de choses). Il faudrait remettre ça en place, peut-être en utilisant OpenVG?
C'est aussi comme ça que X11 devrait fonctionner, sauf que les commandes disponibles (tracé de lignes, de pixels, etc) sont assez limitées (pas de 3D, pas d'antialiasing). Du coup, les toolkits graphiques modernes n'utilisent plus ces commandes et font tout le rendu côté client, avant d'envoyer une grosse image au serveur X.
Pour avoir un serveur X qui marche "normalement", il faut un desktop approprié, utilisant par exemple l'environnement de bureau CDE, et des applications Motif ou Athena ou ce genre de trucs.
En ce qui concerne la notion de "frame", elle est déjà en train de disparaître du côté des écrans avec le DisplayPort, qui n'a plus besoin d'un framerate fixe à 60Hz. ça règle déjà une bonne partie des problèmes (pas de "tearing", en particulier). Donc, il serait logique de faire la même chose côté logiciel.
[^] # Re: BeOS le faisait il y a 15 ans!
Posté par reno . Évalué à 5.
Je ne vois pas le rapport entre la suppression du framerate fixe et la disparition de la "notion de frame"..
[^] # Re: BeOS le faisait il y a 15 ans!
Posté par dinomasque . Évalué à 3.
fuck yeah BeOS !
BeOS le faisait il y a 20 ans !
[^] # Re: BeOS le faisait il y a 15 ans!
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
Bien joué, bien joué, le coup de BeOS le faisait déjà il y a 15 ans. Quand je travaillais dans l'industrie du navigateur, on faisait la blague avec Opera, mais c'était la même chose.
Je suis d'accord avec ton analyse, l'idée générale qu'on envoie des commandes ou au moins quelque chose de structuré au serveur d'affichage existe depuis longtemps.
Ce qui a changé récemment, c'est que le monde des graphismes à bas niveau s'est plus ou moins standardisé autout de l'ensemble de fonctionnalités de OpenGL ES 2 (ou équivalent) comme "lingua franca". Par exemple, quand tu utilises un navigateur Web "moderne", tout ce que tu vois est passé par OpenGL ES 2 ou équivalent. Et comme ces commandes sont de bien plus bas niveau et bien plus généralistes que les primitives 2D à la XRender ou que les "surface trees" acceptés par certains serveurs d'affichage, et contiennent toute leur généralité (par définition, OpenGL représente à peu près ce que peut faire le matériel), on se dit que l'on pourrait rebooter tout ce cercles d'idées, et avoir un serveur d'affichage qui prend des commandes, mais cette fois-ci, des commandes de bas niveau à la OpenGL.
Ensuite, la coïncidence de la sortie de Vulkan qui offre un ensemble de commandes bien nettoyé et un système de command-buffers, rajoute une raison de plus de revisiter ce cercle d'idées aujourd'hui.
Bref c'est comme ça que je suis arrivé à l'idée décrite ici!
# La préemption de la synchronisation inter-buffer
Posté par Clément David (site web personnel) . Évalué à 6.
En regardant le besoin, j'ai trouvé quelques informations sur la façon dont Wayland gère ce cas. En une phrase la conclusion est "I would assume that driver support is required there." donc en ne mettant pas la charrue avant les bœufs il est possible que wayland supporte ce genre d'utilisation plus tard.
Future sync points (Re: Wayland and scheduling) - http://lists.freedesktop.org/archives/wayland-devel/2014-August/016489.html
Trustable Future Sync Points - https://docs.google.com/document/d/1qqu8c5Gp1faY-AY4CgER-GKs0w7GXlR5YJ-BaIZ4auo
# Ouh la
Posté par reno . Évalué à 3.
Pour Wayland c'est vrai, pour X c'est juste un des modes de fonctionnement, j'avais lu qu'il était possible d'avoir un cache des glyphes coté serveur d'affichage et d'afficher donc du texte avec une utilisation minimale de la bande passante.
[^] # Re: Ouh la
Posté par reno . Évalué à 3.
Ta proposition a le même problème que GLX: le client veut pouvoir choisir la version d'OpenGL qu'il utilise ce qui n'est pas simple si c'est le serveur d'affichage qui implémente OpenGL.
s/OpenGL/Vulkan/ dans le texte ci dessus et tu as une des raisons principale pourquoi tu ne peux pas déporter vraiment la gestion de l'accélération matérielle coté serveur d'affichage: ça évolue trop vite.
# Lien rapide avant une réponse plus complete!
Posté par Martin Peres (site web personnel) . Évalué à 9.
Je pense que c'est encore une idée qui sous estime plein de problemes.
J'aime bien cette idée là par contre: https://blog.martin-graesslin.com/blog/2015/12/gaming-on-linux-move-to-next-generation/
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par reno . Évalué à 5.
Bof, tant que c'est optionnel OK, mais dans certain cas tu veux voir les popup, être sûr que le Alt+Tab fonctionne et là sa proposition bof..
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par Benoit Jacob (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2016 à 15:26.
L'idée exprimée dans cet article est de permettre aux jeux en plein écran de contourner le serveur d'affichage. C'est une idée assez classique en soi, ce qui semble etre l'apport nouveau de cet article, c'est qu'il détaille une façon d'y arriver sur le bureau Linux libre actuel, alors que ce n'est a priori pas facile sur X ou Wayland. Mais je pense que cela fait longtemps que certaines plateformes ont des court-circuits pour les jeux en plein écran; je suis un peu surpris d'apprendre que les piles libres X/Wayland n'en avaient pas et je serais encore surpris si le pilote propriétaire NVIDIA n'offrait pas un tel court-circuit. En effet, l'implémentation de OpenGL + la couche d'interfaçage avec le serveur d'affichage (EGL ou GLX par exemple) a toutes les cartes en main pour traiter particulièrement les applications plein écran et décider si besoin de court-circuiter le serveur d'affichage: en fin de compte, c'est bien le pilote OpenGL qui détient les clés de la carte graphique.
Ce type de court-circuit permet effectivement aux jeux en plein-écran d'avoir un contrôle direct de l'affichage et élimine bien tous les problèmes liés au serveur d'affichage. Mais ce type de solution ne se généralise pas au-delà des jeux plein-écran. Les applications en mode fenêtre doivent encore passer par le serveur d'affichage, avec les problèmes qui vont avec. On a donc la situation actuelle, qui n'a pas vraiment changé en 20 ans, où les applications en plein écran marchent magiquement mieux que les applications en mode fenêtre.
L'idée que je propose ici permettrait, à ma connaissance pour la première fois, de généraliser ces avantages à toutes les applications, quel que soit leur type de contenu, et y compris en mode fenêtre, sans avoir à contourner le serveur d'affichage.
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il me semble que les applications opengl attaquent directement la carte graphique. Il y a quelques années, c'était le seul moyen de faire planter un linux : jouer à un jeu 3D avec une carte graphique accéléré.
"La première sécurité est la liberté"
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
C'est l' "entrecroisement" dont je parle dans le journal. Les applications OpenGL utilisent bien directement la carte graphique, au sens où elles communiquent directement avec son pilote. Mais le résultat est traditionnellement un framebuffer, qui va devoir être soumis au serveur d'affichage. A moins que l'application soit plein-écran et que le pilote sache court-circuiter le serveur d'affichage dans ce cas, voir plus haut, ce qui est la raison traditionnelle pour laquelle les applis en plein écran sont plus fluides (sur certains systèmes).
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pas forcément, non, il y a aussi des systèmes qui attaquent directement le hardware en fenêtré. On le voit avec des artefacts comme des rectangles noires ou l'impossiblité de bouger la "fénètre" de l'application.
De toute façon, pour une application opengl, les commandes sont transmises directement au driver, aucun serveur graphique ne traduit les commandes.
"La première sécurité est la liberté"
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Oh, bien sur, on peut toujours avoir des systemes qui poussent le court-circuitage jusqu'a introduire des bugs visibles comme ce que tu decris. Je pensais que l'avenement des compositeurs de bureau avait porte le coup de grace a ces systemes, car les bugs graphiques deviennent particulierement evidents, mais je veux bien croire qu'ils existent encore. Ce que je voulais dire, c'est que l'idee que je propose ici permet pour la premiere fois d'avoir tous les avantage du court-circuitage, en toute generalite meme dans une fenetre, sans aucun cout-circuitage, et donc sans bug.
Le pilote OpenGL est un serveur graphique. Il en faut bien un, pour permettre a plusieurs applications (les clients) d'utiliser OpenGL (le serveur) en meme temps. C'est pourquoi OpenGL se positionne comme un systeme client-serveur. Concretement, quand une application fait un appel OpenGL, ca ne ressemble pas a ceci:
Application -> appel bibli client OpenGL (libGL.so.1) -> syscall ou mmio
mais plutot a ca:
Application -> appel bibli client OpenGL (libGL.so.1) -> construction d'un command-buffer -> plus tard, envoi du command buffer au pilote graphique cote noyau -> mmio
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par cedric . Évalué à 2.
Par design, tu ne peux pas courcicuite X, si tu parles au serveur X :-) Ce que propose Martin, c'est de ne plus faire les round trip avec le serveur wayland ou X. Dans les deux cas, tu as une latence sur l'input et l'output vu qu'ils sont tous les deux gere par le serveur (X et Wayland) avec un peu plus de probleme potentiel avec le serveur X etant donnee que tu peux passer par un compositeur pour l'output.
D'ailleur le seul cour circuit qui existe sur X, c'est le cour circuitage du compositeur pour les fenetres pleins ecran si il l'autorise. Et c'est tout.
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par cedric . Évalué à 5.
Je ne suis pas fan personnellement. La complexite de la gestion du multi ecran, de kms/drm/dmabuff est suffisament eleve pour dire qu'a minima il faudrait avant de pouvoir realiser cela une bibliotheque partageant le boulot (clairement quelque chose que devrait fournir le projet wayland, mais c'est une autre discussion).
Le second probleme que je vois, c'est qu'on repasse en mode cooperatif totalement. Si le jeu n'est pas capable de gerer alt-tab, et bien on reste coince dans le jeu. D'un point de vue securite, c'est juste une potentiel horreur a gerer. On perdrait aussi la possibilit d'avoir un ecran dedie a irc/chat d'un cote et au jeu de l'autre.
Surtout que je ne suis pas convaincu que ce soit un vrai probleme. Si le compositeur ne fait que mettre les buffers gl dans un plan hardware directement, le coup est globalement uniquement sur le switch de context a 60fps. C'est franchement pas la mer a boire pour un PC meme de 10 ans d'age…
# Pas sûr que cela soit efficace
Posté par freejeff . Évalué à 5.
Sur l'aspect transfert de bitmap, je pense qu'on ne peut pas vraiment faire mieux et que surtout cela n'a pas d'intérêt. Pour étayé ce propos voici le fil de ma pensée, X11 savait le faire et pourtant les toolkits graphiques ont choisis de ne pas l'utiliser. Il y a peu sous kde il était encore possible de choisir un mode ou l'autre et je peux t'assurer que pour avoir comparé les deux le mode bitmap générait bien moins de latence. C'est super intéressant d'avoir ce qu'on va qualifier comme "vectoriel" lorsque tu veux pouvoir séparer et zoomer sur des éléments telles de figures dans inkscape par exemple mais lorsqu'il s'agit d'afficher rapidement, je ne pense pas que tu puisses bénéficier des optimisations qui ont été faites sur les cartes graphiques pour afficher des buffer bitmaps et donc même si ça à l'air génial au final ça n'est pas efficace. Je pense que c'est pour cela que Wayland a décidé de ne pas aller dans cette voie.
[^] # Re: Pas sûr que cela soit efficace
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu peux aussi faire des command buffer, avec uniquement des commandes de copies de framebuffer. On peut imaginer peut-être une composition qui se fait avec ses commandes pour éviter d'avoir à dessiner une grosse image avant de la redécouper.
"La première sécurité est la liberté"
[^] # Re: Pas sûr que cela soit efficace
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Voilà, exactement, c'est pourquoi un système à base de command buffers contient implicitement la possibilité, si on veut, de présenter un bon vieux framebuffer, sans avoir à faire quoi que ce soit en particulier pour supporter ce cas.
[^] # Re: Pas sûr que cela soit efficace
Posté par mahikeulbody . Évalué à 3.
Si j'ai bien compris (ce qui est loin d'être sûr), il s'agirait de faire le buffer bitmap dans le serveur d'affichage au lieu de le faire coté client. Du coup, je ne comprends pas la remarque ci-dessus puisqu'au final on enverrait toujours un buffer bitmap à la carte graphique.
[^] # Re: Pas sûr que cela soit efficace
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Oui, exactement!
# Après X, voici Y
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Il y a déjà eu une tentative qui ressemble à ça :
http://linuxfr.org/news/apr%C3%A8s-x-voici-y
Le moins qu'on puisse dire, c'est que ça n'a pas l'air très vivant ;-).
# Petite erreur
Posté par cedric . Évalué à 9.
Juste un point que tu as peut etre manque, avec Wayland, tu n'envois pas une bitmap qui sera copie par le serveur, mais un buffer qui pourra etre utilise directement par le compositeur. Dans le cas ou ton compositeur fonctionne en software, bon, pas trop de chance, tu vas devoir faire un memcpy. C'est pas comme si tu avais le choix. Dans le cas ou ton compositeur fonctionne avec drm et autorise wayland_egl pour tes applications, celui-ci va recevoir un EGLImage qu'il pourra mettre directement dans un plan hardware sans meme faire de composition (GPU ou software).
Cela veut dire deux choses, tout d'abord une commande est courte, c'est juste une serie de buffer, plus la region de ces buffer qui a ete mis a jour. Ensuite contrairement a X, le compositeur peut utiliser le buffer directement (donc le bloquer temporairement) meme pour une application qui n'est pas full screen si le hardware qui gere les plans graphiques autorisent le layout actuellement a l'ecran (Pour l'instant, c'est globalement la top window qui sera dans son propre plan hardware). Ce qui permet d'avoir les perfs du full screen meme quand on n'est pas en fullscreen (Bon, c'est non trivial a implementer et il y a encore du boulot dans tous les compositeurs wayland sur le sujet).
Tu conviendras que contrairement a envoyer un buffer de commande qui peut etre mal interprete par le compositeur et plutot long, tu as un pipeline plutot simple avec peu d'erreur potentiel et court. Aussi un autre point que tu n'as pas mentionne, mais les API modernes tel que Vulkan permette de faire du calcul sur le GPU dont tu obtiens le resultat pour le reutiliser potentiellement par le CPU. Dans ton modele, ca fera un round-trip supplementaire assez couteux a mon avis (sans compter la complexite a gerer les aller-retour).
Enfin concernant la latence des frames a l'affichage. Tout d'abord la raison pour laquelle les flux videos ont generalement une dizaine de frame bufferise est du au codec qui a des images partielles qui references des images dans le passe et le futur. Si tu n'avais pas autant de frame bufferise, tu ne pourrais juste pas les decoder :-) La solution est plutot effectivement d'ajouter un timestamp sur les dites frames pour les presenter le plus tot possible aux compositeurs et lui permettre de les afficher au bon moment (encore une fois, c'est un boulot important que chaque compositeur va avoir a implementer lui meme, donc ca prendra du temps avant d'etre utilisable).
Pour ceux qui est des applications 3D, la raison est assez simple. Tu as besoin de 3 buffers en general pour ne pas bloquer ton pipeline de rendu graphique. L'idee est que tu as actuellement un buffer bloque dans un plan hardware, car il est affiche. Tu as la frame suivante qui est pret a etre affiche, mais le switch de plan hardware au nouveau buffer n'a pas encore eu lieu, donc tu ne as un deuxieme buffer cote serveur en attente. Enfin l'application elle meme est prete a dessiner et decide que plutot que d'attendre que le serveur lui dise de dessiner une frame, elle va le faire en avance. Resultat, tu as effectivement besoin de 3 buffer pour ne jamais bloquer dans le scenario ou tu pousses tes frames sans te synchroniser avec le display server.
Maintenant si tu utilises le frame callback de wayland, tu auras toujours un buffer de bloque dans le hardware plane, mais wayland te dit que maintenant qu'il va affiche un nouveau buffer en fonction de la vsync de l'ecran. Donc tu n'envoie un buffer que lorsque celui ci te le demande. Et tu n'as besoin que de deux buffers. Le second avantage est que tu pousses a l'ecran une image de ton application qui est le reflet exacte de ce qu'elle est cense etre durant cette vsync. Par contre, cela veut dire que tu n'as besoin que du temps de la vsync pour dessiner une frame. Cela peut etre trop court pour certain jeux complexe.
[^] # Re: Petite erreur
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Merci pour ta réponse intéressante. Cependant je dois t'avouer que je ne vois pas de contradiction entre ce que nous disons.
Pour répondre littéralement à ton objection, "un buffer qui pourra etre utilise directement par le compositeur", certes, mais comment est-ce qu'un compositeur utilise ce buffer? Réponse: il l'utilise comme texture et il dessine un quad avec. Ce qui revient à faire une copie --- juste une forme un peu généralisée de copie, qui permet le genre d'effets qu'on voit dans les compositeurs de bureau d'aujourd'hui.
Mais je ne veux pas pinailler là-dessus, car ce n'est pas le point qui me semblait intéressant. Même sans aucune "copie", il y a tout un tas de coûts à demander aux fenêtres de fournir un framebuffer pré-rendu, comme j'essayais de l'expliquer dans mon journal: latence importante et non-constante qui rend difficile d'avoir des animations parfaitement fluides, ce qui entretient le besoin pour les applications graphiques exigentes de pouvoir contourner le système, voir la discussion ci-dessus sur les jeux 3D en plein-écran.
Je pense toujours que l'idée que je propose ici est la première à permettre des graphismes à faible latence et faible distortion d'animation (bonne fluidité) pour toutes les fenêtres, sans avoir à contourner le compositeur de bureau!
[^] # Re: Petite erreur
Posté par cedric . Évalué à 2.
Mon explication n'a pas du etre evidente sur le sujet. Le compositeur recoit un EGLImage directement qu'il va lier directement a un plan hardware. En gros, ca part direct sur le scanout sans repasser par le GPU, donc pas de copie. Et il faut maintenir ce buffer dans cette position tant que l'image est affiche a l'ecran. Cela que ce soit le job du compositeur ou du jeu.
Alors il y a des coups, mais principalement que celui du changement de contexte. Mais si tu fais cela dans le meme process, tu as exactement la meme contrainte, la seule chose que tu vas eliminer, c'est le coup du changement de process. Le reste restera la. Binder le buffer au scanout est un besoin technique, ainsi que se synchroniser sur la vsync. La seule difference, c'est qui le fait et par ou ca passe.
C'est bien pour ca que je ne pense pas que le coup de passer par un compositeur soit si problematique. Ton OS fait des changements de process en permanence. Tu as toujours plusieurs applications qui tournent et qu'il faut scheduler sur plusieurs CPU. Je doute tres tres fortement que c'est la source de probleme aujourd'hui.
Je serais bien plus facilement convaincu, si on parlait de la difficulte en OpenGL de faire du multi thread, d'uploader une texture en zero copie, de melanger calcul CPU/GPU et rendu graphique… Je pense que Vulkan va permettre de lever bien plus de probleme de fluidite que la possibilite de rendre directement a l'ecran sans passer par un compositeur (et encore cela necessite de revoir profondement la maniere dont fonctionne les moteurs graphiques).
Apres on peut aussi parler des problemes du scheduler du kernel, incapable de nos jours de faire un boulot correct lorsqu'on est sur batterie ou qu'on ne lui demande pas de pousser la machine en permanence a fond (Je vais me faire de la pub sur le sujet, mais tu peux lire : http://blogs.s-osg.org/introduction-problems-modern-linux-kernel-cpu-scheduling/ et http://blogs.s-osg.org/improving-user-space-take-advantage-kernel-scheduler-evolution-better-energy-efficiency/). Et je peux te promettre qu'aucun code user space n'est pres pour utiliser correctement un scheduler qui n'est pas lui meme pres :-D
Globalement, je suis d'accord sur le diagnostic. On a des problemes de performance et de stabilite du frame rate sous Linux et il y a du boulot pour avoir des animations fluides, mais la solution n'est pas la ou tu penses :-)
[^] # Re: Petite erreur
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Mince alors, c'est un dialogue de sourds. Tu parles essentiellement de performance; je ne parle pas de performance. Quand je parle de "coûts", je parle de latence et de qualité d'animation, et, au sens où j'ai défini ces termes dans mon journal, cela n'a rien à voir avec des performances, avec le nombre d'images par secondes etc.
Je dis simplement que, indépendamment des performances, la latence et la qualité d'animation sont limitées par le paradigme classique du framebuffer de fenêtre qui demande à chaque fenêtre de finaliser son contenu bien avant que ce contenu atteigne l'écran et, pire encore pour la qualité d'animation, avant même de pouvoir savoir avec précision quand ce contenu atteidra l'écran. Je ne vois guère d'intersection entre ce sujet, et les éléments que tu développes ici.
[^] # Re: Petite erreur
Posté par cedric . Évalué à 4.
J'ai pourtant bien explique pourquoi on avait du double ou triple buffer et pourquoi cette latence etait necessaire techniquement. Tu as toujours un framebuffer, que ce soit lorsque tu passes par un compositeur ou non. Le GPU ne dessine jamais directement a l'ecran (Il ne dessine d'ailleur generalement pas dans tout le framebuffer, mais par zone appele tile pour des raisons de cache et de calcul parallele). C'est inherent a comment fonctionne tous les accelerateurs 3D. Ceux-ci remplisse un buffer, qui sera pousse sur le scanout qui l'affichera l'ecran. Quand tu parles de latence, tu parles du temps necessaire entre la reception d'un input et sa reaction visible a l'ecran.
L'objectif etant que la prochaine frame affiche apres cet evenement le soit le plus tot possible. Il y a deux cas. Soit tu as deja commence a dessiner une image et tu vas perdre le temps de ta vsync + 16ms (sur un ecran a 60hz). Soit tu n'as pas encore commence a dessiner une image, auquel cas, tu auras moins de 16ms avant ta prochaine image qui aura l'input correct. Ca c'est dans le cas du double buffer avec aucun compositeur (Je laisse de cote le cas du triple buffer).
Maintenant en quoi le probleme change si tu as un compositeur dans l'histoire, tu as juste deux etapes supplementaire. L'input est d'abord lu dans le process du compositeur et envoye au jeu. Celui-ci se retrouve alors dans la meme situation que precedemment seulement, il n'a plus 16ms, mais 16ms - le coup du context switch pour l'input. Mais comme cela ne s'arrete pas la et qu'il te faut aussi faire un autre context switch pour pousser le buffer a l'ecran, tu te retrouves avec globalement 16 ms - 2 * context switch. Le reste est strictement egal par ailleur.
Le veritable probleme est donc bien de maintenir le maximum de stabilite dans la capacite de ton process a pouvoir pousser une frame toutes les 16ms.
[^] # Re: Petite erreur
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Bien sur, il faut finir par dessiner un framebuffer. Je dis simplement qu'on peut ne dessiner que ce framebuffer final, directement a partir de command buffers fournis par les fenetres, plutot que de le dessiner a partir de framebuffers intermediaires fournis par les fenetres. Comme tu le dis,
Et ces etapes supplementaires rajoutent une dose de latence, non-constante, entre le moment ou les fenetres dessinent leur propre framebuffer en positionnant leurs objets animes, et le moment ou ces pixels atteignent l'ecran. C'est ca qui limite la fluidite des animations dans les fenetres, independamment des performances.
Ce que je dis ici, c'est que garantir ceci ne garantit en rien la fluidite reelle des animations, qui depend du positionnement de la geometrie dessinee dans la fenetre en fonction du temps reel d'affichage a l'ecran.
[^] # Re: Petite erreur
Posté par cedric . Évalué à 4.
On est bien d'accord que dans le cas de la fenetre ayant le focus ou dans le cas d'une application plein ecran, le compositeur ne dessine rien. Il ne fait que dire a l'entite de scanout d'afficher le dit buffer directement a l'ecran. Exactement la meme operation que ferait une application qui a directement acces a l'ecran. Il n'y a pas de surcout dans ce cas.
La latence dont on parle ici est de deux context switch. Dans le pire cas, cela represente, sur une machine de moins de 5 ans, moins de 1% des 16ms que ton application va utiliser pour dessiner une frame. Les chances de manquer la deadline a cause de ces deux context switch est franchement tres tres tres basse. La variabilite reste sur juste quelques choses >1%, donc j'ai du mal a voir en quoi tu peux imaginer que c'est la que ce trouve le probleme. Est-ce que tu as des mesures qui montre des problemes de ce cote la ?
Je pense que ton probleme pour l'instant, c'est que tu n'as pas de benchmark qui montre ton probleme. Si tu essayes de convaincre qui que ce soit qui connait le sujet et bosse dans le domaine, ils auront beaucoup de mal a te croire voir meme a faire l'effort de faire un benchmark eux-meme pour verifier tes dires. Essaye d'en construire un et d'analyser le comportement du systeme. Je serais interresse de voir des traces de latence ou l'on voit le probleme de stabilite d'une animation dont tu parles. Je te conseille de le construire au dessus de Weston. Cela te donnera aussi une bonne idee de comment marche la stack graphique.
Alors la, je ne te suis pas du tout du tout ! En quoi le positionnement d'une fenetre va avoir le moindre impact sur les performances !?! Relis mes postes plus haut sur l'utilisation des plan hardware.
[^] # Re: Petite erreur
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Ça y est, je crois que je vois l'un des malentendus: tu parles des animations du compositeur lui-même ("le positionnement d'une fenêtre"), je parle des animations dessinées par l'application dans le contenu de la fenêtre ("la geometrie dessinée dans la fenêtre").
Si tu relis ce que j'écris sur la qualité d'animation, ce n'est pas nécessairement (peut-être, peut-être pas) quelque-chose que l'on peut mesurer par un quelconque procédé logiciel. A priori, cela se mesure avec une camera qui filme physiquement l'écran a au moins 60 images par seconde. C'est réellement comme ca que l'on fait dans l'industrie quand on tient vraiment a garantir la qualite réelle d'animation, par exemple les constructeurs d'appareils mobiles ont généralement recours a cette technique. Bien entendu, c'est très coûteux.
[^] # Re: Petite erreur
Posté par cedric . Évalué à 2.
Ok, donc on parlait bien de la meme chose, juste ta phrase etait un peu confuse pour moi, car quand on parle de geometrie, on parle generalement de la geometrie de la fenetre.
En fait, ce genre d'appareil n'est pas necessaire. Tu peux juste mesurer a l'aide d'un timestamp general au systeme quand tu recois un input et quand tu pousses un buffer avec le changement resultant de cet input a l'ecran. Avec un peu de bidouillage dans le protocol wayland et dans le toolkit de l'application, tu peux assez facilement propager ce timestamp de l'input au buffer d'output pour collecter ces informations. En correlant ces informations avec la vsync, tu pourras facilement voire lorsque tu perds des frames.
L'utilisation principal des cameras hautes vitesse que l'on (Samsung) a, c'est pour essayer de "voir" exactement ce que contient une frame avec un glitch graphique (Generalement du a un bug de driver). Pouvoir verifier les pixels a la sortie de l'ecran frame apres frame. On les utilise aussi lorsqu'on a des problemes d'input qui envoie en fait l'information trop tardivement. Mais a part un probleme reellement lie aux drivers, c'est rarement utilise, car franchement pas pratique comme outil d'experimentation et sans valeur ajoute pour la majorite des cas.
Par contre ce qui est amusant, c'est que apres avoir travaille suffisament longtemps dans ce domaine, tes propres yeux savent "sentir" un glitch, un lag, un frame drop. Tu peux meme avoir une estimation du framerate juste avec tes yeux et estimer le lag d'une application en nombre de frame. C'est, je trouve, plus dur de venir avec un chiffre correct pour l'estimation du lag au juge, mais definitivement tu le sens quand ce n'est pas bon.
[^] # Re: Petite erreur
Posté par Benoit Jacob (site web personnel) . Évalué à 3. Dernière modification le 01 février 2016 à 15:11.
On n'est pas d'accord là-dessus non plus: tu peux certes concevoir un compositeur qui porte directement à l'écran le contenu de certaines fenêtres, mais cela comporte de nombreux inconvénients car cela suppose de renoncer à appliquer tous types d'effets. Par exemple, beaucoup d'utilisateurs de Mac OSX se reposent sur sa capacité a redimensionner en permanence le contenu des fenêtres ("scaling"); sans parler de la transparence, etc. Donc Mac OSX n'applique clairement pas de circuit direct pour les fenêtres ayant le focus. Le cas générique est donc bien de dessiner un quad utilisant le framebuffer de la fenêtre comme texture.
[^] # Re: Petite erreur
Posté par cedric . Évalué à 2.
Desole, je n'ai pas acces au code de Mac OS X et je n'ai aucune idee de ce qu'ils font. Par contre, je suis nettement plus a l'aise avec Weston et Enlightenment. Weston supporte aussi le scaling, si j'ai bien compris ce a quoi cela correspond dans Mac OS X. Globalement changer la taille d'un buffer est supporte par les unites de scanout moderne (En tout cas celle de telephone mobile auquel j'ai acces et a priori Intel, mais je n'ai pas verifier).
Globalement le principe est le suivant, quand tu ne peux pas utiliser le "compositeur" simple qui se trouve dans le scanout, tu fallback sur l'utilisation du GPU effectivement (Cela frame apres frame). Maintenant les conditions dans lesquels tu peux utiliser l'unite de scanout uniquement varie d'un hardware a l'autre. Pour faire simple, la plus part support up et down scaling de 5 plan graphiques avec des characteristiques de colorspace qui alloue en general un ou 2 plan YUV et un certain nombre de plan RGBA (Oui, cela inclut la transparence). Ce nombre de plan graphique peut aussi varier en fonction du nombre d'ecran. Ainsi si tu as 2 ecrans, mais que tu as un total de 5 plans, tu te retrouves effectivement a devoir les partager entre tous les ecrans.
Enfin, dans le cas de Weston/Wayland, seul les applications qui fonctionnent en utilisant wayland_gl, ont un interet a etre mis dans un plan hardware (Ca ne couvre pas le terminal par exemple). Celles qui passent par wayland_shm, finissent, a priori, dans un buffer qui devrait etre copie de toute facon vers un nouveau buffer drm pour pouvoir se passer du GPU. Mais cette copie revient techniquement exactement au meme que de passer directement par le GPU avec un support de la mise a jour partiel de buffer pour faire la copie (J'avoue ce n'est pas toujours aussi tranche et des fois il vaut mieux passer faire une copie depuis le CPU dans un buffer drm que de passer par le GPU pour des raisons de consommation d'energie).
Enfin quand tu dois renoncer temporairement a l'utilisation direct de l'unite de scanout, par exemple lorsque le compositeur fait lui meme une animation (a la compiz), ce n'est pas un vrai probleme. Dans ces cas la, tu pourrais meme faire tomber le framerate des applications a 30 fps et reduire de moitie leur resolution que personne ne s'en renderait compte en fait ! Du moment que l'animation du compositeur lui meme est reactive et s'execute a 60fps, personne ne se rendra compte que tu as temporairement diminue les performances de l'application. Sur un PC, tu n'as probablement peu de cas ou tu aurais besoin de faire de tel choix, mais sur un mobile, cela arrive que tu sois limite en bande passante GPU/CPU au point ou tu doivent faire ce genre de chose.
Donc le cas principale d'utilisation est bien l'utilisation unique de l'unite de scanout. J'entend bien par cela le temps d'utilisation d'une application a l'ecran dans une situation interactive.
# pour simplifier si je dis :
Posté par bunam . Évalué à 0.
Tu veux parler de "sprites" à taille variable, avec des effets par rapport aux autres :
- taille
- position
- transparence (exemple d'effet)
et aussi que l'on puisse adresser des changement a son ancienne instance sans tout redessiner ?
Seul le compositeur final connaitrait la gueule de l'image entière ?
J'ai bien connu les sprites sur Amiga ou on pouvait changer leur emplacement pendant le balayage sans changer un octet dans l'image, juste des valeurs x,y.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.