Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

BufferQueue et Gralloc

La classe BufferQueue connecte les composants qui génèrent des tampons de données graphiques ( producteurs ) aux composants qui acceptent les données pour affichage ou traitement ultérieur ( consommateurs ). Presque tout ce qui déplace des tampons de données graphiques dans le système repose sur BufferQueue.

L'allocateur de mémoire Gralloc effectue des allocations de tampon et est implémenté via deux interfaces HIDL spécifiques au fournisseur (voir hardware/interfaces/graphics/allocator/ et hardware/interfaces/graphics/mapper/ ). La fonction allocate() prend les arguments attendus (largeur, hauteur, format de pixel) ainsi qu'un ensemble d'indicateurs d'utilisation.

Producteurs et consommateurs de BufferQueue

Les consommateurs créent et possèdent la structure de données BufferQueue et peuvent exister dans des processus différents de ceux de leurs producteurs. Lorsqu'un producteur a besoin d'un tampon, il demande un tampon libre à BufferQueue en appelant dequeueBuffer() , en spécifiant la largeur, la hauteur, le format de pixel et les indicateurs d'utilisation des tampons. Le producteur remplit ensuite le tampon et renvoie le tampon dans la file d'attente en appelant queueBuffer() . Ensuite, le consommateur acquiert le tampon avec acquireBuffer() et utilise le contenu du tampon. Lorsque le consommateur a terminé, il renvoie le tampon dans la file d'attente en appelant releaseBuffer() . Le cadre de synchronisation contrôle la façon dont les tampons se déplacent dans le pipeline graphique Android.

Certaines caractéristiques de BufferQueue, telles que le nombre maximum de tampons qu'elle peut contenir, sont déterminées conjointement par le producteur et le consommateur. Cependant, BufferQueue alloue des tampons comme il en a besoin. Les tampons sont conservés à moins que les caractéristiques changent; par exemple, si un producteur demande des tampons avec une taille différente, les anciens tampons sont libérés et de nouveaux tampons sont alloués à la demande.

Le contenu du tampon n'est jamais copié par BufferQueue, car déplacer autant de données est inefficace. Au lieu de cela, les tampons sont toujours passés par un handle.

Suivi de BufferQueue avec Systrace

Pour comprendre comment les tampons graphiques se déplacent, utilisez Systrace , un outil qui enregistre l'activité de l'appareil sur une courte période. Le code graphique au niveau du système est bien instrumenté, tout comme une grande partie du code de cadre d'application pertinent.

Pour utiliser Systrace, activez la gfx , view et sched tags. Les objets BufferQueue sont affichés dans la trace. Par exemple, si vous effectuez une trace pendant l' exécution de la vidéo Play de Grafika (SurfaceView) , la ligne intitulée SurfaceView vous indique combien de tampons ont été mis en file d'attente à un moment donné.

La valeur s'incrémente lorsque l'application est active, ce qui déclenche le rendu des images par le décodeur MediaCodec. La valeur décrémente pendant que SurfaceFlinger fonctionne et consomme des tampons. Lors de l'affichage d'une vidéo à 30 ips, la valeur de la file d'attente varie de 0 à 1 car l'affichage ~ 60 ips peut suivre la source. SurfaceFlinger se réveille uniquement lorsqu'il y a du travail à faire, pas 60 fois par seconde. Le système essaie d'éviter le travail et désactive VSYNC si rien ne met à jour l'écran.

Si vous passez à la vidéo Play de Grafika (TextureView) et saisissez une nouvelle trace, vous voyez une ligne intitulée com.android.grafika / com.android.grafika.PlayMovieActivity . Il s'agit de la couche principale de l'interface utilisateur, qui est une autre BufferQueue. Étant donné que TextureView est rendu dans la couche d'interface utilisateur plutôt que dans une couche distincte, toutes les mises à jour vidéo sont affichées ici.

Gralloc

L'allocateur Gralloc HAL hardware/libhardware/include/hardware/gralloc.h effectue des allocations de tampon via des indicateurs d'utilisation. Les indicateurs d'utilisation incluent des attributs tels que:

  • Fréquence d'accès à la mémoire à partir du logiciel (CPU)
  • Fréquence d'accès à la mémoire à partir du matériel (GPU)
  • Si la mémoire sera utilisée comme texture OpenGL ES (GLES)
  • Si la mémoire sera utilisée par un encodeur vidéo

Par exemple, si le format de tampon d'un producteur spécifie RGBA_8888 pixels et que le producteur indique que le tampon sera accessible à partir du logiciel (ce qui signifie qu'une application touchera les pixels sur le CPU), Gralloc crée un tampon avec 4 octets par pixel dans l'ordre RGBA. Si à la place, un producteur spécifie que son tampon ne sera accessible qu'à partir du matériel et en tant que texture GLES, Gralloc peut faire tout ce que le pilote GLES veut, comme la commande BGRA, les mises en page non linéaires et les formats de couleur alternatifs. Permettre au matériel d'utiliser son format préféré peut améliorer les performances.

Certaines valeurs ne peuvent pas être combinées sur certaines plateformes. Par exemple, l'indicateur d'encodeur vidéo peut nécessiter des pixels YUV, donc l'ajout d'un accès logiciel et la spécification de RGBA_8888 échouent.

Le handle retourné par Gralloc peut être passé entre les processus via Binder.

Tampons protégés

L'indicateur d'utilisation GRALLOC_USAGE_PROTECTED permet au tampon graphique d'être affiché uniquement via un chemin protégé par le matériel. Ces plans de superposition sont le seul moyen d'afficher le contenu DRM (les tampons protégés par DRM ne sont pas accessibles par SurfaceFlinger ou le pilote OpenGL ES).

La vidéo protégée par DRM ne peut être présentée que sur un plan de superposition. Les lecteurs vidéo prenant en charge le contenu protégé doivent être implémentés avec SurfaceView. Les logiciels exécutés sur du matériel non protégé ne peuvent ni lire ni écrire le tampon; les chemins protégés par le matériel doivent apparaître sur la superposition de Hardware Composer (c'est-à-dire que les vidéos protégées disparaissent de l'affichage si Hardware Composer passe à la composition OpenGL ES).

Pour plus d'informations sur le contenu protégé, consultez DRM .