Drivers da API Neural Networks

Esta página fornece uma visão geral de como implementar uma API Neural Networks (NNAPI). motorista. Para mais detalhes, consulte a documentação da definição de HAL arquivos no hardware/interfaces/neuralnetworks Um exemplo de implementação de driver está frameworks/ml/nn/driver/sample

Para mais informações sobre a API Neural Networks, consulte API Neural Networks.

HAL de redes neurais

A HAL de redes neurais (NN, na sigla em inglês) define uma abstração dos vários dispositivos, como unidades de processamento gráfico (GPUs) e processadores de sinal digital (DSPs), que estão em um produto (por exemplo, um smartphone ou tablet). Os motivadores devem estar em conformidade com a NN HAL. A interface é especificada na HAL de definição de arquivos hardware/interfaces/neuralnetworks

O fluxo geral da interface entre o framework e um driver é mostrado. na figura 1.

Fluxo de redes neurais

Figura 1. Fluxo de redes neurais

Inicialização

Na inicialização, o framework consulta os recursos do driver usando IDevice::getCapabilities_1_3 A estrutura @1.3::Capabilities inclui todos os tipos de dados e representa um desempenho sem relaxamento usando um vetor.

Para determinar como alocar cálculos para os dispositivos disponíveis, o usa os recursos para entender a rapidez e a intensidade com eficiência para que cada driver execute uma execução. Para fornecer essas informações, o driver precisa fornecer números de desempenho padronizados com base na execução de cargas de trabalho de referência.

Para determinar os valores que o driver retorna em resposta a IDevice::getCapabilities_1_3, use o app de comparação da NNAPI para medir a o desempenho dos tipos de dados correspondentes. As versões v1 e v2 do MobileNet, asr_float, e tts_float são recomendados para medir o desempenho de 32 bits os valores de ponto flutuante e os modelos quantizados MobileNet v1 e v2 recomendado para valores quantizados de 8 bits. Para mais informações, consulte Pacote de testes de machine learning do Android

No Android 9 e versões anteriores, a estrutura Capabilities inclui o desempenho do driver. somente para tensores de ponto flutuante e quantizados e não inclui tipos de dados escalares.

Como parte do processo de inicialização, o framework pode consultar mais informações, usando IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, e IDevice::getNumberOfCacheFilesNeeded

Entre as reinicializações do produto, o framework espera todas as consultas descritas neste para sempre informar os mesmos valores de um determinado motorista. Caso contrário, um app usar esse driver pode reduzir a performance ou ter um comportamento incorreto.

Compilação

O framework determina quais dispositivos usar quando receber uma solicitação de um app. No Android 10, os apps podem descobrir e especificar os dispositivos que o framework escolhe. Para mais informações, consulte Descoberta e atribuição de dispositivos.

No momento de compilação do modelo, o framework o envia para cada candidato motorista ligando para IDevice::getSupportedOperations_1_3 Cada driver retorna uma matriz de booleanos indicando quais as operações do modelo. O motorista consegue determinar oferecem suporte a uma determinada operação por vários motivos. Exemplo:

  • O driver não é compatível com o tipo de dados.
  • O driver só é compatível com operações com parâmetros de entrada específicos. Para exemplo, um driver pode oferecer suporte a 3 x 3 e 5 x 5, mas não a convolução 7 x 7 as operações.
  • O driver tem restrições de memória que o impedem de processar gráficos ou entradas.

Durante a compilação, a entrada, a saída e os operandos internos do modelo, conforme descritos em OperandLifeTime, podem ter dimensões ou classificações desconhecidas. Para mais informações, consulte Forma de saída.

O framework instrui cada driver selecionado a se preparar para executar um subconjunto de o modelo chamando IDevice::prepareModel_1_3 Em seguida, cada driver compila o próprio subconjunto. Por exemplo, um motorista pode gerar código ou criar uma cópia reordenada dos pesos. Como pode haver um período significativo entre a compilação do modelo e a de solicitações, recursos como grandes pedaços de memória do dispositivo não devem ser atribuídos durante a compilação.

Se for bem-sucedido, o driver retornará um @1.3::IPreparedModel. cabo Se o driver retornar um código de falha ao preparar seu subconjunto da o framework executa o modelo inteiro na CPU.

Para reduzir o tempo usado para compilação quando um app é iniciado, o motorista pode artefatos de compilação em cache. Para mais informações, consulte Compilação Armazenamento em cache.

Execução

Quando um app pede que o framework execute uma solicitação, ele chama as IPreparedModel::executeSynchronously_1_3 Método HAL por padrão para executar uma execução síncrona em um modelo preparado. Uma solicitação também pode ser executada de forma assíncrona usando o método execute_1_3 , o método executeFenced (consulte Execução limitada), ou executadas usando uma execução de burst.

As chamadas de execução síncrona melhoram o desempenho e reduzem o encadeamento em comparação com chamadas assíncronas porque o controle é retornado ao processo do app somente após a conclusão da execução. Isso significa que o driver não precisa de um mecanismo separado para notificar o processo do aplicativo que até que a execução seja concluída.

Com o método execute_1_3 assíncrono, o controle retorna ao o processo do app após o início da execução, e o motorista precisa notificar framework quando a execução é concluída, usando o @1.3::IExecutionCallback.

O parâmetro Request transmitido ao método de execução lista a entrada e a saída. operandos usados para a execução. A memória que armazena os dados do operando precisa usa a ordem principal da linha com a primeira dimensão iterando a mais lenta e não tem padding no final de qualquer linha. Para mais informações sobre os tipos de operandos, ver Operandos.

Para drivers NN HAL 1.2 ou mais recentes, quando uma solicitação é concluído, o status do erro, o formato da saída e as informações de tempo são retornadas para a estrutura. Durante a execução, os operandos de saída ou internos do modelo podem ter uma ou mais dimensões ou classificação desconhecida. Quando pelo menos uma saída operando tiver uma dimensão ou classificação desconhecida, o motorista precisará retornar informações de saída dimensionadas dinamicamente.

Para drivers com NN HAL 1.1 ou anterior, somente o status de erro é retornado quando um solicitação for concluída. As dimensões dos operandos de entrada e saída precisam ser totalmente especificado para que a execução seja concluída. Operandos internos podem têm uma ou mais dimensões desconhecidas, mas devem ter uma classificação especificada.

Para solicitações de usuários que abrangem vários drivers, a estrutura é responsável por reservando memória intermediária e para sequenciar as chamadas para cada driver.

Várias solicitações podem ser iniciadas em paralelo no mesmo @1.3::IPreparedModel O driver pode executar solicitações em paralelo ou serializar as execuções.

O framework pode pedir que um driver mantenha mais de um modelo preparado. Para exemplo, preparar o modelo m1, preparar m2, executar a solicitação r1 em m1, executar r2 em m2, executar r3 em m1, executar r4 em m2, versão (descrita em Limpar), m1 e liberar m2.

Para evitar uma primeira execução lenta que poderia resultar em uma experiência do usuário ruim (por como a primeira renderização lenta do frame), ele realiza a maioria das inicializações na fase de compilação. A inicialização na primeira execução deve ser limitada a ações que afetam negativamente a integridade do sistema quando realizadas cedo, como reservar grandes buffers temporários ou aumentar a velocidade do clock de um dispositivo. Os impulsionadores que preparam apenas um número limitado de modelos simultâneos podem ter para fazer sua inicialização na primeira execução.

No Android 10 ou versões mais recentes, nos casos em que execuções com o mesmo modelo preparado são executadas em rápida sucessão, o cliente pode optar por usar uma para comunicação entre os processos do app e do driver. Para mais informações, consulte Execuções de burst e filas rápidas de mensagens.

Para melhorar o desempenho de várias execuções em rápida sucessão, o impulsionador pode manter buffers temporários ou aumentar as velocidades do clock. Como criar um watchdog a linha de execução é recomendada para liberar recursos se nenhuma nova solicitação for criada após por um período fixo.

Forma da saída

Para solicitações em que um ou mais operandos de saída não têm todas as dimensões especificado, o driver precisa fornecer uma lista de formas de saída contendo o informações de dimensão para cada operando de saída após a execução. Para mais informações sobre dimensões, consulte OutputShape

Se uma execução falhar devido a um buffer de saída menor que o tamanho, o driver vai precisar indicam quais operandos de saída têm tamanho de buffer insuficiente na lista de formatos de saída e deve relatar o máximo de informações dimensionais possível, usando zero para dimensões desconhecidas.

Marcação de tempo

No Android 10, um app pode solicitar a execução se o app especificou um único dispositivo para ser usado durante o processo de compilação. Para detalhes, consulte MeasureTiming e Descoberta e atribuição de dispositivos. Nesse caso, um O driver NN HAL 1.2 precisa medir a duração da execução ou informar UINT64_MAX (para indicar que a duração não está disponível) ao executar uma solicitação. O motorista deve minimizar as penalidades de desempenho resultantes da medição da execução. duração

O driver informa as seguintes durações em microssegundos no Timing estrutura:

  • Tempo de execução no dispositivo: não inclui o tempo de execução no que é executado no processador host.
  • Tempo de execução no driver:inclui o tempo de execução no dispositivo.

Essas durações precisam incluir o tempo em que a execução fica suspensa, por exemplo, quando a execução tiver sido interrompida por outras tarefas ou quando ela for aguardando a disponibilização de um recurso.

Quando o motorista não precisa medir a duração da execução ou quando houver um erro de execução, o driver precisará informar as durações como UINT64_MAX: Mesmo quando o motorista precisa medir a execução ele pode informar UINT64_MAX para tempo no dispositivo, tempo no ou ambos. Quando o motorista informa as duas durações como um valor diferente UINT64_MAX, o tempo de execução no driver precisa ser igual ou maior que o tempo em o dispositivo.

Execução cercada

No Android 11, a NNAPI permite que as execuções aguardem uma lista de identificadores sync_fence e, opcionalmente, retornar um objeto sync_fence, que é sinalizado quando a execução é concluída. Isso reduz a sobrecarga para modelos sequenciais e casos de uso de streaming. A execução cercada também permite mais uma interoperabilidade eficiente com outros componentes que podem sinalizar ou esperar sync_fence: Para mais informações sobre sync_fence, consulte Framework de sincronização.

Em uma execução cercada, o framework chama o IPreparedModel::executeFenced para iniciar uma execução assíncrona e limitada em um modelo preparado com uma é um vetor de limites de sincronização para esperar. Se a tarefa assíncrona for concluída antes a chamada retornar, um identificador vazio poderá ser retornado para sync_fence. Um O objeto IFencedExecutionCallback também precisa ser retornado para permitir que o framework para consultar informações de duração e status de erro.

Após a conclusão de uma execução, os dois valores de timing medir a duração da execução pode ser consultada por IFencedExecutionCallback::getExecutionInfo.

  • timingLaunched: Duração entre a chamada de executeFenced e o momento em que executeFenced sinaliza o syncFence retornado.
  • timingFenced: Duração de quando todos os limites de sincronização que a execução espera serão sinalizadas quando executeFenced indicar o syncFence retornado.

Fluxo de controle

Para dispositivos com o Android 11 ou mais recente, a NNAPI inclui duas operações de fluxo de controle, IF e WHILE, que usam outros modelos como argumentos e os execute condicionalmente (IF) ou repetidamente (WHILE). Para mais informações sobre como fazer isso, consulte Fluxo de controle.

Qualidade de serviço

No Android 11, a NNAPI inclui uma qualidade aprimorada do Google (QoS) ao permitir que um aplicativo indique as prioridades relativas de modelos, o tempo máximo esperado para um modelo ser preparado e o tempo máximo esperado para que uma execução seja concluída. Para mais informações, consulte Qualidade de Serviço.

Limpeza

Quando um app termina de usar um modelo preparado, o framework é liberado sua referência ao @1.3::IPreparedModel objeto. Quando o objeto IPreparedModel não estiver mais referenciado, ele será destruídos automaticamente no serviço do driver que o criou. Específico do modelo os recursos podem ser recuperados, no momento, na implementação do driver destruidor. Se o serviço do motorista quiser que o objeto IPreparedModel seja destruído automaticamente quando não for mais necessário para o cliente, ele não poderá conter qualquer referência ao objeto IPreparedModel depois do IPreparedeModel foi retornado por meio de IPreparedModelCallback::notify_1_3.

Uso da CPU

Os drivers precisam usar a CPU para configurar cálculos. Motoristas não devem usar a CPU para fazer cálculos de gráfico, porque isso interfere na capacidade do framework de alocar corretamente o trabalho. O motorista precisa informar partes que ele não pode processar no framework e deixar que ele lide com descansar.

A biblioteca fornece uma implementação de CPU para todas as operações da NNAPI, exceto para as operações definidas pelo fornecedor. Para mais informações, consulte Extensões de fornecedor.

A operações introduzidas no Android 10 (nível 29 da API) ter apenas uma implementação de CPU de referência para verificar se os testes CTS e VTS estão corretas. Implementações otimizadas incluídas no machine learning para dispositivos móveis têm preferência sobre a implementação de CPU da NNAPI.

Funções utilitárias

A base de código da NNAPI inclui funções utilitárias que podem ser usadas pelo driver serviços.

A frameworks/ml/nn/common/include/Utils.h contém diversas funções utilitárias, como as usadas para registro e para a conversão entre diferentes versões da NN HAL.

  • VLogging: VLOG é uma macro wrapper no LOG do Android que apenas registra a mensagem se a tag apropriada estiver definida no debug.nn.vlog . initVLogMask() precisa ser chamado antes de qualquer chamada para VLOG. A macro VLOG_IS_ON pode ser usado para verificar se VLOG está ativado no momento, o que permite uma geração de registros complicada. que o código seja ignorado, caso não seja necessário. O valor da propriedade deve ser uma das seguintes opções:

    • Uma string vazia, indicando que nenhum registro será feito.
    • O token 1 ou all, indicando que toda a geração de registros precisa ser realizada.
    • Uma lista de tags, delimitadas por espaços, vírgulas ou dois-pontos. indicando qual registro deve ser feito. As tags são compilation, cpuexe, driver, execution, manager e model.

  • compliantWithV1_*: retorna true se um objeto NN HAL puder ser convertido para o mesmo tipo de uma versão diferente da HAL sem perder informações. Para Por exemplo, chamar compliantWithV1_0 em uma V1_2::Model retorna false se o modelo inclui tipos de operação introduzidos na NN HAL 1.1 ou NN HAL 1.2.

  • convertToV1_*: converte um objeto da NN HAL de uma versão em outra. Um aviso é registrado se a conversão resultar na perda de informações (que caso a nova versão do tipo não possa representar totalmente o valor).

  • Recursos: nonExtensionOperandPerformance e update podem ser usadas para ajudar a criar Capabilities::operandPerformance .

  • Propriedades de consulta de tipos: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar. tensorHasUnspecifiedDimensions.

A frameworks/ml/nn/common/include/ValidateHal.h O arquivo contém funções utilitárias para validar se um objeto NN HAL é válido de acordo com as especificações da versão da HAL.

  • validate*: retorna true se o objeto NN HAL for válido de acordo com as especificações da versão da HAL. Tipos de OEM e de extensão não são validados. Por exemplo, validateModel retorna false se a O modelo contém uma operação que faz referência a um índice de operandos que não ou uma operação que não tem suporte nessa versão da HAL.

A frameworks/ml/nn/common/include/Tracing.h arquivo contém macros para simplificar a adição systracing para o código das redes neurais. Para ver um exemplo, consulte as invocações da macro NNTRACE_* na exemplo de driver.

A frameworks/ml/nn/common/include/GraphDump.h contém uma função utilitária para despejar o conteúdo de um Model em gráficos para fins de depuração.

  • graphDump: grava uma representação do modelo no Graphviz. (.dot) para o stream especificado (se fornecido) ou para o logcat (se nenhum stream é fornecido).

Validação

Para testar sua implementação da NNAPI, use os testes VTS e CTS incluídos em framework do Android. O VTS treina os motoristas diretamente (sem usar o enquanto o CTS os exercita indiretamente por meio desse framework. Esses testar cada método de API e verificar se todas as operações suportadas pela funcionam corretamente e fornecem resultados que atendem aos requisitos de precisão.

Os requisitos de precisão no CTS e VTS para a NNAPI são os seguintes:

  • Ponto flutuante: abs(esperado - real) <= atol + rtol * abs(esperado); em que:

    • Para fp32, atol = 1e-5f, rtol = 5.0f * 1,1920928955078125e-7
    • Para fp16, atol = rtol = 5.0f * 0.0009765625f

  • Quantized:separados por um (exceto para mobilenet_quantized, que é uma diferença de três)

  • Booleano:correspondência exata

Uma maneira de o CTS testar a NNAPI é gerando gráficos pseudoaleatórios fixos usada para testar e comparar os resultados da execução de cada driver com o implementação de referência da NNAPI. Para drivers com NN HAL 1.2 ou superior, se o resultados não atendem aos critérios de precisão, o CTS relata um erro e despeja uma do modelo com falha em /data/local/tmp para depuração. Para mais detalhes sobre os critérios de precisão, consulte TestRandomGraph.cpp e TestHarness.h

Teste de fuzz

O objetivo do teste de fuzz é encontrar falhas, declarações, violações de memória ou comportamento indefinido geral no código em teste devido a fatores como entradas inesperadas. Para testes de fuzz da NNAPI, o Android usa testes baseados em libFuzzer, que são eficientes no fuzzing porque usam a cobertura de linha dos casos de teste anteriores para gerar novas entradas aleatórias. Por exemplo, o libFuzzer favorece casos de teste que são executados em novas linhas de código. Isso reduz bastante o tempo que os testes levam para encontrar código problemático.

Para realizar um teste de fuzz e validar a implementação do driver, modifique frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp no utilitário de teste libneuralnetworks_driver_fuzzer encontrado no AOSP para incluir código do driver. Para mais informações sobre o teste de fuzz da NNAPI, consulte frameworks/ml/nn/runtime/test/android_fuzzing/README.md

Segurança

Como os processos do app se comunicam diretamente com o processo do motorista, os drivers precisam validar os argumentos das chamadas recebidas. Essa validação é verificada pelo VTS. O código de validação está no frameworks/ml/nn/common/include/ValidateHal.h

Os motoristas também devem garantir que os aplicativos não interfiram em outros apps ao usar o mesmo dispositivo.

Pacote de testes de machine learning do Android

O Android Machine Learning Test Suite (MLTS) é um comparativo de mercado da NNAPI incluído em CTS e VTS para validar a precisão de modelos reais em dispositivos de fornecedores. A o comparativo de mercado avalia a latência e a acurácia e compara resultados com os resultados usando TF Lite em execução na CPU para o mesmo modelo e conjuntos de dados. Isso garante que a precisão do motorista não seja pior do que a implementação de referência da CPU.

Os desenvolvedores da Plataforma Android também usam o MLTS para avaliar a latência e a acurácia de motoristas.

O comparativo de mercado da NNAPI pode ser encontrado em dois projetos no AOSP:

Modelos e conjuntos de dados

O comparativo de mercado da NNAPI usa os modelos e conjuntos de dados a seguir.

  • Os pontos flutuantes MobileNetV1 e u8 quantizados em diferentes tamanhos, são executados em um subconjunto pequeno (1.500 imagens) do conjunto de dados Open Images v4.
  • Os pontos flutuantes MobileNetV2 e u8 quantizados em diferentes tamanhos, são executados em uma subconjunto pequeno (1.500 imagens) do conjunto de dados Open Images v4.
  • Modelo acústico de longa duração com base em memória de curto prazo (LSTM, na sigla em inglês) para conversão de texto em voz. são executados em um pequeno subconjunto do conjunto do CMU Arctic.
  • Modelo acústico com base em LSTM para reconhecimento automático de fala, executado um pequeno subconjunto do conjunto de dados do LibriSpeech.

Para saber mais, consulte platform/test/mlts/models.

Teste de estresse

O Android Machine Learning Test Suite inclui uma série de testes de falhas para para validar a resiliência dos motoristas sob condições intensas de uso ou em cantos os casos de clientes do seu modelo.

Todos os testes de falha oferecem os seguintes recursos:

  • Detecção de suspensão: se o cliente NNAPI trava durante um teste, o O teste falha com o motivo da falha HANG e o pacote de testes. passa para o próximo teste.
  • Detecção de falha do cliente NNAPI: testes sobrevivem a falhas e testes do cliente falhar com o motivo CRASH.
  • Detecção de acidente de motorista:os testes podem detectar um acidente de motorista. que causa uma falha em uma chamada da NNAPI. Pode haver falhas processos de driver que não causem uma falha da NNAPI e não causem o teste a falhar. Para cobrir esse tipo de falha, é recomendável executar o tail no registro do sistema para erros ou falhas relacionadas ao driver.
  • Segmentação de todos os aceleradores disponíveis: os testes são executados em todos os dos motoristas disponíveis.

Todos os testes de falha têm os quatro resultados possíveis a seguir:

  • SUCCESS: execução concluída sem erro.
  • FAILURE: falha na execução. Normalmente, causada por uma falha quando testar um modelo, indicando que o driver falhou ao compilar ou executar o modelo.
  • HANG: o processo de teste deixou de responder.
  • CRASH: o processo de teste falhou.

Para mais informações sobre testes de estresse e uma lista completa de testes de falha, consulte platform/test/mlts/benchmark/README.txt

Usar o MLTS

Para usar o MLTS:

  1. Conecte um dispositivo de destino à estação de trabalho e verifique acessível por meio de adb padrão. Exportar o dispositivo de destino ANDROID_SERIAL variável de ambiente se mais de um dispositivo estiver conectado.

  2. cd no diretório de origem de nível superior do Android.

    source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh

    Ao final de uma execução de comparativo de mercado, os resultados são apresentados como uma página HTML e transmitidas para xdg-open.

Para saber mais, consulte platform/test/mlts/benchmark/README.txt.

Versões da HAL de redes neurais

Esta seção descreve as mudanças introduzidas no Android e nos sistemas neurais Versões da HAL de redes.

Android 11

O Android 11 introduz a NN HAL 1.3, que inclui a após mudanças importantes.

  • Compatibilidade com quantização de 8 bits assinada na NNAPI. Adiciona o TENSOR_QUANT8_ASYMM_SIGNED operando. Drivers com NN HAL 1.3 compatíveis as operações com quantização não assinada também precisam oferecer suporte às variantes assinadas dessas operações. Ao executar as versões assinadas e não assinadas da maioria operações quantizadas, os motoristas devem produzir os mesmos resultados até com um deslocamento de 128. Há cinco exceções a esse requisito: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2 e QUANTIZED_16BIT_LSTM. A operação QUANTIZED_16BIT_LSTM não é compatível com operandos assinados e as outras quatro operações aceitam quantização assinada, mas não exigem resultados sejam os mesmos.
  • Suporte para execuções delimitadas em que o framework chama o IPreparedModel::executeFenced para iniciar uma execução assíncrona e limitada em um modelo preparado com uma é um vetor de limites de sincronização para esperar. Para mais informações, consulte Execução limitada.
  • Suporte para fluxo de controle. Adiciona as operações IF e WHILE, que usam outros modelos como argumentos e os executa condicionalmente (IF) ou repetidamente (WHILE). Para mais informações, consulte Fluxo de controle.
  • Melhor qualidade de serviço (QoS), já que os apps podem indicar o prioridades dos modelos, o máximo de tempo esperado para um precisa ser preparado e a quantidade máxima de tempo esperada para uma para que a execução seja concluída. Para mais informações, consulte Qualidade de Serviço.
  • Suporte a domínios de memória que fornecem interfaces de alocação para e buffers gerenciados pelo driver. Isso permite transmitir memórias nativas do dispositivo entre execuções, suprimindo cópias e transformações desnecessárias dos dados entre execuções consecutivas do mesmo motorista. Para mais informações, consulte Domínios de memória.

Android 10

O Android 10 apresenta a NN HAL 1.2, que inclui a após mudanças importantes.

  • O struct Capabilities inclui todos os tipos de dados, incluindo dados escalares tipos de dados diferentes e representa o desempenho sem relaxamento usando um vetor do que os campos nomeados.
  • Os métodos getVersionString e getType permitem que o framework recuperam o tipo de dispositivo (DeviceType) e as informações de versão. Consulte Descoberta e atribuição de dispositivos.
  • O método executeSynchronously é chamado por padrão para executar uma de maneira síncrona. O método execute_1_2 instrui o framework a executar uma execução de forma assíncrona. Consulte Execução.
  • O parâmetro MeasureTiming para executeSynchronously, execute_1_2 e a execução de burst especifica se o driver precisa medir a execução. duração Os resultados são informados na estrutura Timing. Consulte Tempo.
  • Suporte a execuções em que um ou mais operandos de saída têm um valor desconhecido. dimensão ou classificação. Consulte Forma de saída.
  • Suporte para extensões de fornecedor, que são coleções de objetos definidos pelo fornecedor operações e tipos de dados. O motorista informa as extensões compatíveis com o o método IDevice::getSupportedExtensions. Consulte Extensões de fornecedor.
  • A capacidade de um objeto de burst controlar um conjunto de execuções de burst usando filas rápidas de mensagens (FMQs, na sigla em inglês) para comunicação entre aplicativo e driver e reduzir a latência. Consulte Execuções de burst e filas rápidas de mensagens.
  • Suporte a AHardwareBuffer para permitir que o driver execute execuções sem copiar dados. Consulte AHardwareBuffer (link em inglês).
  • Melhoria na compatibilidade com armazenamento em cache de artefatos de compilação para reduzir o tempo usada para compilação quando um app é iniciado. Consulte Armazenamento de compilação em cache.

O Android 10 introduz os tipos de operando e as operações.

  • Tipos de operandos

    • ANEURALNETWORKS_BOOL
    • ANEURALNETWORKS_FLOAT16
    • ANEURALNETWORKS_TENSOR_BOOL8
    • ANEURALNETWORKS_TENSOR_FLOAT16
    • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
    • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL

  • Operações

    • ANEURALNETWORKS_ABS
    • ANEURALNETWORKS_ARGMAX
    • ANEURALNETWORKS_ARGMIN
    • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
    • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
    • ANEURALNETWORKS_CAST
    • ANEURALNETWORKS_CHANNEL_SHUFFLE
    • ANEURALNETWORKS_DETECTION_POSTPROCESSING
    • ANEURALNETWORKS_EQUAL
    • ANEURALNETWORKS_EXP
    • ANEURALNETWORKS_EXPAND_DIMS
    • ANEURALNETWORKS_GATHER
    • ANEURALNETWORKS_GENERATE_PROPOSALS
    • ANEURALNETWORKS_GREATER
    • ANEURALNETWORKS_GREATER_EQUAL
    • ANEURALNETWORKS_GROUPED_CONV_2D
    • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
    • ANEURALNETWORKS_INSTANCE_NORMALIZATION
    • ANEURALNETWORKS_LESS
    • ANEURALNETWORKS_LESS_EQUAL
    • ANEURALNETWORKS_LOG
    • ANEURALNETWORKS_LOGICAL_AND
    • ANEURALNETWORKS_LOGICAL_NOT
    • ANEURALNETWORKS_LOGICAL_OR
    • ANEURALNETWORKS_LOG_SOFTMAX
    • ANEURALNETWORKS_MAXIMUM
    • ANEURALNETWORKS_MINIMUM
    • ANEURALNETWORKS_NEG
    • ANEURALNETWORKS_NOT_EQUAL
    • ANEURALNETWORKS_PAD_V2
    • ANEURALNETWORKS_POW
    • ANEURALNETWORKS_PRELU
    • ANEURALNETWORKS_QUANTIZE
    • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
    • ANEURALNETWORKS_RANDOM_MULTINOMIAL
    • ANEURALNETWORKS_REDUCE_ALL
    • ANEURALNETWORKS_REDUCE_ANY
    • ANEURALNETWORKS_REDUCE_MAX
    • ANEURALNETWORKS_REDUCE_MIN
    • ANEURALNETWORKS_REDUCE_PROD
    • ANEURALNETWORKS_REDUCE_SUM
    • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
    • ANEURALNETWORKS_ROI_ALIGN
    • ANEURALNETWORKS_ROI_POOLING
    • ANEURALNETWORKS_RSQRT
    • ANEURALNETWORKS_SELECT
    • ANEURALNETWORKS_SIN
    • ANEURALNETWORKS_SLICE
    • ANEURALNETWORKS_SPLIT
    • ANEURALNETWORKS_SQRT
    • ANEURALNETWORKS_TILE
    • ANEURALNETWORKS_TOPK_V2
    • ANEURALNETWORKS_TRANSPOSE_CONV_2D
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

O Android 10 introduz atualizações para vários dos as operações. As atualizações são está relacionada principalmente ao seguinte:

  • Suporte para o layout de memória NCHW
  • Suporte a tensores com classificação diferente de 4 em softmax e operações de normalização
  • Suporte para convoluções dilatadas
  • Suporte para entradas com quantização mista em ANEURALNETWORKS_CONCATENATION

A lista abaixo mostra as operações que foram modificadas Android 10 Para total detalhes das alterações, consulte OperationCode (link em inglês) na documentação de referência da NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

Android 9

A NN HAL 1.1 foi introduzida no Android 9 e inclui as seguintes mudanças.

  • IDevice::prepareModel_1_1 inclui um ExecutionPreference . Um motorista pode usar isso para ajustar a preparação, sabendo que o app prefere economizar bateria ou executará o modelo em chamadas sucessivas rápidas.
  • Foram adicionadas nove operações novas: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB e TRANSPOSE.
  • Um aplicativo pode especificar que cálculos de flutuação de 32 bits podem ser executados usar intervalo flutuante de 16 bits e/ou precisão definindo Model.relaxComputationFloat32toFloat16 para true. O Capabilities O struct tem o campo adicional relaxedFloat32toFloat16Performance. Portanto, para que o driver possa relatar seu desempenho reduzido ao framework.

Android 8.1

A HAL de redes neurais inicial (1.0) foi lançada no Android 8.1. Para mais informações, consulte /neuralnetworks/1.0/