Qualità del servizio

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, 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 valori di errore NNAPI aggiuntivi 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 e recuperare meglio.

Priorità

Per Android 11 o versioni successive, i modelli vengono preparati con una priorità in NN HAL 1.3. Questa priorità è relativa ad altri modelli preparati di proprietà della stessa app. Le esecuzioni con priorità più alta possono utilizzare più risorse di calcolo rispetto a quelle con priorità più bassa e possono interrompere o bloccare quelle con priorità più bassa.

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 conducenti che dispongono di assistenza prioritaria integrata, propaga direttamente il campo Priority all'acceleratore.
• Utilizza una coda di priorità per app per supportare priorità diverse anche prima che un'esecuzione raggiunga l'acceleratore.

• Metti in pausa o annulla i modelli a bassa priorità in esecuzione per liberare l'acceleratore per eseguire i modelli ad alta priorità. A questo scopo, puoi inserire checkpoint nei modelli a bassa priorità che, una volta raggiunti, eseguono query su un flag per determinare se l'esecuzione corrente deve essere interrotta prematuramente oppure partizionare il modello in sottomodelli ed eseguire query sul flag tra le esecuzioni dei sottomodelli. Tieni presente che l'utilizzo di checkpoint o sottomodelli nei modelli preparati con una priorità può introdurre un overhead aggiuntivo che non è presente nei modelli senza priorità nelle versioni inferiori a NN HAL 1.3.

  • Per supportare la preemption, conserva il contesto di esecuzione inclusa la successiva operazione o il successivo sottomodello da eseguire e tutti i dati dell'operando intermedio pertinenti. Utilizza questo contesto di esecuzione per riprendere l'esecuzione in un secondo momento.
  • Il supporto completo della preemption non è necessario, quindi il contesto di esecuzione non deve essere conservato. Poiché le esecuzioni del modello NNAPI sono deterministiche, possono essere riavviate da zero in un secondo momento.

Android consente ai servizi di distinguere le diverse app di chiamata tramite l'utilizzo di un AID (Android UID). HIDL dispone di meccanismi integrati per recuperare l'UID dell'app chiamante tramite il metodo ::android::hardware::IPCThreadState::getCallingUid. Un elenco di ID account può essere trovato in libcutils/include/cutils/android_filesystem_config.h.

Scadenze

A partire da Android 11, la preparazione e l'esecuzione dei modelli possono essere avviate con un argomento di scadenza OptionalTimePoint. Per i conducenti che possono stimare la durata di un'attività, questa scadenza consente al conducente di interrompere l'attività prima che inizi se stima che non possa essere completata prima della scadenza. Allo stesso modo, la scadenza consente al driver di interrompere un'attività in corso che stima non verrà completata prima della scadenza. L'argomento scadenza non forza un autista ad abbandonare un'attività se non è completata entro la scadenza o se la scadenza è passata. L'argomento deadline può essere utilizzato per liberare risorse di calcolo all'interno del driver e restituire il controllo all'app più rapidamente di quanto sia possibile senza la scadenza.

Le chiamate NN HAL 1.3 che includono 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 precedenti, 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 i report sugli errori, consentendo ai conducenti di comunicare meglio il loro stato e alle app di ripristinarsi 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 workload è stato interrotto perché è stata raggiunta la scadenza o perché il driver ha previsto che il workload 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 riuscire dopo un breve ritardo. Ad esempio, questo codice di errore deve essere restituito quando il driver è occupato con un lavoro precedente a esecuzione prolungata o che richiede molte risorse, ma la nuova attività verrebbe completata correttamente se il driver non fosse occupato con il lavoro precedente. La versione PERSISTENT di entrambi gli errori indica che le chiamate future alla stessa attività dovrebbero sempre non riuscire. Ad esempio, questo codice di errore deve essere restituito quando il driver stima che l'attività non verrà completata entro la scadenza anche in condizioni perfette oppure che il modello è intrinsecamente troppo grande e supera le risorse del driver.

Convalida

La funzionalità di qualità del servizio viene testata nei test VTS di NNAPI (VtsHalNeuralnetworksV1_3Target). Sono inclusi un insieme di test per la convalida (TestGenerated/ValidationTest#Test/) per garantire che il driver rifiuti le priorità non valide e un insieme di test denominati DeadlineTest (TestGenerated/DeadlineTest#Test/) per garantire che il driver gestisca correttamente le scadenze.