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