Implementar a HAL do Hardware Composer

As camadas compostas HAL do Hardware Composer (HWC) recebidas do SurfaceFlinger, reduzindo a quantidade de composição OpenGL ES (GLES) e o desempenho da GPU.

O HWC abstrai objetos, como sobreposições e blitters 2D, para mesclar superfícies e se comunicar com hardware especializado de composição de janelas para compor janelas. Use o HWC para compor janelas em vez de usar o SurfaceFlinger com a GPU. A maioria das GPUs não é otimizada para composição. Quando a GPU compõe camadas do SurfaceFlinger, os apps não podem usar a GPU para a própria renderização.

As implementações de HWC precisam oferecer suporte a:

  • Pelo menos quatro sobreposições:
    • Barra de status
    • Barra do sistema
    • App
    • Plano de fundo/papel de parede
  • Camadas maiores que a tela (por exemplo, um plano de fundo)
  • Mistura alfa pré-multiplicada por pixel e por plano simultânea
  • Caminho de hardware para reprodução de vídeo protegida
  • Ordem de compactação RGBA, formatos YUV e propriedades de ladrilhos, swizzling e stride

Para implementar o HWC:

  1. Implemente um HWC não operacional e envie todo o trabalho de composição para GLES.
  2. Implemente um algoritmo para delegar a composição ao HWC de forma incremental. Por exemplo, delegue apenas as três ou quatro primeiras superfícies para o hardware de sobreposição do HWC.
  3. Otimize o HWC. Isso pode incluir:
    • Selecionar superfícies que maximizam a carga retirada da GPU e enviá-las para o HWC.
    • Detectando se a tela está sendo atualizada. Se não for, delegue a composição ao GLES em vez da HWC para economizar energia. Quando a tela for atualizada novamente, continue a transferir a composição para o HWC.
    • Preparar-se para casos de uso comuns, como:
      • A tela inicial, que inclui a barra de status, a barra do sistema, a janela do app e os planos de fundo interativos
      • Jogos em tela cheia no modo retrato e paisagem
      • Vídeo em tela cheia com legendas e controle de reprodução
      • Reprodução de vídeo protegida
      • Janela múltipla em tela dividida

Primitivos de HWC

O HWC fornece duas primitivas, layers e displays, para representar o trabalho de composição e a interação com o hardware de exibição. O HWC também oferece controle sobre VSYNC e um callback para SurfaceFlinger para notificá-lo quando um evento VSYNC ocorre.

Interface HIDL

O Android 8.0 e versões mais recentes usam uma interface HIDL chamada HAL do Composer para IPC vinculado entre o HWC e o SurfaceFlinger. A HAL do Composer substitui a interface hwcomposer2.h legada. Se os fornecedores fornecerem uma implementação de HAL do Composer para o HWC, a HAL do Composer vai aceitar diretamente as chamadas HIDL do SurfaceFlinger. Se os fornecedores fornecerem uma implementação legada do HWC, o HAL do Composer vai carregar ponteiros de função de hwcomposer2.h, encaminhando chamadas HIDL para chamadas de ponteiros de função.

O HWC fornece funções para determinar as propriedades de uma determinada tela, alternar entre diferentes configurações de tela (como resolução 4K ou 1080p) e modos de cor (como cor nativa ou sRGB verdadeiro) e ativar, desativar ou colocar a tela em modo de baixo consumo, se houver suporte.

Ponteiros de função

Se os fornecedores implementarem o HAL do Composer diretamente, o SurfaceFlinger vai chamar as funções pelo IPC do HIDL. Por exemplo, para criar uma camada, o SurfaceFlinger chama createLayer() no HAL do Composer.

Se os fornecedores implementarem a interface hwcomposer2.h, o HAL do Composer vai chamar ponteiros de função hwcomposer2.h. Nos comentários hwcomposer2.h, as funções da interface HWC são referenciadas por nomes em lowerCamelCase que não existem na interface como campos nomeados. Quase todas as funções são carregadas solicitando um ponteiro de função usando getFunction fornecido por hwc2_device_t. Por exemplo, a função createLayer é um ponteiro de função do tipo HWC2_PFN_CREATE_LAYER, que é retornado quando o valor enumerado HWC2_FUNCTION_CREATE_LAYER é transmitido para getFunction.

Para conferir uma documentação detalhada sobre as funções HAL do Composer e as funções de passagem de função HWC, consulte composer. Para conferir uma documentação detalhada sobre ponteiros de função de HWC, consulte o hwcomposer2.h.

Alças de camada e exibição

As camadas e telas são manipuladas por alças geradas pelo HWC. As alças são opacas para o SurfaceFlinger.

Quando o SurfaceFlinger cria uma nova camada, ele chama createLayer, que retorna do tipo Layer para implementações diretas ou hwc2_layer_t para implementações de passagem. Quando o SurfaceFlinger modifica uma propriedade dessa camada, ele transmite o valor hwc2_layer_t para a função de modificação adequada com todas as outras informações necessárias para fazer a modificação. O tipo hwc2_layer_t é grande o suficiente para conter um ponteiro ou um índice.

As telas físicas são criadas por hotplug. Quando uma tela física é conectada, o HWC cria um handle e o transmite para o SurfaceFlinger por meio do callback de hotplug. As telas virtuais são criadas pelo SurfaceFlinger chamando createVirtualDisplay() para solicitar uma tela. Se o HWC oferecer suporte à composição de tela virtual, ele retorna um identificador. Em seguida, o SurfaceFlinger delega a composição das telas para o HWC. Se o HWC não oferecer suporte à composição de tela virtual, o SurfaceFlinger vai criar o handle e compor a tela.

Mostrar operações de composição

Uma vez por VSYNC, o SurfaceFlinger é ativado se tiver um novo conteúdo para compor. Esse novo conteúdo pode ser novos buffers de imagem de apps ou uma mudança nas propriedades de uma ou mais camadas. Quando o SurfaceFlinger acorda:

  1. Processa transações, se houver.
  2. Trava novos buffers gráficos, se houver.
  3. Executa uma nova composição se a etapa 1 ou 2 resultar em uma mudança no conteúdo da tela.

Para realizar uma nova composição, o SurfaceFlinger cria e destrói camadas ou modifica os estados das camadas, conforme aplicável. Ele também atualiza camadas com o conteúdo atual, usando chamadas como setLayerBuffer ou setLayerColor. Depois que todas as camadas são atualizadas, o SurfaceFlinger chama validateDisplay, que instrui o HWC a examinar o estado das camadas e determinar como a composição continuará. Por padrão, o SurfaceFlinger tenta configurar todas as camadas para que sejam compostas pelo HWC. No entanto, em algumas circunstâncias, o SurfaceFlinger compõe camadas pelo substituto da GPU.

Após a chamada para validateDisplay, o SurfaceFlinger chama getChangedCompositionTypes para saber se o HWC quer que algum dos tipos de composição de camada seja alterado antes de realizar a composição. Para aceitar as mudanças, o SurfaceFlinger chama acceptDisplayChanges.

Se alguma camada for marcada para composição do SurfaceFlinger, ele a vai compor no buffer de destino. Em seguida, o SurfaceFlinger chama setClientTarget para fornecer o buffer à tela. Assim, ele pode ser mostrado na tela ou composto por camadas que não foram marcadas para a composição do SurfaceFlinger. Se nenhuma camada for marcada para composição do SurfaceFlinger, o SurfaceFlinger vai ignorar a etapa de composição.

Por fim, o SurfaceFlinger chama presentDisplay para informar ao HWC que ele precisa concluir o processo de composição e mostrar o resultado final.

Várias telas

O Android 10 oferece suporte a várias telas físicas. Ao projetar uma implementação de HWC destinada ao uso no Android 7.0 e versões mais recentes, há algumas restrições que não estão presentes na definição de HWC:

  • Suponha que haja exatamente uma tela interna. A tela interna é a que o hotplug inicial informa durante a inicialização. Depois que a tela interna é conectada, ela não pode ser desconectada.
  • Além da tela interna, qualquer número de telas externas pode ser conectado durante a operação normal do dispositivo. O framework pressupõe que todos os hotplugs após a primeira tela interna são telas externas. Portanto, se mais telas internas forem adicionadas, elas serão categorizadas incorretamente como Display.TYPE_HDMI em vez de Display.TYPE_BUILT_IN.

Embora as operações do SurfaceFlinger descritas acima sejam realizadas por tela, elas são executadas sequencialmente para todas as telas ativas, mesmo que o conteúdo de apenas uma tela seja atualizado.

Por exemplo, se a tela externa for atualizada, a sequência será:

// In Android 9 and lower:

// Update state for internal display
// Update state for external display
validateDisplay(<internal display>)
validateDisplay(<external display>)
presentDisplay(<internal display>)
presentDisplay(<external display>)

// In Android 10 and higher:

// Update state for internal display
// Update state for external display
validateInternal(<internal display>)
presentInternal(<internal display>)
validateExternal(<external display>)
presentExternal(<external display>)

Composição de tela virtual

A composição de tela virtual é semelhante à composição de tela externa. A diferença entre a composição da tela virtual e a composição da tela física é que as telas virtuais enviam a saída para um buffer Gralloc em vez da tela. O Hardware Composer (HWC) grava a saída em um buffer, fornece o limite de conclusão e o envia para um consumidor, como o codificador de vídeo, GPU, CPU e assim por diante. As telas virtuais poderão usar 2D/blitter ou sobreposições se o pipeline de exibição gravar na memória.

Modos

Cada frame está em um dos três modos depois que o SurfaceFlinger chama o método HWC validateDisplay():

  • GLES: a GPU compõe todas as camadas, gravando diretamente no buffer de saída. A HWC não está envolvida na composição.
  • MIXED: a GPU compõe algumas camadas no framebuffer e o HWC compõe o framebuffer e as camadas restantes, gravando diretamente no buffer de saída.
  • HWC: o HWC compõe todas as camadas e grava diretamente no buffer de saída.

Formato de saída

Os formatos de saída do buffer de exibição virtual dependem do modo:

  • Modo GLES: o driver EGL define o formato do buffer de saída em dequeueBuffer(), normalmente RGBA_8888. O consumidor precisa aceitar o formato de saída definido pelo driver, ou o buffer não poderá ser lido.
  • Modos MIXED e HWC: se o consumidor precisar de acesso à CPU, ele definirá o formato. Caso contrário, o formato é IMPLEMENTATION_DEFINED, e o Gralloc define o melhor formato com base nos flags de uso. Por exemplo, o Gralloc define um formato YCbCr se o consumidor for um codificador de vídeo e o HWC puder gravar o formato de maneira eficiente.

Limites de sincronização

As cercas de sincronização (sync) são um aspecto crucial do sistema gráfico do Android. As cercas permitem que o trabalho da CPU prossiga de forma independente do trabalho da GPU simultâneo, bloqueando apenas quando há uma dependência real.

Por exemplo, quando um app envia um buffer que está sendo produzido na GPU, ele também envia um objeto de cerca de sincronização. Essa cerca sinaliza quando a GPU terminou de gravar no buffer.

O HWC exige que a GPU termine de gravar buffers antes que eles sejam exibidos. Os limites de sincronização são passados pelo pipeline de gráficos com buffers e sinalizam quando os buffers são gravados. Antes que um buffer seja mostrado, o HWC verifica se a cerca de sincronização sinalizou e, se sim, exibe o buffer.

Para mais informações sobre limites de sincronização, consulte Integração do Hardware Composer.