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