Driver dell'API Neural Networks

Obsoleta: a partire da Android 15, . La NNAPI (API NDK) è deprecata. Interfaccia dell'HAL per le reti neurali continua a essere supportata.

Per ulteriori informazioni, consulta Guida alla migrazione di NNAPI.

Questa pagina fornisce una panoramica su come implementare un'API Neural Networks (NNAPI) conducente. Per ulteriori dettagli, consulta la documentazione presente nella definizione dell'HAL in hardware/interfaces/neuralnetworks È disponibile un'implementazione del driver di esempio frameworks/ml/nn/driver/sample

Per ulteriori informazioni sull'API Neural Networks, consulta API Neural Networks.

Reti neurali HAL

Nota: questa pagina si riferisce alla versione 1.3 dell'HAL per le reti neurali in AOSP. Se implementi un driver su un'altra versione, fai riferimento corrispondente dell'HAL per le reti neurali.

L'HAL (NN) di reti neurali definisce un'astrazione dei vari dispositivi, come le GPU (Graphics Processing Unit) e i processori di segnale digitale (DSP), presenti in un prodotto (ad esempio un telefono o un tablet). I driver I dispositivi devono essere conformi alla norma NN HAL. L'interfaccia è specificata nell'HAL di definizione dei file in hardware/interfaces/neuralnetworks

È rappresentato il flusso generale dell'interfaccia tra il framework e un driver come mostrato nella figura 1.

Figura 1. Flusso delle reti neurali

Inizializzazione

Al momento dell'inizializzazione, il framework esegue una query sul driver per verificarne le capacità utilizzando IDevice::getCapabilities_1_3 La struttura @1.3::Capabilities include tutti i tipi di dati e rappresenta le prestazioni non rallentate utilizzando un vettore.

Per determinare come allocare i calcoli ai dispositivi disponibili, usa le funzionalità per comprendere la velocità e il modo in cui l'energia in modo efficiente ogni conducente può eseguire un'esecuzione. Per fornire queste informazioni, il conducente deve fornire numeri di prestazioni standardizzati in base all'esecuzione dei carichi di lavoro di riferimento.

Per determinare i valori che il conducente restituisce in risposta a IDevice::getCapabilities_1_3, usa l'app di benchmark NNAPI per misurare il il rendimento per i tipi di dati corrispondenti. Le versioni 1 e 2 di MobileNet, asr_float, e tts_float sono consigliati per la misurazione delle prestazioni per i modelli a 32 bit i valori in virgola mobile e i modelli quantiizzati MobileNet v1 e v2 consigliato per i valori quantizzati a 8 bit. Per ulteriori informazioni, vedi Test Suite di Android Machine Learning.

In Android 9 e versioni precedenti, la struttura Capabilities include le prestazioni del driver informazioni solo per i tensori a virgola mobile e quantizzati e non include tipi di dati scalari.

Nell'ambito del processo di inizializzazione, il framework può interrogare ulteriori informazioni, utilizzando IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, e IDevice::getNumberOfCacheFilesNeeded.

Tra i riavvii del prodotto, il framework prevede tutte le query descritte in in modo da riportare sempre gli stessi valori per un determinato conducente. Altrimenti, l'utilizzo di tale driver potrebbe presentare prestazioni ridotte o comportamenti errati.

Compilation

Il framework determina quali dispositivi usare quando riceve una richiesta da un dell'app. In Android 10, le app possono rilevare e specificare i dispositivi tra cui il framework sceglie. Per ulteriori informazioni, vedi Rilevamento e assegnazione dei dispositivi.

Al momento della compilazione del modello, il framework invia il modello a ciascun candidato autista chiamando IDevice::getSupportedOperations_1_3 Ogni driver restituisce un array di valori booleani che indicano del modello sono supportate. Un conducente può stabilire che non può una determinata operazione per vari motivi. Ad esempio:

• Il driver non supporta il tipo di dati.
• Il driver supporta solo le operazioni con parametri di input specifici. Per Ad esempio, un driver potrebbe supportare la convoluzione 3x3 e 5x5, ma non la convoluzione 7x7 operazioni.
• Il driver ha vincoli di memoria che gli impediscono di gestire grafici o input.

Durante la compilazione, l'input, l'output e gli operandi interni del modello, descritti in OperandLifeTime, possono avere dimensioni o ranking sconosciute. Per ulteriori informazioni, vedi Forma di output.

Il framework indica a ogni driver selezionato di prepararsi a eseguire un sottoinsieme di del modello chiamando IDevice::prepareModel_1_3 Ogni driver compila quindi il proprio sottoinsieme. Ad esempio, un conducente potrebbe generare il codice o creare una copia riordinata dei pesi. Poiché può esserci un una quantità di tempo significativa tra la compilazione del modello e delle richieste, risorse come grandi blocchi di memoria da assegnare durante la compilazione.

Se l'operazione riesce, il conducente restituisce un @1.3::IPreparedModel . Se il driver restituisce un codice di errore durante la preparazione del suo sottoinsieme modello, il framework esegue l'intero modello sulla CPU.

Per ridurre il tempo utilizzato per la compilazione all'avvio di un'app, un conducente può artefatti di compilazione della cache. Per ulteriori informazioni, consulta la sezione Compilation Memorizzazione nella cache.

Esecuzione

Quando un'app chiede al framework di eseguire una richiesta, il framework chiama il IPreparedModel::executeSynchronously_1_3 Metodo HAL per impostazione predefinita per eseguire un'esecuzione sincrona su un modello preparato. Una richiesta può essere eseguita anche in modo asincrono utilizzando execute_1_3 , executeFenced (vedi Esecuzione vincolata), o eseguito utilizzando Esecuzione di una serie di burst.

Le chiamate a esecuzione sincrona migliorano le prestazioni e riducono il threading overhead rispetto alle chiamate asincrone perché il controllo viene restituito solo al termine dell'esecuzione. Ciò significa che non necessita di un meccanismo separato per comunicare al processo dell'app il completamento di un'esecuzione.

Con il metodo execute_1_3 asincrono, il controllo torna al dopo l'inizio dell'esecuzione e il conducente deve inviare una notifica al framework una volta completata l'esecuzione, utilizzando @1.3::IExecutionCallback

Il parametro Request passato al metodo Esecuzione elenca l'input e l'output operandi usati per l'esecuzione. La memoria in cui vengono archiviati i dati degli operandi deve utilizza l'ordine principale di riga con la prima dimensione che ripete la più lenta e non ha spaziatura interna alla fine di qualsiasi riga. Per ulteriori informazioni sui tipi di operandi, vedi Operandi.

Per i conducenti NN HAL 1.2 o superiore, quando viene richiesta una richiesta completato, lo stato di errore, la forma di output e vengono restituite informazioni sulle tempistiche al framework. Durante l'esecuzione, gli operandi di output o interni del modello hanno una o più dimensioni o ranking sconosciuti. Quando almeno un output l'operando ha una dimensione o un ranking sconosciuti, il driver deve restituire con informazioni di output con dimensioni dinamiche.

Per i driver con NN HAL 1.1 o precedente, viene restituito solo lo stato di errore quando dell'utente. Le dimensioni degli operandi di input e output devono essere completamente specificato per il completamento dell'esecuzione. Gli operandi interni possono hanno una o più dimensioni sconosciute, ma devono avere un ranking specificato.

Per le richieste degli utenti che interessano più driver, il framework è responsabile per la memoria intermedia e per la sequenziazione delle chiamate a ciascun conducente.

È possibile avviare più richieste in parallelo sulla stessa @1.3::IPreparedModel Il driver può eseguire le richieste in parallelo o serializzare le esecuzioni.

Il framework può chiedere al conducente di tenere più di un modello preparato. Per esempio, prepara il modello m1, prepara m2, esegui la richiesta r1 su m1, esegui r2 su m2, esegui r3 su m1, esegui r4 su m2, release (descritta in Esegui la pulizia) m1 e rilascia m2.

Per evitare una prima esecuzione lenta che potrebbe comportare un'esperienza utente scadente (ad ad esempio lo stuttering del primo frame), il driver dovrebbe eseguire la maggior parte delle inizializzazioni nella fase di compilazione. L'inizializzazione alla prima esecuzione deve essere limitata a azioni che hanno un impatto negativo sull'integrità del sistema se eseguite per tempo, ad esempio riservare grandi buffer temporanei o aumentare la frequenza di clock di un dispositivo. I driver in grado di preparare solo un numero limitato di modelli simultanei potrebbero avere eseguire l'inizializzazione alla prima esecuzione.

In Android 10 o versioni successive, nei casi in cui con lo stesso modello preparato vengono eseguite in rapida successione, il cliente può scegliere eseguire burst di oggetti per comunicare tra i processi dell'app e del conducente. Per ulteriori informazioni le informazioni, vedi Esecuzioni lampo e code di messaggi rapide.

Per migliorare le prestazioni di più esecuzioni in rapida successione, può mantenere i buffer temporanei o aumentare le frequenze di clock. Creazione di un watchdog si consiglia di rilasciare risorse nel thread se non vengono create nuove richieste dopo per un periodo di tempo prestabilito.

Nota: il supporto per le chiamate di esecuzione sincrona nel livello HAL non è dipende dalle chiamate di esecuzione sincrone sul livello NDK.

Forma di output

Per le richieste in cui uno o più operandi di output non hanno tutte le dimensioni specificato, il conducente deve fornire un elenco di forme di output contenenti le informazioni sulla dimensione per ogni operando di output dopo l'esecuzione. Per ulteriori informazioni informazioni sulle dimensioni, consulta OutputShape

Se un'esecuzione non va a buon fine a causa di un buffer di output di dimensioni ridotte, il driver deve indicano quali operandi di output hanno dimensioni del buffer insufficienti nell'elenco forme di output e dovrebbero riportare quante più informazioni dimensionali possibile, utilizzando zero per le dimensioni sconosciute.

Tempi

In Android 10, un'app può chiedere l'esecuzione se l'app ha specificato un singolo dispositivo da utilizzare durante il processo di compilazione. Per i dettagli, vedi MeasureTiming e Rilevamento e assegnazione dei dispositivi. In questo caso, Il conducente dell'HAL 1.2 NN deve misurare la durata dell'esecuzione o segnalare UINT64_MAX (per indicano che la durata non è disponibile) durante l'esecuzione di una richiesta. Il conducente dovrebbero ridurre al minimo eventuali penalità in termini di prestazioni derivanti dalla misurazione dell'esecuzione durata massima.

Il driver riporta le seguenti durate in microsecondi nei Timing struttura:

• Tempo di esecuzione sul dispositivo: non include il tempo di esecuzione nella che viene eseguito sul processore host.
• Tempo di esecuzione nel driver: include il tempo di esecuzione sul dispositivo.

Queste durate devono includere il momento in cui l'esecuzione viene sospesa, ad esempio ad esempio quando l'esecuzione è stata prerilasciata da altre attività o quando in attesa che una risorsa diventi disponibile.

Nota: mentre il conducente indica le durate in microsecondi, il framework indica in nanosecondi (scalando le durate riportate dal driver).

Quando al conducente non è stato chiesto di misurare la durata dell'esecuzione o quando si è verificato un errore di esecuzione, il driver deve segnalare le durate come UINT64_MAX. Anche quando al conducente è stato chiesto di misurare l'esecuzione media, può invece registrare UINT64_MAX per il tempo sul dispositivo, ora nel conducente o entrambi. Quando il conducente segnala entrambe le durate come un valore diverso da UINT64_MAX, il tempo di esecuzione nel driver deve essere uguale o superiore a quello del dispositivo.

Esecuzione protetta

In Android 11, NNAPI consente alle esecuzioni di attendere elenco di handle sync_fence e, facoltativamente, restituisce un oggetto sync_fence, e viene segnalato al completamento dell'esecuzione. In questo modo si riduce l'overhead per modelli di sequenza e casi d'uso di flussi di dati. L'esecuzione vincolata consente inoltre di avere un'interoperabilità efficiente con altri componenti che possono segnalare o attendere sync_fence. Per ulteriori informazioni su sync_fence, vedi Framework di sincronizzazione.

In un'esecuzione protetta, il framework chiama IPreparedModel::executeFenced per avviare un'esecuzione asincrona e recintata su un modello preparato con un vettore di recinti di sincronizzazione da attendere. Se l'attività asincrona viene completata prima del giorno viene restituita la chiamata, è possibile restituire un handle vuoto per sync_fence. Un È necessario restituire anche l'oggetto IFencedExecutionCallback per consentire al framework per eseguire query su stato e durata degli errori.

Al termine di un'esecuzione, vengono eseguite le seguenti due valori tempistiche la misurazione della durata dell'esecuzione può essere interrogata IFencedExecutionCallback::getExecutionInfo

• timingLaunched: Durata da quando viene chiamato executeFenced a quando executeFenced segnala il valore syncFence restituito.
• timingFenced: Durata da quando tutte le restrizioni di sincronizzazione che l'esecuzione attende vengono avvisati quando executeFenced segnala syncFence restituito.

Flusso di controllo

Per i dispositivi con Android 11 o versioni successive, include due operazioni del flusso di controllo, IF e WHILE, che prendono altri modelli come argomenti ed eseguili in modo condizionale (IF) o ripetutamente (WHILE). Per ulteriori informazioni su come implementare questa funzionalità, consulta Flusso di controllo.

Qualità del servizio

In Android 11, la NNAPI offre una migliore qualità servizio (QoS) consentendo a un'app di indicare le priorità relative del suo la quantità di tempo massima prevista per la preparazione di un modello il tempo massimo previsto per il completamento di un'esecuzione. Per ulteriori informazioni, vedi Qualità del servizio.

Pulizia

Quando un'app termina di utilizzare un modello preparato, il framework viene rilasciato il suo riferimento @1.3::IPreparedModel . Quando non viene più fatto riferimento all'oggetto IPreparedModel, viene automaticamente nel servizio driver che l'ha creato. Specifico per il modello in questo momento nell'implementazione del driver come un distruttore. Se il servizio autista vuole che l'oggetto IPreparedModel sia automaticamente quando non è più necessario al client, non deve contenere qualsiasi riferimento all'oggetto IPreparedModel dopo l'oggetto IPreparedeModel che è stato restituito tramite IPreparedModelCallback::notify_1_3

Utilizzo CPU

I driver devono utilizzare la CPU per configurare i calcoli. I conducenti non devono usare la CPU per eseguire calcoli grafici perché questo interferisce con capacità del framework di allocare correttamente il lavoro. Il conducente deve segnalare le parti che non è in grado di gestire e lasciare che sia quest'ultimo a e riposare.

Il framework fornisce un'implementazione della CPU per tutte le operazioni NNAPI, ad eccezione di delle operazioni definite dal fornitore. Per ulteriori informazioni, vedi Estensioni del fornitore.

La operative introdotte in Android 10 (livello API 29) avere un'implementazione della CPU di riferimento solo per verificare che i test CTS e VTS sono corrette. Le implementazioni ottimizzate incluse nel machine learning per dispositivi mobili di rete sono preferiti rispetto all'implementazione della CPU NNAPI.

Funzioni di utilità

Il codebase NNAPI include funzioni di utilità che possono essere utilizzate dal driver i servizi di machine learning.

La frameworks/ml/nn/common/include/Utils.h contiene funzioni di utilità assortite, come quelle utilizzate per il logging e per la conversione tra diverse versioni di NN HAL.

• VLogging: VLOG è una macro wrapper relativa a LOG di Android che registra il messaggio se è impostato il tag appropriato nella debug.nn.vlog proprietà. initVLogMask() deve essere chiamato prima di qualsiasi chiamata a VLOG. La macro VLOG_IS_ON può essere utilizzata per verificare se VLOG è attualmente abilitato, abilitando il logging complicato del codice da saltare se non è necessario. Il valore della proprietà deve essere uno dei seguenti:

  • Una stringa vuota, che indica che non deve essere eseguito alcun logging.
  • Il token 1 o all, che indica che tutti i log devono essere eseguiti.
  • Un elenco di tag, delimitati da spazi, virgole o due punti, che indicano quale logging deve essere eseguito. I tag sono compilation, cpuexe, driver, execution, manager e model.

• compliantWithV1_*: restituisce true se un oggetto HAL NN può essere convertito allo stesso tipo di una versione HAL diversa senza perdere informazioni. Per ad esempio, chiamando compliantWithV1_0 su un V1_2::Model restituisce false se il modello include tipi di operazioni introdotte in NN HAL 1.1 o NN HAL 1.2.

• convertToV1_*: converte un oggetto NN HAL da una versione a un'altra. Viene registrato un avviso se la conversione determina una perdita di informazioni (ossia se la nuova versione del tipo non può rappresentare completamente il valore).

• Funzionalità: nonExtensionOperandPerformance e update per aiutare a creare Capabilities::operandPerformance: .

• Esecuzione di query sulle proprietà dei tipi: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData nonExtensionOperandSizeOfData nonExtensionOperandTypeIsScalar tensorHasUnspecifiedDimensions,

La frameworks/ml/nn/common/include/ValidateHal.h contiene funzioni di utilità per verificare la validità di un oggetto NN HAL in base alle specifiche della versione HAL.

• validate*: restituisce true se l'oggetto NN HAL è valido in base alle specifiche della versione HAL. Tipi di OEM e di estensione non vengono convalidati. Ad esempio, validateModel restituisce false se la proprietà modello contiene un'operazione che fa riferimento a un indice operando che non una versione dell'HAL o un'operazione non supportata in quella versione dell'HAL.

La frameworks/ml/nn/common/include/Tracing.h contiene macro per semplificare l'aggiunta informazioni systracing al codice delle reti neurali. Per un esempio, vedi le chiamate della macro NNTRACE_* nella driver di esempio.

La frameworks/ml/nn/common/include/GraphDump.h contiene una funzione di utilità per eseguire il dump del contenuto di un Model per il debug.

• graphDump: scrive una rappresentazione del modello in Graphviz (.dot) al flusso specificato (se fornito) o al logcat (se non viene fornito nessuno stream).

Convalida

Per testare l'implementazione della NNAPI, utilizza i test VTS e CTS inclusi in il framework Android. VTS esercita direttamente i conducenti (senza utilizzare quadro), mentre il CTS li applica indirettamente attraverso il framework. Questi testare ciascun metodo API e verificare che tutte le operazioni supportate che funzionano correttamente e forniscono risultati che soddisfano i requisiti di precisione.

I requisiti di precisione in CTS e VTS per NNAPI sono i seguenti:

• Virgola in virgola mobile: AB(previsto- effettivo) <= atol + rtol * as(previsto); dove:

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

• Quantizzati: di sconto di uno (tranne mobilenet_quantized, che è disattivato per tre)

• Booleano:corrispondenza esatta

Un modo in cui CTS testa la NNAPI è generando grafici pseudocasuali fissi. utilizzato per testare e confrontare i risultati di esecuzione di ciascun driver Implementazione del riferimento NNAPI. Per i conducenti con NN HAL 1.2 o superiore, se non soddisfano i criteri di precisione, il CTS segnala un errore ed esegue il dump file di specifiche per il modello con errore in /data/local/tmp per il debug. Per ulteriori dettagli sui criteri di precisione, consulta TestRandomGraph.cpp e TestHarness.h.

Test fuzz

Lo scopo dei test fuzz è individuare arresti anomali, asserzioni, violazioni della memoria o un comportamento generale indefinito nel codice sottoposto a test a causa di fattori quali input imprevisti. Per i fuzz test NNAPI, Android utilizza test basati su libFuzzer, che sono efficiente nel fuzzing perché utilizza la copertura di linea degli scenari di test precedenti per generano nuovi input casuali. Ad esempio, libFuzzer favorisce gli scenari di test eseguiti su nuove righe di codice. Questo riduce notevolmente il tempo necessario ai test un codice problematico.

Per eseguire test fuzz per convalidare l'implementazione del driver, modifica frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp nell'utilità di test libneuralnetworks_driver_fuzzer trovata in AOSP per includere il tuo codice driver. Per ulteriori informazioni sui fuzz test NNAPI, consulta frameworks/ml/nn/runtime/test/android_fuzzing/README.md

Sicurezza

Poiché i processi delle app comunicano direttamente con quelli del conducente, i conducenti devono convalidare gli argomenti delle chiamate che ricevono. Questo tipo di convalida sia verificata da VTS. Il codice di convalida è in frameworks/ml/nn/common/include/ValidateHal.h

I conducenti devono anche assicurarsi che le app non possano interferire con altri quando usi lo stesso dispositivo.

Test Suite di Android Machine Learning

Android Machine Learning Test Suite (MLTS) è un benchmark NNAPI incluso nella CTS e VTS per convalidare l'accuratezza dei modelli reali sui dispositivi dei fornitori. La benchmark valuta la latenza e l'accuratezza e confronta risultati con i risultati utilizzando TF Lite in esecuzione sulla CPU, per lo stesso modello e set di dati. Ciò garantisce che la precisione di un conducente peggiore dell'implementazione del riferimento della CPU.

Gli sviluppatori di piattaforme Android utilizzano anche MLTS per valutare la latenza e la precisione dei conducenti.

Il benchmark NNAPI è disponibile in due progetti in AOSP:

• platform/test/mlts/benchmark (app benchmark)
• platform/test/mlts/models (modelli e set di dati)

Modelli e set di dati

Il benchmark NNAPI utilizza i seguenti modelli e set di dati.

• MobileNetV1 in virgola mobile e u8 quantizzati in dimensioni diverse, eseguiti rispetto a un un piccolo sottoinsieme (1500 immagini) del set di dati Open Images v4.
• MobileNetV2 in virgola mobile e u8 quantizzati in dimensioni diverse, eseguiti rispetto a un un piccolo sottoinsieme (1500 immagini) del set di dati Open Images v4.
• Modello acustico basato su LSTM (Long Short-Term Memory). per la sintesi vocale, verranno eseguiti su un piccolo sottoinsieme del CMU artico.
• Modello acustico basato su LSTM per il riconoscimento vocale automatico, eseguito rispetto un piccolo sottoinsieme del set di dati LibriSpeech.

Per ulteriori informazioni, vedi platform/test/mlts/models

Test di stress

La Test Suite di Android Machine Learning include una serie di test di arresti anomali per convalidare la resilienza dei conducenti in condizioni di utilizzo gravose o in un angolo i casi dei clienti comportamento degli utenti.

Tutti i test di arresto anomalo offrono le seguenti funzionalità:

• Rilevamento blocco: se il client NNAPI si blocca durante un test, il test ha esito negativo con il motivo dell'errore HANG e la suite di test passa al test successivo.
• Rilevamento di arresti anomali del client NNAPI: i test superano gli arresti anomali e i test del client non riesce con il motivo dell'errore CRASH.
• Rilevamento di arresti anomali del conducente: i test possono rilevare un incidente del conducente che causa un errore di una chiamata NNAPI. Tieni presente che potrebbero verificarsi arresti anomali in processi del driver che non causano un errore NNAPI e non causano l'errore. Per risolvere questo tipo di errore, ti consigliamo di eseguire tail nel log di sistema per rilevare errori o arresti anomali relativi al driver.
• Targeting di tutti gli acceleratori disponibili: i test vengono eseguiti su tutti dei conducenti disponibili.

Tutti i test di arresto anomalo hanno i seguenti quattro risultati possibili:

• SUCCESS: esecuzione completata senza un errore.
• FAILURE: esecuzione non riuscita. Generalmente è causato da un errore quando testare un modello, indicando che la compilazione o l'esecuzione del driver non è riuscita del modello.
• HANG: il processo di test non risponde.
• CRASH: arresto anomalo del processo di test.

Per ulteriori informazioni sui test di stress e per un elenco completo dei test di arresto anomalo, vedi platform/test/mlts/benchmark/README.txt

Utilizzo di MLTS

Per utilizzare MLTS:

1. Connetti un dispositivo di destinazione alla workstation e assicurati che sia raggiungibile tramite adb. Esporta il dispositivo di destinazione ANDROID_SERIAL se sono connessi più dispositivi.

2. cd nella directory di origine di primo livello Android.

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

   Al termine dell'esecuzione di un benchmark, i risultati vengono presentati come pagina HTML e passato a xdg-open.

Per ulteriori informazioni, vedi platform/test/mlts/benchmark/README.txt

Versioni HAL per le reti neurali

Questa sezione descrive le modifiche introdotte in Android e Neural Reti le versioni HAL.

Android 11

Android 11 introduce NN HAL 1.3, che include il in seguito a cambiamenti degni di nota.

• Supporto per la quantizzazione firmata a 8 bit in NNAPI. Aggiunge il parametro TENSOR_QUANT8_ASYMM_SIGNED di operando. Driver con NN HAL 1.3 che supportano le operazioni con quantizzazione non firmata devono supportare anche le varianti con firma di queste operazioni. Quando esegui versioni con e senza firma della maggior parte operazioni quantizzate, i conducenti devono produrre gli stessi risultati fino con un offset di 128. Esistono cinque eccezioni a questo requisito: CAST. HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2 e QUANTIZED_16BIT_LSTM. L'operazione QUANTIZED_16BIT_LSTM non supporta gli operandi firmati e le altre quattro operazioni supportano la quantizzazione firmata, ma non richiedono che i risultati siano gli stessi.
• Supporto per esecuzioni limitate in cui il framework chiama IPreparedModel::executeFenced per avviare un'esecuzione asincrona e recintata su un modello preparato con un vettore di recinti di sincronizzazione da attendere. Per ulteriori informazioni, vedi Esecuzione vincolata.
• Supporto per il flusso di controllo. Aggiunge le operazioni IF e WHILE, che richiedono altri modelli come argomenti ed eseguirli in modo condizionale (IF) ripetutamente (WHILE). Per ulteriori informazioni, vedi Flusso di controllo.
• La qualità del servizio (QoS) migliorata, in quanto le app possono indicare le priorità dei suoi modelli, la quantità di tempo massima prevista del modello da preparare e la quantità di tempo massima prevista il completamento dell'esecuzione. Per ulteriori informazioni, vedi Qualità del servizio.
• Supporto per domini di memoria che forniscono interfacce allocator per buffer gestiti dal driver. Ciò consente di trasmettere le memorie native dei dispositivi tutte le esecuzioni, eliminando la copia e la trasformazione non necessarie dei dati tra esecuzioni consecutive sullo stesso driver. Per ulteriori informazioni, vedi Domini di memoria.

Android 10

Android 10 introduce NN HAL 1.2, che include il in seguito a cambiamenti degni di nota.

• Lo struct Capabilities include tutti i tipi di dati, inclusi quelli scalari tipi di dati e rappresenta le prestazioni non rallentate utilizzando un vettore rispetto ai campi con nome.
• I metodi getVersionString e getType consentono al framework di recupero delle informazioni sul tipo di dispositivo (DeviceType) e sulla versione. Consulta Rilevamento e assegnazione dei dispositivi.
• Il metodo executeSynchronously viene chiamato per impostazione predefinita per eseguire una l'esecuzione in modalità sincrona. Il metodo execute_1_2 indica al framework di eseguire un'esecuzione in modo asincrono. Vedi Esecuzione.
• Il parametro MeasureTiming per executeSynchronously, execute_1_2, mentre l'esecuzione burst specifica se il driver deve misurare l'esecuzione durata massima. I risultati sono riportati nella struttura Timing. Consulta Tempistiche.
• Supporto per esecuzioni in cui uno o più operandi di output hanno un dimensione o ranking. Vedi Forma di output.
• Supporto per le estensioni del fornitore, ovvero raccolte di contenuti definiti dal fornitore operazioni e tipi di dati. Il conducente segnala le estensioni supportate tramite il metodo IDevice::getSupportedExtensions. Consulta Estensioni del fornitore.
• Possibilità di un oggetto burst di controllare una serie di esecuzioni a raffica utilizzando code di messaggi veloci (FMQ) per comunicare tra app e driver i processi, riducendo la latenza. Consulta Esecuzioni lampo e code di messaggi rapide.
• Supporto per AHardwareBuffer per consentire al driver di eseguire le esecuzioni senza copiare i dati. Consulta AHardwareBuffer.
• Supporto migliorato per la memorizzazione nella cache degli artefatti di compilazione per ridurre il tempo utilizzata per la compilazione all'avvio di un'app. Consulta Memorizzazione nella cache della compilazione.

Android 10 introduce i seguenti tipi di operandi e operazioni.

• Tipi di 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

• Operazioni

  • 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

Android 10 introduce aggiornamenti per molti dei operazioni. Gli aggiornamenti sono relative principalmente a quanto segue:

• Supporto del layout della memoria NCHW
• Supporto per tensori con ranking diverso da 4 in softmax e operazioni di normalizzazione
• Supporto per le convoluzioni dilate
• Supporto per input con quantizzazione mista in ANEURALNETWORKS_CONCATENATION

L'elenco seguente mostra le operazioni modificate in Android 10. Per la carica completa i dettagli delle modifiche, vedi OperationCode nella documentazione di riferimento di 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 viene introdotto in Android 9 e include quanto segue modifiche.

• IDevice::prepareModel_1_1 include un ExecutionPreference . Un conducente può usarlo per regolare la sua preparazione, sapendo che l'app preferisce risparmiare batteria o eseguirà il modello in chiamate successive e rapide.
• Sono state aggiunte nove nuove operazioni: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB e TRANSPOSE.
• Un'app può specificare che è possibile eseguire calcoli in virgola mobile a 32 bit utilizzando l'intervallo in virgola mobile a 16 bit e/o la precisione impostando Da Model.relaxComputationFloat32toFloat16 a true. Capabilities lo struct ha il campo aggiuntivo relaxedFloat32toFloat16Performance, perciò in modo che il conducente possa segnalare le sue prestazioni rilassate al framework.

Android 8.1

L'HAL iniziale di reti neurali (1.0) è stato rilasciato in Android 8.1. Per ulteriori informazioni le informazioni, vedi /neuralnetworks/1.0/