Réduire la consommation de mémoire graphique

Dans la pile graphique, un cache de tampon par calque se trouve entre Composer HAL et SurfaceFlinger pour réduire la surcharge associée à l'envoi de descripteurs de fichiers sur IPC. Avant Android 14, le système ne vidait pas ce cache de tampon lorsqu'un GraphicBufferProducer se déconnectait de GraphicBufferConsumer de SurfaceFlinger, par exemple lorsqu'un MediaCodec se déconnectait d'une SurfaceView. À partir d'Android 14, vous pouvez vider de force ce cache de tampon pour réduire la consommation de mémoire graphique.

Choisissez l'une des deux options suivantes :

  • Pour les appareils lancés avec Android 14 ou version ultérieure, vous devez implémenter la nouvelle API Composer HAL version 3.2. Cette option est activée par défaut et permet d'économiser le maximum de mémoire. Les appareils passant à la version 14 ou ultérieure peuvent également utiliser cette option pour profiter pleinement des avantages de la mémoire.
  • Pour les appareils qui passent à Android 14 et pour lesquels vous ne souhaitez pas implémenter l'API Composer HAL 3.2, vous pouvez activer l'option rétrocompatible. Cette option permet d'économiser presque autant de mémoire que l'option précédente.

Les deux sections suivantes expliquent comment implémenter chaque option.

Implémenter l'API Composer HAL 3.2

Pour profiter pleinement des avantages de la mémoire tampon graphique, vous devez :

  1. Mettez à jour votre implémentation Composer HAL vers la version 3.2.
  2. Traitez LayerCommand::bufferSlotsToClear en supprimant les entrées du cache du tampon indiquées par les numéros d'emplacement figurant dans la liste.

Les API Composer HAL 3.2 liées à la mémoire tampon graphique, y compris LayerCommand::bufferSlotsToClear, se trouvent dans le fichier LayerCommand.aidl.

Activer l'option rétrocompatible

L'option de réduction de la mémoire rétrocompatible remplace un véritable tampon dans l'emplacement du cache par un tampon d'espace réservé 1x1. Cela permet d'économiser de la mémoire pour tous les emplacements purgés, à l'exception de l'emplacement de tampon actif actuel. Pour bénéficier d'économies de mémoire partielles, activez l'option rétrocompatible en définissant la propriété système surface_flinger.clear_slots_with_set_layer_buffer sur true. Cette propriété système se trouve dans le fichier property_contexts.

Pour définir cette propriété système, votre implémentation Composer HAL doit gérer correctement plusieurs commandes setLayerBuffer pour le même calque dans un même cycle de présentation.

L'activation de l'option de compatibilité descendante a les effets suivants :

  • Pour les HAL AIDL : SurfaceFlinger envoie plusieurs instances LayerCommand pour un même calque, chacune avec un seul BufferCommand. Chaque BufferCommand contient un handle de tampon d'espace réservé 1x1 et un numéro d'emplacement pour l'emplacement de tampon de cache qui doit être vidé.

  • Pour les HAL HIDL : SurfaceFlinger envoie plusieurs commandes SELECT_DISPLAY, SELECT_LAYER et SET_BUFFER. Ces commandes contiennent un handle de tampon d'espace réservé 1x1 et un numéro d'emplacement pour l'emplacement du tampon de cache qui doit être purgé.

L'option rétrocompatible peut entraîner le plantage de Composer HAL sur certains appareils. Vous pourrez peut-être modifier votre HAL Composer pour résoudre ce problème. Le code qui contrôle ce comportement se trouve ici :

Tester la consommation de mémoire cache de la mémoire tampon graphique

Les tests ne peuvent pas vérifier si les implémentations HAL vident les emplacements de cache. Toutefois, vous pouvez utiliser vos outils de débogage pour surveiller l'utilisation de la mémoire tampon graphique. En surveillant, vous remarquerez peut-être moins d'erreurs de mémoire insuffisante dans les scénarios où plusieurs vidéos différentes sont arrêtées et démarrées rapidement sur YouTube.

Des tests VTS sont disponibles pour vérifier que l'implémentation HAL est fonctionnellement capable de recevoir les nouveaux appels d'API (HAL version 3.2 ou ultérieure) ou plusieurs commandes setLayerBuffer pour l'implémentation rétrocompatible. Toutefois, cela ne doit pas être considéré comme un test suffisant pour un bon fonctionnement, car certains appareils réussissent ces tests VTS, mais échouent lors de cas d'utilisation réels.

Pour les nouveaux tests VTS, consultez les liens suivants :