Qualità del servizio

Ritirata: a partire da Android 15, l' API NNAPI (NDK) è stata ritirata. L'interfaccia HAL delle reti neurali continua a essere supportata.

Per ulteriori informazioni, consulta la guida alla migrazione di NNAPI.

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

Priorità

Per Android 11 o versioni successive, i modelli vengono preparati con priorità in 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 possibili per supportare le priorità a seconda delle funzionalità del driver e dell'acceleratore. Ecco alcune strategie:

• Per i driver con assistenza prioritaria integrata, 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.

• Metti in pausa o annulla i modelli di bassa priorità in esecuzione per liberare l'acceleratore in modo che possa eseguire i modelli di 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 la preemption, conserva il contesto di esecuzione, tra cui l'operazione o il sottomodello successivo da eseguire e gli eventuali dati degli operandi intermedi pertinenti. Utilizza questo contesto di esecuzione per riprendere l'esecuzione in un secondo momento.
  • Non è necessario il supporto completo della preemption, pertanto il contesto di esecuzione non deve essere preservato. 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 chiamante 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 che possono stimare il tempo necessario per un'attività, questa scadenza consente di interrompere l'attività prima dell'inizio se il conducente stima che non possa 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 scadenza 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 le scadenze OptionalTimePoint come argomento 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 indicati, 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 generazione di report sugli errori, consentendo ai driver di comunicare meglio il proprio stato e alle app di recuperare in modo più elegante. Questi sono i valori del codice di errore in ErrorStatus.

• MISSED_DEADLINE_TRANSIENT
• MISSED_DEADLINE_PERSISTENT
• RESOURCE_EXHAUSTED_TRANSIENT
• RESOURCE_EXHAUSTED_PERSISTENT

In Android 10 o versioni precedenti, un driver poteva 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 driver 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 se il driver non dispone di 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 riuscire 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 PERSISTENT versione di entrambi gli errori indica che le chiamate future alla stessa attività dovrebbero sempre essere fallimentari. 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 VTS NNAPI (VtsHalNeuralnetworksV1_3Target). Sono inclusi un insieme di test di convalida (TestGenerated/ValidationTest#Test/) per garantire che il driver rifiuti le priorità invalide e un insieme di test chiamato DeadlineTest (TestGenerated/DeadlineTest#Test/) per garantire che il driver gestisca correttamente le scadenze.