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.
[^] # 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.
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.