2015-04-11 4 views
3

J'ai quelques questions sur le SurfaceFlinger:Android SurfaceFlinger et openGL ES

1) Je comprends que l'application écrit à la surface elle-même, puis déplace le tampon à la SurfaceFlinger (supposons que je utilise une toile de matériel ou EGL). Qu'y a-t-il dans le tampon? pixels bruts? code openGL compilé? Le tampon peut-il contenir des pixels sur une transaction et un autre type de données sur une autre?

2) J'ai lu quelque part que le SurfaceFlinger écrit dans les commandes HWC/DisplayController en utilisant l'API OpenGL ES 1.0. Est-ce vrai?

Si tel est le cas, alors comment les commandes de la version 3.0 sont-elles traduites en commandes de la version 1.0, et où?

Merci

Répondre

4

(1) En supposant que vous utilisez OpenGL ES, l'application met en attente des commandes au pilote GL, ce qui rend la sortie à un tampon. La surface est un pool/file d'attente de tampons qui sont partagés entre un producteur et un consommateur; dans ce cas, l'application est le producteur, et SurfaceFlinger le consommateur. Pour le rendu GLES à une Surface, le pool aura deux ou trois tampons (c'est-à-dire, le double ou triple buffering). Le tampon est alloué par gralloc, a un en-tête qui décrit le contenu (largeur, hauteur, format de pixel, etc.), et contient des pixels bruts.

Il n'est pas nécessaire que les pixels bruts existent, car un système suffisamment sophistiqué pourrait simplement rejouer les commandes GLES si nécessaire, mais en pratique, les implémentations remplissent des tampons et passent les poignées. Comme l'en-tête gralloc spécifie les attributs de la mémoire tampon, il est possible de modifier la taille de la mémoire tampon et le format des pixels à tout moment. Certaines parties du système ne s'y attendent pas. Par exemple, si vous alimentez des pixels RVB à l'entrée Surface d'un MediaCodec, puis passez à YUV, le codec risque de ne pas détecter la modification. (Cela peut être démontré avec certaines options cachées à screenrecord.)

(2) Le composeur de matériel a its own API. Il n'a aucun rapport avec GLES. Dans les cas où le nombre de plans de recouvrement est dépassé, tout ou partie de la composition peut être faite avec GLES, mais cela est traité dans SurfaceFlinger.

Plus de détails peuvent être trouvés dans le graphics architecture doc.

+0

Merci, mais je ne suis pas encore sûr de comprendre: I) les commandes à l'intérieur du tampon gralloc sont des commandes openGL "compilées" qui peuvent être exécutées sur n'importe quel périphérique supportant openGL (quel type de code "respecté"?) II) est-ce que le flinger de surface supporte vraiment seulement les commandes GLES 1.0 (quand on n'utilise pas trop de plans)? et où est faite la traduction de GLES 3.0 à GLES 1.0? – EyalBellisha

+0

Le tampon Gralloc contient des données de pixels. Le pilote GLES dispose d'une file d'attente de commandes spécifique au fournisseur. * En théorie * vous pouvez simplement rejouer les commandes chaque fois que quelqu'un effectue la composition du tampon, mais en pratique les commandes sont terminées avant que la clôture soit signalée et l'étape suivante est capable d'accéder aux pixels, ce qui est fait en lisant les données Gralloc tampon. SurfaceFlinger utilisera GLES 1.x ou 2.x pour la composition sans superposition; voir https://android.googlesource.com/platform/frameworks/native/+/lollipop-release/services/surfaceflinger/RenderEngine/ – fadden