Pools de memória

Esta página descreve as estruturas de dados e métodos usados ​​para comunicar eficientemente os buffers de operandos entre o driver e a estrutura.

No momento da compilação do modelo, o framework fornece os valores dos operandos constantes ao driver. Dependendo do tempo de vida do operando constante, seus valores estão localizados em um vetor HIDL ou em um conjunto de memória compartilhada.

  • Se o tempo de vida for CONSTANT_COPY , os valores estarão localizados no campo operandValues ​​da estrutura do modelo. Como os valores no vetor HIDL são copiados durante a comunicação entre processos (IPC), isso normalmente é usado apenas para armazenar uma pequena quantidade de dados, como operandos escalares (por exemplo, o escalar de ativação em ADD ) e pequenos parâmetros de tensor (por exemplo, o tensor de forma em RESHAPE ).
  • Se o tempo de vida for CONSTANT_REFERENCE , os valores estarão localizados no campo pools da estrutura do modelo. Apenas os identificadores dos conjuntos de memória compartilhada são duplicados durante o IPC, em vez de copiar os valores brutos. Portanto, é mais eficiente manter uma grande quantidade de dados (por exemplo, os parâmetros de peso em convoluções) usando conjuntos de memória compartilhada do que vetores HIDL.

No tempo de execução do modelo, o framework fornece os buffers dos operandos de entrada e saída para o driver. Ao contrário das constantes de tempo de compilação que podem ser enviadas em um vetor HIDL, os dados de entrada e saída de uma execução são sempre comunicados por meio de uma coleção de conjuntos de memória.

O tipo de dados hidl_memory é usado tanto na compilação quanto na execução para representar um conjunto de memória compartilhada não mapeado. O driver deve mapear a memória adequadamente para torná-la utilizável com base no nome do tipo de dados hidl_memory . Os nomes de memória suportados são:

  • ashmem : memória compartilhada do Android. Para obter mais detalhes, consulte memória .
  • mmap_fd : Memória compartilhada apoiada por um descritor de arquivo por meio de mmap .
  • hardware_buffer_blob : Memória compartilhada apoiada por um AHardwareBuffer com o formato AHARDWARE_BUFFER_FORMAT_BLOB . Disponível em Redes Neurais (NN) HAL 1.2. Para obter mais detalhes, consulte AHardwareBuffer .
  • hardware_buffer : Memória compartilhada apoiada por um AHardwareBuffer geral que não usa o formato AHARDWARE_BUFFER_FORMAT_BLOB . O buffer de hardware do modo não BLOB é suportado apenas na execução do modelo. Disponível a partir de NN HAL 1.2. Para obter mais detalhes, consulte AHardwareBuffer .

A partir do NN HAL 1.3, o NNAPI oferece suporte a domínios de memória que fornecem interfaces de alocador para buffers gerenciados por driver. Os buffers gerenciados por driver também podem ser usados ​​como entradas ou saídas de execução. Para obter mais detalhes, consulte Domínios de memória .

Os drivers NNAPI devem dar suporte ao mapeamento de nomes de memória ashmem e mmap_fd . A partir do NN HAL 1.3, os drivers também devem suportar o mapeamento de hardware_buffer_blob . O suporte para hardware_buffer e domínios de memória de modo não BLOB geral é opcional.

AHardwareBuffer

AHardwareBuffer é um tipo de memória compartilhada que envolve um buffer Gralloc . No Android 10, a Neural Networks API (NNAPI) é compatível com o uso de AHardwareBuffer , permitindo que o driver realize execuções sem copiar dados, o que melhora o desempenho e o consumo de energia dos aplicativos. Por exemplo, uma pilha HAL de câmera pode passar objetos AHardwareBuffer para o NNAPI para cargas de trabalho de aprendizado de máquina usando identificadores AHardwareBuffer gerados por NDK de câmera e APIs de NDK de mídia. Para obter mais informações, consulte ANeuralNetworksMemory_createFromAHardwareBuffer .

Os objetos AHardwareBuffer usados ​​na NNAPI são passados ​​para o driver por meio de uma estrutura hidl_memory chamada hardware_buffer ou hardware_buffer_blob . A estrutura hidl_memory hardware_buffer_blob representa apenas objetos AHardwareBuffer com o formato AHARDWAREBUFFER_FORMAT_BLOB .

As informações exigidas pela estrutura são codificadas no campo hidl_handle da estrutura hidl_memory . O campo hidl_handle envolve native_handle , que codifica todos os metadados necessários sobre o buffer AHardwareBuffer ou Gralloc.

O driver deve decodificar corretamente o campo hidl_handle fornecido e acessar a memória descrita por hidl_handle . Quando o getSupportedOperations_1_2 , getSupportedOperations_1_1 ou getSupportedOperations é chamado, o driver deve detectar se pode decodificar o hidl_handle fornecido e acessar a memória descrita por hidl_handle . A preparação do modelo deve falhar se o campo hidl_handle usado para um operando constante não for compatível. A execução deve falhar se o campo hidl_handle usado para um operando de entrada ou saída da execução não for compatível. É recomendado que o driver retorne um código de erro GENERAL_FAILURE se a preparação ou execução do modelo falhar.

Domínios de memória

Para dispositivos que executam o Android 11 ou superior, a NNAPI é compatível com domínios de memória que fornecem interfaces de alocação para buffers gerenciados por driver. Isso permite a passagem de memórias nativas do dispositivo entre as execuções, suprimindo a cópia e a transformação de dados desnecessárias entre execuções consecutivas no mesmo driver. Este fluxo é ilustrado na Figura 1.

Buffer de fluxo de dados com e sem domínios de memória
Figura 1. Fluxo de dados de buffer usando domínios de memória

O recurso de domínio de memória destina-se a tensores que são principalmente internos ao driver e não precisam de acesso frequente no lado do cliente. Exemplos de tais tensores incluem os tensores de estado em modelos de sequência. Para tensores que precisam de acesso frequente à CPU no lado do cliente, é preferível usar pools de memória compartilhada.

Para oferecer suporte ao recurso de domínio de memória, implemente IDevice::allocate para permitir que a estrutura solicite alocação de buffer gerenciada por driver. Durante a alocação, a estrutura fornece as seguintes propriedades e padrões de uso para o buffer:

  • BufferDesc descreve as propriedades necessárias do buffer.
  • BufferRole descreve o padrão de uso potencial do buffer como uma entrada ou saída de um modelo preparado. Várias funções podem ser especificadas durante a alocação do buffer e o buffer alocado pode ser usado apenas como essas funções especificadas.

O buffer alocado é interno ao driver. Um driver pode escolher qualquer localização de buffer ou layout de dados. Quando o buffer é alocado com sucesso, o cliente do driver pode fazer referência ou interagir com o buffer usando o token retornado ou o objeto IBuffer .

O token de IDevice::allocate é fornecido ao fazer referência ao buffer como um dos objetos MemoryPool na estrutura Request de uma execução. Para evitar que um processo tente acessar o buffer alocado em outro processo, o driver deve aplicar a validação adequada em cada uso do buffer. O driver deve validar que o uso do buffer é uma das funções BufferRole fornecidas durante a alocação e deve falhar na execução imediatamente se o uso for ilegal.

O objeto IBuffer é usado para cópia de memória explícita. Em determinadas situações, o cliente do driver deve inicializar o buffer gerenciado por driver de um conjunto de memórias compartilhadas ou copiar o buffer para um conjunto de memórias compartilhadas. Exemplos de casos de uso incluem:

  • Inicialização do tensor de estado
  • Cache de resultados intermediários
  • Execução de fallback na CPU

Para oferecer suporte a esses casos de uso, o driver deve implementar IBuffer::copyTo e IBuffer::copyFrom com ashmem , mmap_fd e hardware_buffer_blob se ele suportar alocação de domínio de memória. É opcional para o driver suportar hardware_buffer de modo não BLOB .

Durante a alocação de buffer, as dimensões do buffer podem ser deduzidas dos operandos de modelo correspondentes de todas as funções especificadas por BufferRole e as dimensões fornecidas em BufferDesc . Com todas as informações dimensionais combinadas, o buffer pode ter dimensões ou classificação desconhecidas. Nesse caso, o buffer está em um estado flexível onde as dimensões são fixas quando usadas como entrada do modelo e em um estado dinâmico quando usadas como saída do modelo. O mesmo buffer pode ser usado com diferentes formatos de saídas em diferentes execuções e o driver deve tratar o redimensionamento do buffer adequadamente.

O domínio da memória é um recurso opcional. Um driver pode determinar que não pode dar suporte a uma determinada solicitação de alocação por vários motivos. Por exemplo:

  • O buffer solicitado tem um tamanho dinâmico.
  • O driver tem restrições de memória que o impedem de manipular buffers grandes.

É possível que vários threads diferentes leiam do buffer gerenciado pelo driver simultaneamente. Acessar o buffer simultaneamente para gravação ou leitura/gravação é indefinido, mas não deve travar o serviço de driver ou bloquear o chamador indefinidamente. O driver pode retornar um erro ou deixar o conteúdo do buffer em estado indeterminado.