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.
# Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). É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.