Qualità del servizio

Deprecato: a partire da Android 15 (sperimentale AOSP), l' API NNAPI (NDK) è deprecata. L'interfaccia HAL delle reti neurali continua a essere supportata.

Per ulteriori informazioni, consulta la guida alla migrazione NNAPI.

A partire da Android 11, la NNAPI offre una migliore qualità del servizio (QoS) consentendo a un'app di indicare le priorità relative dei suoi modelli, la quantità massima di tempo prevista per un determinato modello per la preparazione e la quantità massima di tempo prevista per il completamento di una determinata esecuzione. Inoltre, Android 11 introduce valori di errore NNAPI aggiuntivi che consentono a un servizio di indicare con maggiore precisione cosa non ha funzionato quando si verifica un errore, in modo che l'app client possa reagire e recuperare meglio.

Priorità

Per Android 11 o versioni successive, i modelli vengono preparati con priorità nell'NN HAL 1.3. Questa priorità è relativa agli altri modelli preparati di proprietà della stessa app. Le esecuzioni con priorità più alta possono utilizzare più risorse di calcolo rispetto alle esecuzioni con priorità inferiore e possono prerilasciare o annullare le esecuzioni con priorità inferiore.

La chiamata NN HAL 1.3 che include Priority come argomento esplicito è IDevice::prepareModel_1_3. Tieni presente che IDevice::prepareModelFromCache_1_3 include implicitamente Priority negli argomenti della cache.

Esistono molte strategie per supportare le priorità, a seconda delle capacità del conducente e dell'acceleratore. Ecco alcune strategie:

• Per i driver che hanno un supporto prioritario integrato, propaga direttamente il campo Priority all'acceleratore.
• Utilizza una coda di priorità per app al fine di supportare diverse priorità anche prima che l'esecuzione raggiunga l'acceleratore.

• Mettere in pausa o annullare i modelli a bassa priorità in esecuzione per liberare l'acceleratore e consentire l'esecuzione di modelli ad alta priorità. Per farlo, inserisci checkpoint nei modelli a bassa priorità che, una volta raggiunti, eseguono una query su un flag per determinare se l'esecuzione attuale deve essere interrotta prematuramente oppure partizionando il modello in modelli secondari ed eseguendo query sul flag tra le esecuzioni di un modello secondario. Tieni presente che l'utilizzo di punti di controllo o sottomodelli nei modelli preparati con una priorità può introdurre un overhead aggiuntivo non presente per i modelli senza priorità nelle versioni inferiori a NN HAL 1.3.

  • Per supportare il prerilascio, preserva il contesto di esecuzione, inclusi l'operazione o il sottomodello successivo da eseguire e tutti i dati operando intermedi pertinenti. Utilizza questo contesto di esecuzione per riprendere l'esecuzione in un secondo momento.
  • Non è necessario un supporto completo del prerilascio, quindi non è necessario conservare il contesto dell'esecuzione. Poiché le esecuzioni del modello NNAPI sono deterministiche, è possibile riavviarle da zero in un secondo momento.

Android consente ai servizi di distinguere le diverse app per le chiamate tramite l'uso di un AID (UID Android). HIDL ha meccanismi integrati per recuperare l'UID dell'app di chiamata tramite il metodo ::android::hardware::IPCThreadState::getCallingUid. Un elenco di AID è disponibile in libcutils/include/cutils/android_filesystem_config.h.

Scadenze

A partire da Android 11, la preparazione ed le esecuzioni del modello possono essere lanciate con un argomento Scadenza OptionalTimePoint. Per i conducenti in grado di stimare il tempo necessario per un'attività, questa scadenza consente al conducente di interromperla prima che inizi se il conducente stima che l'attività non può essere completata prima della scadenza. Analogamente, la scadenza consente al conducente di interrompere un'attività in corso che, secondo la stima, non verrà completata prima della scadenza. L'argomento scadenze non obbliga un driver a interrompere un'attività se l'attività non viene completata entro la scadenza o se la scadenza è trascorsa. L'argomento scadenza può essere utilizzato per liberare risorse di computing all'interno del driver e restituire il controllo all'app più velocemente di quanto sia possibile senza la scadenza.

Le chiamate NN HAL 1.3 che includono come argomento le scadenze OptionalTimePoint sono:

• IDevice::prepareModel_1_3
• IDevice::prepareModelFromCache_1_3
• IPreparedModel::execute_1_3
• IPreparedModel::executeSynchronously_1_3
• IPreparedModel::executeFenced

Per visualizzare un'implementazione di riferimento della funzionalità di scadenza per ciascuno dei metodi sopra citati, consulta il driver di esempio NNAPI all'indirizzo frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Codici di errore

Android 11 include quattro valori di codice di errore in NN HAL 1.3 per migliorare la segnalazione degli errori, consentendo ai conducenti di comunicare meglio il proprio stato e alle app di recuperare in modo più agevole. Questi sono i valori dei codici di errore in ErrorStatus.

• MISSED_DEADLINE_TRANSIENT
• MISSED_DEADLINE_PERSISTENT
• RESOURCE_EXHAUSTED_TRANSIENT
• RESOURCE_EXHAUSTED_PERSISTENT

In Android 10 o versioni precedenti, un driver potrebbe indicare un errore solo tramite il codice di errore GENERAL_FAILURE. A partire da Android 11, i due codici di errore MISSED_DEADLINE possono essere utilizzati per indicare che il carico di lavoro è stato interrotto perché è stata raggiunta la scadenza o perché il conducente ha previsto che il carico di lavoro non sarebbe stato completato entro la scadenza. I due codici di errore RESOURCE_EXHAUSTED possono essere utilizzati per indicare che l'attività non è riuscita a causa di una limitazione delle risorse all'interno del driver, ad esempio il driver non ha memoria sufficiente per la chiamata.

La versione TRANSIENT di entrambi gli errori indica che il problema è temporaneo e che le chiamate future alla stessa attività potrebbero avere esito positivo dopo un breve ritardo. Ad esempio, questo codice di errore dovrebbe essere restituito quando il driver è occupato con operazioni precedenti a lunga esecuzione o che richiedono molte risorse, ma la nuova attività viene completata correttamente se il driver non è occupato con il lavoro precedente. La versione PERSISTENT di entrambi gli errori indica che le chiamate future alla stessa attività non andranno mai a buon fine. Ad esempio, questo codice di errore dovrebbe essere restituito quando il conducente stima che l'attività non verrebbe completata entro la scadenza anche in condizioni perfette o quando il modello è intrinsecamente troppo grande e supera le risorse del conducente.

Convalida

La funzionalità di qualità del servizio viene testata nei test NNAPI VTS (VtsHalNeuralnetworksV1_3Target). Questo include una serie di test di convalida (TestGenerated/ValidationTest#Test/) per garantire che il conducente rifiuti priorità non valide e una serie di test denominati DeadlineTest (TestGenerated/DeadlineTest#Test/) per garantire che il conducente gestisca correttamente le scadenze.