O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Drivers de API de redes neurais

Esta página fornece uma visão geral de como implementar um driver Neural Networks API (NNAPI). Para mais detalhes, consulte a documentação encontrada nos arquivos de definição de HAL em hardware/interfaces/neuralnetworks . Uma implementação do controlador de amostra é em frameworks/ml/nn/driver/sample .

Para mais informações sobre a API Redes Neurais, consulte API Redes Neurais .

Redes Neurais HAL

A Neural Networks (NN) HAL define uma abstracção dos diferentes dispositivos, tais como unidades de processamento gráfico (GPUs) e processadores de sinal digitais (DSPs), que estão em um produto (por exemplo, um telefone ou comprimido). Os drivers para esses dispositivos devem estar em conformidade com o NN HAL. A interface é especificado nos arquivos de definição HAL em hardware/interfaces/neuralnetworks .

O fluxo geral da interface entre a estrutura e um driver é ilustrado na figura 1.

Fluxo de redes neurais

Fluxo Figura 1. Neural Networks

Inicialização

Na inicialização, o quadro consulta o driver para as suas capacidades usando IDevice::getCapabilities_1_3 . O @1.3::Capabilities estrutura inclui todos os tipos de dados e representa desempenho nonrelaxed utilizando um vector.

Para determinar como alocar cálculos para os dispositivos disponíveis, a estrutura usa os recursos para compreender a rapidez e a eficiência energética de cada driver pode executar uma execução. Para fornecer essas informações, o driver deve 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 , usar o aplicativo NNAPI referência para medir o desempenho de tipos de dados correspondente. O MobileNet v1 e v2, asr_float , e tts_float modelos são recomendados para medir o desempenho para valores de ponto flutuante de 32-bit e o MobileNet v1 e v2 quantificados modelos são recomendados para 8 bits quantizado valores. Para mais informações, consulte Máquina Android Aprendizagem Test Suite .

No Android 9 e inferior, o Capabilities estrutura inclui informação do desempenho do condutor apenas para ponto e tensores quantificados flutuante e não inclui tipos de dados escalares.

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

Entre as reinicializações do produto, a estrutura espera que todas as consultas descritas nesta seção sempre relatem os mesmos valores para um determinado driver. Caso contrário, um aplicativo que usa esse driver pode apresentar desempenho reduzido ou comportamento incorreto.

Compilação

A estrutura determina quais dispositivos usar ao receber uma solicitação de um aplicativo. No Android 10, os aplicativos podem descobrir e especificar os dispositivos que a estrutura escolhe. Para mais informações, consulte Device Discovery e Atribuição .

Em tempo de compilação modelo, o quadro envia o modelo para cada motorista candidato chamando IDevice::getSupportedOperations_1_3 . Cada driver retorna uma matriz de booleanos indicando quais operações do modelo são suportadas. Um driver pode determinar que não oferece suporte a uma determinada operação por vários motivos. Por exemplo:

  • O driver não suporta o tipo de dados.
  • O driver só oferece suporte a operações com parâmetros de entrada específicos. Por exemplo, um driver pode suportar 3x3 e 5x5, mas não operações de convolução 7x7.
  • O driver tem restrições de memória que o impedem de lidar com grandes gráficos ou entradas.

Durante a compilação, a entrada, a saída, e operandos internas do modelo, tal como descrito em OperandLifeTime , pode ter dimensões desconhecidas ou classificação. Para mais informações, consulte forma de saída .

O quadro instrui cada condutor selecionado para preparar a execução de um subconjunto do modelo chamando IDevice::prepareModel_1_3 . Cada driver então compila seu subconjunto. Por exemplo, um driver pode gerar código ou criar uma cópia reordenada dos pesos. Como pode haver uma quantidade significativa de tempo entre a compilação do modelo e a execução das solicitações, recursos como grandes blocos de memória do dispositivo não devem ser atribuídos durante a compilação.

Em caso de sucesso, o driver retorna um @1.3::IPreparedModel alça. Se o driver retorna um código de falha ao preparar seu subconjunto do modelo, o framework executa o modelo inteiro na CPU.

Para reduzir o tempo usado para compilação quando um aplicativo é iniciado, um driver pode armazenar em cache os artefatos de compilação. Para mais informações, consulte Compilação Caching .

Execução

Quando um aplicativo pede a estrutura para executar um pedido, o quadro chama a IPreparedModel::executeSynchronously_1_3 método HAL por padrão para executar uma execução síncrona em um modelo preparado. A solicitação também pode ser executado de forma assíncrona usando o execute_1_3 método, o executeFenced método (veja execução Cercado ), ou executado usando uma execução explosão .

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

Com a assíncrona execute_1_3 método, o controle retorna para o processo de aplicação após a execução já começou, eo motorista deve notificar o quadro quando a execução for concluída, utilizando o @1.3::IExecutionCallback .

O Request parâmetro passado para as listas método execute os operandos de entrada e saída utilizados para a execução. A memória que armazena os dados do operando deve usar a ordem da linha principal com a primeira dimensão iterando a mais lenta e não ter preenchimento no final de qualquer linha. Para mais informações sobre os tipos de operandos, ver Operandos .

Para NN HAL 1.2 ou superior motoristas, quando uma solicitação é concluída, o status de erro, forma de saída e informações tempo são devolvidos ao quadro. Durante a execução, a saída ou operandos internos do modelo podem ter uma ou mais dimensões desconhecidas ou classificação desconhecida. Quando pelo menos um operando de saída tem uma dimensão ou classificação desconhecida, o driver deve retornar informações de saída dimensionadas dinamicamente.

Para drivers com NN HAL 1.1 ou inferior, apenas o status de erro é retornado quando uma solicitação é concluída. As dimensões dos operandos de entrada e saída devem ser totalmente especificadas para que a execução seja concluída com êxito. Os operandos internos podem ter uma ou mais dimensões desconhecidas, mas devem ter uma classificação especificada.

Para solicitações de usuários que abrangem vários drivers, o framework é responsável por reservar memória intermediária e por 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.

A estrutura pode pedir a um driver para manter mais de um modelo preparado. Por exemplo, preparar modelo m1 , preparar m2 , executar o pedido r1 em m1 , executar r2 em m2 , executar r3 em m1 , executar r4 em m2 , de libertação (descrito em Limpeza ) m1 , e libertação m2 .

Para evitar uma primeira execução lenta que poderia resultar em uma experiência do usuário insatisfatória (por exemplo, uma falha no primeiro quadro), o driver deve realizar 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 antecipadamente, como reservar grandes buffers temporários ou aumentar a taxa de clock de um dispositivo. Drivers que podem preparar apenas um número limitado de modelos simultâneos podem ter que fazer sua inicialização na primeira execução.

No Android 10 ou superior, nos casos em que várias execuções com o mesmo modelo preparado são executadas em rápida sucessão, o cliente pode escolher usar um objeto de burst de execução para se comunicar entre os processos do aplicativo e do driver. Para mais informações, consulte Execuções e rápido filas de mensagens Explosão .

Para melhorar o desempenho de várias execuções em rápida sucessão, o driver pode manter buffers temporários ou aumentar as taxas de clock. A criação de um thread de watchdog é recomendada para liberar recursos se nenhuma nova solicitação for criada após um período fixo de tempo.

Forma de saída

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

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

Cronometragem

No Android 10, um aplicativo pode solicitar o tempo de execução se o aplicativo tiver especificado um único dispositivo para usar durante o processo de compilação. Para mais detalhes, consulte MeasureTiming e descoberta de dispositivo e Atribuição . Neste caso, um motorista de NN HAL 1.2 deve medir a duração de execução ou relatório UINT64_MAX (para indicar que a duração é indisponível) ao executar um pedido. O driver deve minimizar qualquer penalidade de desempenho resultante da medição da duração da execução.

O motorista relata as seguintes durações em microssegundos no Timing estrutura:

  • O tempo de execução no dispositivo: não inclui o tempo de execução no controlador, que é executado no processador host.
  • O tempo de execução no driver: Inclui o tempo de execução no dispositivo.

Essas durações devem incluir o tempo em que a execução é suspensa, por exemplo, quando a execução foi interrompida por outras tarefas ou quando está aguardando a disponibilização de um recurso.

Quando o motorista não foi pedido para medir a duração da execução, ou quando há um erro de execução, o motorista deve informar durações como UINT64_MAX . Mesmo quando o motorista foi convidado para medir a duração da execução, ele pode sim relate UINT64_MAX para o tempo no dispositivo, o tempo no controlador, ou ambos. Quando o motorista relata ambos durações como um valor diferente de UINT64_MAX , o tempo de execução no controlador deve ser igual ou exceder o tempo no dispositivo.

Execução cercada

Em Android 11, NNAPI permite execuções de esperar por uma lista de sync_fence alças e, opcionalmente retornar um sync_fence objeto, que é sinalizado quando a execução for concluída. Isso reduz a sobrecarga para modelos de sequência pequena e casos de uso de streaming. Execução vedada também permite uma maior interoperabilidade eficiente com outros componentes que podem sinalizar ou esperar por sync_fence . Para mais informações sobre sync_fence , consulte Synchronization Framework .

Em uma execução vedada, a estrutura chama a IPreparedModel::executeFenced método para lançar um cercado, execução assíncrona em um modelo preparado com um vector de cercas de sincronização para esperar. Se a tarefa assíncrona é concluída antes de a chamada retorna, uma alça de vazio pode ser devolvido para sync_fence . Um IFencedExecutionCallback objeto também deve ser devolvido para permitir o enquadramento de status de erro da consulta e informações duração.

Depois de uma execução é completada, os dois seguintes temporização valores de medição da duração da execução pode ser consultado através IFencedExecutionCallback::getExecutionInfo .

  • timingLaunched : Duração de quando executeFenced é chamado para quando executeFenced sinaliza o retornou syncFence .
  • timingFenced : Duração de quando todas as cercas da sincronização que as esperas de execução para são sinalizados quando executeFenced sinaliza o retornou syncFence .

Controle de fluxo

Para os dispositivos que executam o Android 11 ou superior, o NNAPI inclui duas operações de controle de fluxo, IF e WHILE , que tomam outros modelos como argumentos e executá-los condicionalmente ( IF ) ou repetidamente ( WHILE ). Para mais informações sobre como implementar isso, consulte Fluxo de controle .

Qualidade de serviço

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

Limpar

Quando um aplicativo é terminado utilizando um modelo preparado, o quadro libera sua referência à @1.3::IPreparedModel objeto. Quando o IPreparedModel objeto não é referenciado, ele é destruído automaticamente no serviço de motorista que o criou. Os recursos específicos do modelo podem ser recuperados neste momento na implementação do destruidor pelo driver. Se o serviço de motorista quer o IPreparedModel objeto a ser destruído automaticamente quando não for mais necessária pelo cliente, não deve manter quaisquer referências ao IPreparedModel objeto após a IPreparedeModel objeto foi devolvido através IPreparedModelCallback::notify_1_3 .

utilização do CPU

Espera-se que os drivers usem a CPU para configurar os cálculos. Os drivers não devem usar a CPU para realizar cálculos gráficos porque isso interfere na capacidade do framework de alocar trabalho corretamente. O driver deve relatar as partes que ele não pode manipular para a estrutura e deixar que a estrutura cuide do resto.

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

As operações introduzidas no Android 10 (nível API 29) só tem uma implementação CPU de referência para verificar se os testes CTS e VTS estão corretas. As implementações otimizadas incluídas em estruturas de aprendizado de máquina móvel são preferidas em vez da implementação de CPU NNAPI.

Funções utilitárias

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

A frameworks/ml/nn/common/include/Utils.h ficheiro contém funções de utilidades variadas, tais como os usados para o registo e para a conversão de diferentes versões NN HAL.

  • Vlogging: VLOG é uma macro invólucro em torno do Android LOG que só registra a mensagem se a tag apropriada está situado no debug.nn.vlog propriedade. initVLogMask() deve ser chamado antes de quaisquer chamadas para VLOG . O VLOG_IS_ON macro pode ser usada para verificar se VLOG está habilitado, permitindo código de log complicado para ser ignorado se não for necessário. O valor da propriedade deve ser um dos seguintes:

    • Uma string vazia, indicando que nenhum registro deve ser feito.
    • O token 1 ou all , indicando que todos os logs deve ser feito.
    • Uma lista de tags, delimitada 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 pode ser convertido para o mesmo tipo de uma versão HAL diferente sem perda de informações. Por exemplo, chamar compliantWithV1_0 em um V1_2::Model retorna false se o modelo inclui tipos de operação introduzidas no NN HAL 1.1 ou NN HAL 1.2.

  • convertToV1_* : Converte um objeto NN HAL de uma versão para outra. Um aviso é registrado se a conversão resultar em perda de informações (ou seja, se a nova versão do tipo não puder representar totalmente o valor).

  • Capacidades: O nonExtensionOperandPerformance e update funções podem ser usadas para ajudar a construir as Capabilities::operandPerformance campo.

  • Consultando propriedades de tipos: isExtensionOperandType , isExtensionOperationType , nonExtensionSizeOfData , nonExtensionOperandSizeOfData , nonExtensionOperandTypeIsScalar , tensorHasUnspecifiedDimensions .

A frameworks/ml/nn/common/include/ValidateHal.h ficheiro contém funções de utilidade para a validação de que um objecto NN HAL é válido de acordo com a especificação da sua versão HAL.

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

O frameworks/ml/nn/common/include/Tracing.h arquivo contém macros para simplificar a adição systracing informações para código de Redes Neurais. Para um exemplo, ver as NNTRACE_* invocações de macro no driver de exemplo .

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

  • graphDump : Grava uma representação do modelo em Graphviz ( .dot formato) para o fluxo especificado (se proporcionados) ou para o logcat (se não houver corrente é fornecida).

Validação

Para testar sua implementação da NNAPI, use os testes VTS e CTS incluídos na estrutura Android. O VTS exercita seus drivers diretamente (sem usar o framework), enquanto o CTS os exercita indiretamente por meio do framework. Eles testam cada método de API e verificam se todas as operações suportadas pelos drivers funcionam corretamente e fornecem resultados que atendem aos requisitos de precisão.

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

  • De ponto flutuante: abs (esperado - real) <= atol + rtol * abs (esperado); Onde:

    • Para fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • Para fp16, atol = rtol = 5.0f * 0,0009765625f
  • Quantizado: off-por-um (excepto para mobilenet_quantized , o qual é desligado por três-)

  • Boolean: correspondência exata

Uma das maneiras pelas quais o CTS testa a NNAPI é gerando gráficos pseudo-aleatórios fixos usados ​​para testar e comparar os resultados da execução de cada driver com a implementação de referência da NNAPI. Para os condutores com NN HAL 1.2 ou superior, se os resultados não cumpram os critérios de precisão, CTS relata um erro e despeja um arquivo de especificação para o modelo falhou em /data/local/tmp para depuração. Para mais detalhes sobre os critérios de precisão, consulte TestRandomGraph.cpp e TestHarness.h .

Teste Fuzz

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

Para executar fuzz testes para validar a sua implementação motorista, Modificar frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp na libneuralnetworks_driver_fuzzer utilitário de teste encontrado em AOSP para incluir o seu código do driver. Para mais informações sobre Fuzzing NNAPI, ver frameworks/ml/nn/runtime/test/android_fuzzing/README.md .

Segurança

Como os processos do aplicativo se comunicam diretamente com o processo de um driver, os drivers devem validar os argumentos das chamadas que recebem. Esta validação é verificada pelo VTS. O código de validação é em frameworks/ml/nn/common/include/ValidateHal.h .

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

Pacote de teste de aprendizado de máquina Android

O Android Machine Learning Test Suite (MLTS) é um benchmark NNAPI incluído no CTS e VTS para validar a precisão de modelos reais em dispositivos de fornecedores. Os avalia referência latência e precisão, e compara os resultados dos pilotos com os resultados usando TF Lite em execução no CPU, para o mesmo modelo e conjuntos de dados. Isso garante que a precisão do driver não seja pior do que a implementação de referência da CPU.

Os desenvolvedores da plataforma Android também usam MLTS para avaliar a latência e a precisão dos drivers.

O benchmark NNAPI pode ser encontrado em dois projetos no AOSP:

Modelos e conjuntos de dados

O benchmark NNAPI usa os seguintes modelos e conjuntos de dados.

  • MobileNetV1 float e u8 quantizados em tamanhos diferentes, executados em um pequeno subconjunto (1500 imagens) do Open Images Dataset v4.
  • MobileNetV2 float e u8 quantizados em tamanhos diferentes, executados em um pequeno subconjunto (1500 imagens) do Open Images Dataset v4.
  • Modelo acústico baseado em memória longa de curto prazo (LSTM) para conversão de texto em fala, executado em um pequeno subconjunto do conjunto CMU Arctic.
  • Modelo acústico baseado em LSTM para reconhecimento automático de fala, executado em um pequeno subconjunto do conjunto de dados LibriSpeech.

Para mais informações, consulte platform/test/mlts/models .

Teste de estresse

O Android Machine Learning Test Suite inclui uma série de testes de colisão para validar a resiliência dos drivers sob condições de uso pesado ou em casos extremos do comportamento dos clientes.

Todos os testes de falha fornecem os seguintes recursos:

  • Detecção jeito: Se os trava cliente NNAPI durante um teste, o teste falha com o motivo da falha HANG e o conjunto de teste desloca-se para o próximo teste.
  • NNAPI detecção acidente cliente: testes sobreviver cliente falhar e testes falhar com a causa da falha CRASH .
  • Detecção acidente motorista: Testes podem detectar uma falha do driver que causa uma falha em uma chamada NNAPI. Observe que pode haver travamentos nos processos do driver que não causam uma falha de NNAPI e não fazem com que o teste falhe. Para cobrir este tipo de falha, é recomendado para executar a tail de comando no log do sistema para erros ou acidentes relacionados ao driver.
  • Segmentação de todos os aceleradores disponíveis: Os testes são executados em todos os drivers disponíveis.

Todos os testes de colisão têm os seguintes quatro resultados possíveis:

  • SUCCESS : Execução concluída sem um erro.
  • FAILURE : Falha na execução. Normalmente causado por uma falha ao testar um modelo, indicando que o driver falhou ao compilar ou executar o modelo.
  • HANG : processo de teste tornou-se indiferente.
  • CRASH : processo de teste caiu.

Para mais informações sobre testes de estresse e uma lista completa de testes de colisão, ver platform/test/mlts/benchmark/README.txt .

Usando MLTS

Para usar o MLTS:

  1. Conecte um dispositivo de destino para a sua estação de trabalho e ter certeza que é alcançável através de adb . Exportar o dispositivo de destino ANDROID_SERIAL variável de ambiente, se mais do que um dispositivo está ligado.
  2. cd para o diretório fonte de nível superior Android.

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

    No final de uma referência prazo, os resultados são apresentados como uma página HTML e passou a xdg-open .

Para mais informações, consulte platform/test/mlts/benchmark/README.txt .

Versões HAL de redes neurais

Esta seção descreve as alterações introduzidas nas versões HAL do Android e redes neurais.

Android 11

O Android 11 apresenta o NN HAL 1.3, que inclui as seguintes mudanças notáveis.

  • Suporte para quantização de 8 bits assinada em NNAPI. Adiciona o TENSOR_QUANT8_ASYMM_SIGNED tipo de operando. Drivers com NN HAL 1.3 que suportam operações com quantização não assinada também devem suportar as variantes assinadas dessas operações. Ao executar versões assinados e não assinados da maioria das operações quantizados, os motoristas devem produzir os mesmos resultados até um deslocamento de 128. Há cinco excepções a esta exigência: CAST , HASHTABLE_LOOKUP , LSH_PROJECTION , PAD_V2 e QUANTIZED_16BIT_LSTM . O QUANTIZED_16BIT_LSTM operação não suporta operandos assinados e as outras quatro operações apoiar quantização assinado, mas não exigem que os resultados sejam os mesmos.
  • Suporte para execuções fortificadas onde o quadro chama a IPreparedModel::executeFenced método para lançar um cercado, execução assíncrona em um modelo preparado com um vector de cercas de sincronização para esperar. Para mais informações, consulte a execução Cercado .
  • Suporte para controle de fluxo. Adiciona as IF e WHILE operações, que têm outros modelos como argumentos e executá-los condicionalmente ( IF ) ou repetidamente ( WHILE ). Para mais informações, consulte Fluxo de controle .
  • Melhor qualidade de serviço (QoS), pois os aplicativos podem indicar as prioridades relativas de seus modelos, a quantidade máxima de tempo esperada para um modelo ser preparado e a quantidade máxima de tempo esperada para a conclusão de uma execução. Para mais informações, consulte Qualidade de Serviço .
  • Suporte para domínios de memória que fornecem interfaces de alocador para buffers gerenciados por driver. Isso permite a passagem de memórias nativas do dispositivo entre as execuções, suprimindo a cópia e transformação desnecessária de dados entre execuções consecutivas no mesmo driver. Para mais informações, consulte domínios de memória .

Android 10

O Android 10 apresenta o NN HAL 1.2, que inclui as seguintes mudanças notáveis.

  • O Capabilities struct inclui todos os tipos de dados, incluindo tipos de dados escalares, e representa desempenho nonrelaxed usando um vetor em vez de campos nomeados.
  • Os getVersionString e getType métodos permitem o enquadramento para recuperar tipo de dispositivo ( DeviceType ) e informações sobre a versão. Veja Device Discovery e Atribuição .
  • O executeSynchronously método é chamado por padrão para executar uma execução síncrona. O execute_1_2 método conta a estrutura para realizar uma execução de forma assíncrona. Veja Execution .
  • O MeasureTiming parâmetro para executeSynchronously , execute_1_2 especifica, e execução explosão se o driver é para medir a duração de execução. Os resultados são relatados na Timing estrutura. Veja sincronismo .
  • Suporte para execuções onde um ou mais operandos de saída têm uma dimensão ou classificação desconhecida. Veja forma de saída .
  • Suporte para extensões do fornecedor, que são coleções de operações definidas pelo fornecedor e tipos de dados. Os relatórios motorista extensões através do suportado IDevice::getSupportedExtensions método. Veja Vendor Extensions .
  • Capacidade de um objeto de burst de controlar um conjunto de execuções de burst usando filas de mensagens rápidas (FMQs) para se comunicar entre os processos do aplicativo e do driver, reduzindo a latência. Veja Execuções de ruptura e filas de mensagens rápidas .
  • Suporte para AHardwareBuffer para permitir que o driver execute execuções sem copiar dados. Veja AHardwareBuffer .
  • Suporte aprimorado para armazenamento em cache de artefatos de compilação para reduzir o tempo usado para compilação quando um aplicativo é iniciado. Veja Compilation Caching .

O Android 10 apresenta os seguintes tipos de operando e operações.

  • Tipos de operando

    • 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 apresenta atualizações para muitas das operações existentes. As atualizações estão principalmente relacionadas ao seguinte:

  • Suporte para o layout de memória NCHW
  • Suporte para 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 misto no ANEURALNETWORKS_CONCATENATION

A lista abaixo mostra as operações que são modificados no Android 10. Para maiores detalhes sobre as alterações, consulte OperationCode na documentação de referência 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

NN HAL 1.1 é introduzido no Android 9 e inclui as seguintes alterações notáveis.

  • IDevice::prepareModel_1_1 inclui um ExecutionPreference parâmetro. Um motorista pode usar isso para ajustar sua preparação, sabendo que o aplicativo prefere economizar bateria ou estará executando o modelo em chamadas sucessivas rápidas.
  • Nove novas operações foram adicionados: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
  • Um aplicativo pode especificar que os cálculos de flutuação de 32 bits pode ser executado usando faixa de flutuação de 16 bits e / ou precisão, definindo Model.relaxComputationFloat32toFloat16 a true . O Capabilities struct tem o campo adicional relaxedFloat32toFloat16Performance para que o motorista pode relatar seu desempenho relaxado ao quadro.

Android 8.1

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