Qualità del servizio

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 ad altri modelli preparati di proprietà della stessa app. Le esecuzioni con priorità più elevata possono utilizzare più risorse di calcolo delle esecuzioni con priorità inferiore e possono prelevare o bloccare 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 conducenti con 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 di bassa priorità in esecuzione per liberare l'acceleratore in modo che possa eseguire i modelli di alta priorità. A tale scopo, puoi inserire checkpoint nei modelli a bassa priorità che, quando vengono raggiunti, eseguono una query su un flag per determinare se l'esecuzione corrente deve essere interrotta prematuramente oppure puoi suddividere il modello in sottomodelli ed eseguire una query sul flag tra le esecuzioni dei sottomodelli. Tieni presente che l'utilizzo di checkpoint o submodelli nei modelli preparati con una priorità può introdurre un overhead aggiuntivo non presente per i modelli senza priorità nelle versioni precedenti 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 dei modelli NNAPI sono deterministiche, possono essere riavviate da zero in un secondo momento.

Android consente ai servizi di distinguere tra diverse app di chiamata tramite l'utilizzo di un AID (Android UID). 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 e le esecuzioni dei modelli possono essere avviate 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 stima non verrà completata prima della scadenza. L'argomento scadenza non forza un driver ad abortire un'attività se non viene completata entro la scadenza o se la scadenza è passata. L'argomento scadenza puoi essere utilizzato per liberare risorse di calcolo 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 riportati, 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 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 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 deve essere restituito quando il driver è occupato con un lavoro precedente di lunga durata o che richiede molte risorse, ma la nuova attività verrà 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à sono sempre previste come non riuscite. 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 o 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 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.