Framework de sincronização

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O framework de sincronização descreve explicitamente as dependências entre diferentes operações assíncronas no sistema gráfico Android. A estrutura fornece uma API que permite que os componentes indiquem quando os buffers são liberados. O framework também permite que os primitivos de sincronização sejam transmitidos entre drivers do kernel ao espaço do usuário e entre os próprios processos do espaço do usuário.

Por exemplo, um aplicativo pode enfileirar o trabalho a ser realizado na GPU. A GPU começa a desenhar essa imagem. Embora a imagem não tenha sido desenhada na memória, o ponteiro do buffer é passado para a janela compositor junto com um limite que indica quando o trabalho da GPU será concluir. O compositor da janela começa o processamento antecipadamente e passa o trabalho para o controlador de tela. Da mesma forma, a CPU funciona é feito com antecedência. Quando a GPU terminar, o controlador de exibição exibe a imagem imediatamente.

O framework de sincronização também permite que implementadores aproveitem recursos de sincronização nos próprios componentes de hardware. Por fim, o fornece visibilidade do pipeline de gráficos para ajudar na depuração.

Sincronização explícita

A sincronização explícita permite que produtores e consumidores de buffers gráficos sinalizem quando terminarem de usar um buffer. A sincronização explícita é implementado no espaço do kernel.

Os benefícios da sincronização explícita incluem:

• Menos variação de comportamento entre os dispositivos
• Melhor suporte à depuração
• Métricas de teste aprimoradas

O framework de sincronização tem três tipos de objeto:

• sync_timeline
• sync_pt
• sync_fence

sync_timeline

sync_timeline é uma linha do tempo monotonicamente crescente que os fornecedores devem implementar para cada instância de driver, como contexto de GL, ou controle de tela em 2D. sync_timeline conta os jobs enviados ao kernel para um hardware específico. O sync_timeline fornece garantias sobre a ordem das operações e permite implementações específicas de hardware.

Siga estas diretrizes ao implementar sync_timeline:

• Dê nomes úteis para todos os drivers, linhas do tempo e cercas para simplificar a depuração.
• Implemente os operadores timeline_value_str e pt_value_str em linhas do tempo para tornar a saída de depuração mais legível.
• Implemente o preenchimento driver_data para dar acesso a dados de linha do tempo particulares a bibliotecas do espaço do usuário, como a biblioteca GL, se desejar. data_driver permite que os fornecedores transmitam informações sobre os dados imutáveis sync_fence e sync_pts para criar linhas de comando. com base neles.
• Não permita que o espaço do usuário crie ou sinalize um limite explicitamente. A criação explícita de indicadores/cercas resulta em um ataque de negação de serviço que interrompe a funcionalidade do pipeline.
• Não acessar sync_timeline, sync_pt ou sync_fence explicitamente. A API oferece todas as funções necessárias.

sinc_pt

sync_pt é um único valor ou ponto em um sync_timeline. Um ponto tem três estados: ativo, sinalizado e erro. Os pontos começam no estado ativo e passar para os estados sinalizados ou de erro. Por exemplo, quando uma imagem consumidor não precisar mais de um buffer, um sync_pt será sinalizado para que os produtores de imagens saibam que não há problema em gravar no buffer novamente.

sincronia_de_sincronia

sync_fence é uma coleção de valores sync_pt que geralmente têm diferentes pais sync_timeline, como o controlador de exibição e a GPU. sync_fence, sync_pt e sync_timeline são as principais primitivas que os drivers e o espaço do usuário usam para comunicar as dependências. Quando uma cerca é sinalizada, todos os comandos emitidos antes dela são garantidos como concluídos, porque o driver do kernel ou o bloco de hardware executa comandos em ordem.

O framework de sincronização permite que vários consumidores ou produtores sinalizem quando terminarem de usar um buffer, comunicando as informações de dependência com um parâmetro de função. Os limites são respaldados por um descritor de arquivo e são passados de espaço do kernel para o espaço do usuário. Por exemplo, uma cerca pode ter dois Valores de sync_pt que significam quando dois consumidores de imagem diferentes terminam e a leitura de um buffer. Quando a cerca é sinalizada, os produtores de imagens sabem que os consumidores terminaram de consumir.

As cercas, como os valores sync_pt, começam ativas e mudam de estado com base no estado dos pontos. Se todos os valores de sync_pt forem sinalizados, o sync_fence será sinalizado. Se um sync_pt entrar em um estado de erro, o sync_fence inteiro terá um estado de erro.

A associação em um sync_fence é imutável depois que o limite é criados. Para ter mais de um ponto em uma cerca, é realizada uma mesclagem, em que pontos de duas cercas distintas são adicionados a uma terceira. Se um desses pontos tiver sido sinalizado na cerca de origem e o outro não, a terceira cerca também não estará em um estado sinalizado.

Para implementar a sincronização explícita, forneça o seguinte:

• Subsistema do espaço do kernel que implementa o framework de sincronização para um driver de hardware específico. Os drivers que precisam ser compatíveis com a cerca são geralmente qualquer coisa que acesse ou se comunique com o Hardware Composer. Os principais arquivos incluem:
  • Implementação principal:
    • kernel/common/include/linux/sync.h
    • kernel/common/drivers/base/sync.c
  • Documentação em kernel/common/Documentation/sync.txt
  • para se comunicar com o espaço do kernel em platform/system/core/libsync
• O fornecedor precisa fornecer o serviço de sincronização limites como parâmetros para validateDisplay() e presentDisplay() na HAL.
• Duas extensões GL relacionadas a cercas (EGL_ANDROID_native_fence_sync e EGL_ANDROID_wait_sync) e suporte a cercas no driver gráfico.

Estudo de caso: implementar um driver de exibição

Para usar a API que oferece suporte à função de sincronização, desenvolver um driver de exibição com uma função de buffer de exibição. Antes do framework de sincronização, essa função recebia objetos dma-buf, colocava esses buffers na tela e bloqueava enquanto o buffer estava visível. Por exemplo:

/*
 * assumes buffer is ready to be displayed.  returns when buffer is no longer on
 * screen.
 */
void display_buffer(struct dma_buf *buffer);

Com o framework de sincronização, a função display_buffer é mais complexa. Ao colocar um buffer em exibição, ele é associado com um limite que indica quando o buffer estará pronto. Você pode colocar na fila e iniciar o trabalho depois que a cerca for removida.

A fila e a inicialização do trabalho após a limpeza da cerca não bloqueiam nada. Você retorna imediatamente sua própria cerca, o que garante quando o buffer será removido da tela. À medida que você enfileira buffers, o kernel vai listar dependências com o framework de sincronização:

/*
 * displays buffer when fence is signaled.  returns immediately with a fence
 * that signals when buffer is no longer displayed.
 */
struct sync_fence* display_buffer(struct dma_buf *buffer, struct sync_fence
*fence);

Integração da sincronização

Esta seção explica como integrar o framework de sincronização do espaço do kernel com partes do espaço do usuário do framework do Android e os drivers que precisam se comunicar entre si. Os objetos do espaço do kernel são representados como descritores de arquivo no espaço do usuário.

Convenções de integração

Siga as convenções de interface da HAL do Android:

• Se a API fornecer um descritor de arquivo que se refira a um sync_pt, o driver do fornecedor ou o HAL que usa a API precisa fechar o descritor de arquivo.
• Se o driver do fornecedor ou a HAL passar um descritor de arquivo que contenha um sync_pt a uma função da API, o driver do fornecedor ou a HAL não podem feche o descritor do arquivo.
• Para continuar usando o descritor de arquivo de limite, o driver do fornecedor ou o A HAL precisa duplicar o descritor.

Um objeto de limite é renomeado sempre que passa pela BufferQueue. O suporte a cercas do kernel permite que as cercas tenham strings para nomes. Portanto, o framework de sincronização usa o nome da janela e o índice de buffer que está na fila para nomear a cerca, como SurfaceView:0. Isso é útil na depuração para identificar a origem de um impasse, pois os nomes aparecem na saída de /d/sync e relatórios de bugs.

Integração com ANativeWindow

A ANativeWindow é compatível com a cerca. dequeueBuffer, queueBuffer e cancelBuffer têm parâmetros de limite.

Integração do OpenGL ES

A integração da sincronização do OpenGL ES depende de duas extensões EGL:

• O EGL_ANDROID_native_fence_sync oferece uma maneira de unem ou criam descritores de arquivo de limite nativo do Android objetos EGLSyncKHR.
• EGL_ANDROID_wait_sync permite pausas na GPU em vez de no lado da CPU, fazendo com que a GPU aguarde por EGLSyncKHR. A extensão EGL_ANDROID_wait_sync é igual à extensão EGL_KHR_wait_sync.

Para usar essas extensões de forma independente, implemente a EGL_ANDROID_native_fence_sync com as extensões associadas suporte ao kernel. Em seguida, ative a EGL_ANDROID_wait_sync no driver. O EGL_ANDROID_native_fence_sync extensão consiste em um objeto EGLSyncKHR de limite nativo distinto não é válido. Como resultado, as extensões que se aplicam a tipos de objeto EGLSyncKHR não necessariamente se aplicam a objetos EGL_ANDROID_native_fence, evitando interações indesejadas.

A extensão EGL_ANDROID_native_fence_sync usa um atributo correspondente de descritor de arquivo de cerca nativo que pode ser definido apenas no momento da criação e não pode ser consultado diretamente em um objeto de sincronização. Esse atributo pode ser definido em um destes dois modos:

• Um descritor de arquivo de cerca válido envolve um descritor de arquivo de cerca nativo do Android em um objeto EGLSyncKHR.
• -1 cria um descritor de arquivo de limite nativo do Android a partir de uma objeto EGLSyncKHR.

Use a chamada de função DupNativeFenceFD() para extrair o objeto EGLSyncKHR do descritor de arquivo de cerca nativo do Android. Isso tem o mesmo resultado de uma consulta ao atributo set, mas segue a convenção de que o destinatário fecha a cerca (por isso a cópia operação). Por fim, destruir o objeto EGLSyncKHR fecha o atributo de limite interno.

Integração do Hardware Composer

O Hardware Composer processa três tipos de cercas de sincronização:

• Adquirir limites são transmitidos com buffers de entrada para as chamadas setLayerBuffer e setClientTarget. Eles representam uma gravação pendente no buffer e devem sinalizar antes que o O SurfaceFlinger ou o HWC tenta ler o buffer associado para e fazer a composição.
• Os limites de liberação são recuperados após a chamada para presentDisplay usando a chamada de getReleaseFences. Elas representam uma leitura pendente do buffer anterior na mesma camada. Um liberar sinais de limite quando o HWC não estiver mais usando o buffer anterior porque o buffer atual substituiu o anterior na tela. Os limites de liberação são retornados ao app junto com os buffers anteriores que será substituída durante a composição atual. O app precisa esperar até que uma cerca de liberação sinalize antes de gravar novos conteúdos no buffer que foi retornado a ele.
• Limites atuais são retornados, um por frame, como parte da a chamada para presentDisplay. Cercas do presente representam quando composição deste frame foi concluída ou, alternativamente, quando a o resultado da composição do frame anterior não é mais necessário. Para telas físicas, presentDisplay retorna cercas presentes quando o frame atual aparece na tela. Depois que os limites atuais são devolvidos, será seguro gravar novamente no buffer de destino SurfaceFlinger aplicável. Para telas virtuais, as cercas presentes são retornadas quando é seguro ler do buffer de saída.