Implementar a HAL do Hardware Composer

A HAL do Hardware Composer (HWC) compõe as camadas recebidas do SurfaceFlinger, reduzindo a quantidade de composição OpenGL ES (GLES) e a performance da GPU.

O HWC abstrai objetos, como sobreposições e blitters 2D, para compor 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 do 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/plano de fundo
  • 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 a HWC:

  1. Implemente um HWC não operacional e envie todo o trabalho de composição para GLES.
  2. Implementar um algoritmo para delegar a composição ao HWC gradualmente. Por exemplo, delegue apenas as três ou quatro primeiras superfícies para o hardware de sobreposição do HWC.
  3. Otimizar a 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. Caso contrário, delegue a composição para o GLES em vez do HWC para economizar energia. Quando a tela for atualizada novamente, continue a transferir a composição para o HWC.
    • Como se preparar para casos de uso comuns, como:
      • A tela inicial, que inclui a barra de status, a barra do sistema, o app janela e planos de fundo interativos,
      • Jogos em tela cheia nos modos retrato e paisagem
      • Vídeo em tela cheia com legendas e reprodução controle
      • Reprodução de vídeo protegida
      • Várias janelas em tela dividida

Primitivos de HWC

O HWC fornece dois primitivos, camadas e telas, para representam o trabalho de composição e a interação dele com o hardware de tela. O O HWC também oferece controle sobre VSYNC e um callback para o SurfaceFlinger para notificá-lo quando ocorrer um evento VSYNC.

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. O HAL do Composer substitui a interface hwcomposer2.h legada. Se os fornecedores fornecerem uma HAL do Composer implementação do HWC, a HAL do Composer aceita diretamente chamadas HIDL do com o 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 oferece funções para determinar as propriedades de uma determinada tela. para alternar entre diferentes configurações de tela (como 4K ou 1080p resolução) e modos de cor (como cor nativa ou sRGB verdadeiro); e transformar a tela ligada, desligada ou em um modo de baixo consumo de energia, se compatível.

Ponteiros de função

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

Se os fornecedores implementarem a interface hwcomposer2.h, a HAL do Composer chamadas em ponteiros de função hwcomposer2.h. Em hwcomposer2.h comentários, As funções de interface HWC são referenciados por nomes bottomCamelCase 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 acessar a documentação detalhada ponteiros da função HWC, consulte a hwcomposer2.h

Alças de camada e exibição

As camadas e telas são manipuladas por identificadores gerados 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 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 identificador e o transmite para o SurfaceFlinger por meio do callback de hotplug. Telas virtuais criadas pelo SurfaceFlinger chamando createVirtualDisplay() para solicitar uma exibição. Se o dispositivo HWC oferece suporte à composição de exibição virtual, ele retorna um identificador. Depois, o SurfaceFlinger delega a composição das telas ao hardware 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 será ativado se houver novo conteúdo para composto. 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. Traça 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 vai prosseguir. Por padrão, o SurfaceFlinger tenta configurar todas as camadas. de forma que a camada seja composta pelo HWC; embora, em alguns circunstâncias, o SurfaceFlinger compõe camadas usando o 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 estiver marcada para a composição do SurfaceFlinger, o SurfaceFlinger e os compõe no buffer de destino. O SurfaceFlinger chama setClientTarget para fornecer o buffer à tela, de modo que o buffer possa ser mostrado na tela ou composto com camadas que não foram marcadas para 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 para uso no Android 7.0 e no mais alto, há algumas restrições que não estão presentes na definição de HWC:

  • Supõe-se que há exatamente uma tela interna. Os dados tela é aquela que o hotplug inicial informa durante inicialização. Depois que a tela interna é conectada, não é possível ser desconectados.
  • Além da tela interna, qualquer número de monitores externos pode estar conectado por hotplug durante a operação normal do dispositivo. O framework presume que todos os hotplugs após a primeira tela interna são telas externas, portanto, se houver 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 realizadas sequencialmente para todas as telas ativas, mesmo que o conteúdo de apenas uma tela seja atualizado.

Por exemplo, se o monitor externo for atualizado, 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 de tela virtual e a composição de tela física é que as telas virtuais enviam a saída para um buffer Gralloc em vez de para a tela. O compositor de hardware (HWC) grava a saída em um buffer, fornece a cerca de conclusão e envia o buffer para um consumidor, como o codificador de vídeo, a GPU, a CPU etc. Telas virtuais podem usar 2D/blitter ou se o pipeline de exibição fizer gravações 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 combina todas as camadas, gravando diretamente no buffer de saída. O HWC não está envolvido na composição.
  • MIXED: a GPU compõe algumas camadas ao o framebuffer e HWC compõem o framebuffer e as camadas restantes, gravando diretamente no buffer de saída.
  • HWC: HWC compõe todas as camadas e grava diretamente ao 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 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 CPU acesso, o consumidor define o formato. Caso contrário, o formato será IMPLEMENTATION_DEFINED, e o Gralloc define o melhor formato com base as flags de uso. Por exemplo, Gralloc define um formato YCbCr se o consumidor o codificador de vídeo e o HWC possam gravar o formato de forma eficiente.

Cercas de sincronização

As cercas de sincronização (sync) são um aspecto crucial do sistema gráfico do Android. Os limites permitem que o trabalho da CPU ocorra de maneira independente do trabalho simultâneo da GPU. o bloqueio de dados somente quando há uma dependência verdadeira.

Por exemplo, quando um app envia um buffer que está sendo produzido em a GPU também envia um objeto de limite 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. As cercas de sincronização são transmitidas pelo pipeline gráfico com buffers e sinalizam quando os buffers são gravados. Antes da exibição de um buffer, o HWC verifica se o limite de sincronização sinalizou e, em caso positivo, exibe o tempo extra.

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