Qualità del servizio

A partire da Android 11, il 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 una data esecuzione da completare. 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 ripristinarsi meglio.

Priorità

Per Android 11 o versioni successive, i modelli sono 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 usare più risorse di calcolo rispetto alle esecuzioni con priorità più bassa e possono anticipare o eliminare le esecuzioni con priorità più bassa.

Il NN HAL 1.3 chiamata che include Priority come argomento esplicito è IDevice::prepareModel_1_3 . Si noti che IDevice::prepareModelFromCache_1_3 include implicitamente Priority negli argomenti della cache.

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

  • Per i conducenti che sono dotati di un sostegno prioritario, propagare direttamente la Priority campo per l'acceleratore.
  • Usa una coda di priorità per app per supportare priorità diverse anche prima che un'esecuzione raggiunga l'acceleratore.
  • Sospendi o annulla i modelli a bassa priorità attualmente in esecuzione per liberare l'acceleratore per l'esecuzione di modelli ad alta priorità. Fare sia posti di blocco inserimento in modelli a bassa priorità che, una volta raggiunto, interrogare un flag per determinare se l'esecuzione corrente deve essere interrotta prematuramente o suddividendo il modello in sottomodelli ed interrogare il flag tra le esecuzioni modelli secondari. Si noti che l'uso di checkpoint o sottomodelli nei modelli preparati con una priorità può introdurre un sovraccarico aggiuntivo che non è presente per i modelli senza priorità nelle versioni inferiori a NN HAL 1.3.

    • Per supportare la prelazione, preservare il contesto di esecuzione inclusa l'operazione successiva o il sottomodello da eseguire e tutti i dati degli operandi intermedi rilevanti. Utilizzare questo contesto di esecuzione per riprendere l'esecuzione in un secondo momento.
    • Il supporto per la prelazione completa non è necessario, quindi non è necessario preservare il contesto di esecuzione. Poiché le esecuzioni del modello NNAPI sono deterministiche, le esecuzioni possono essere riavviate da zero in un secondo momento.

Android consente ai servizi di distinguere tra diverse app di chiamata tramite l'uso di un AID (UID Android). HIDL è dotato di meccanismi per recuperare UID dell'app chiama attraverso il metodo ::android::hardware::IPCThreadState::getCallingUid . Un elenco di AIDS può essere trovato in libcutils/include/cutils/android_filesystem_config.h .

Scadenze

A partire da Android 11, la preparazione e le esecuzioni del modello possono essere lanciati con un OptionalTimePoint argomento scadenza. Per i conducenti in grado di stimare la durata di un'attività, questa scadenza consente al conducente di interrompere l'attività prima dell'inizio se stima che l'attività non può essere completata prima della scadenza. Allo stesso modo, la scadenza consente al conducente di interrompere un'attività in corso che si stima non sarà completata prima della scadenza. L'argomento della scadenza non impone a un conducente di interrompere un'attività se l'attività non è stata completata entro la scadenza o se la scadenza è stata superata. L'argomento della scadenza può 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.

I NN HAL 1.3 chiamate che includono OptionalTimePoint scadenze 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à scadenza per ciascuno dei metodi di cui sopra, vedere il driver di esempio NNAPI a 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 le app per recuperare in modo più garbato. 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 inferiore, un driver potrebbe indicare solo un guasto attraverso il GENERAL_FAILURE codice di errore. Da Android 11, i due MISSED_DEADLINE codici di errore possono essere utilizzate per indicare che il carico di lavoro è stata interrotta perché il termine è stato raggiunto o perché il conducente ha predetto il carico di lavoro non avrebbe completato entro la scadenza. I due RESOURCE_EXHAUSTED codici di errore possono essere utilizzate per indicare che l'attività non è riuscita a causa di una limitazione di risorse all'interno del driver, come ad esempio il conducente non avere memoria sufficiente per la chiamata.

La TRANSIENT versione di entrambi gli errori indica che il problema è temporaneo, e che il futuro chiama alla stessa operazione potrebbe avere successo dopo un breve ritardo. Ad esempio, questo codice di errore deve essere restituito quando il conducente è impegnato in un lavoro precedente a esecuzione prolungata o che richiede molte risorse, ma la nuova attività viene completata correttamente se il conducente non è impegnato con il lavoro precedente. La PERSISTENT versione di entrambi gli errori indica che le chiamate future lo stesso compito sono sempre tenuti a fallire. Ad esempio, questo codice di errore dovrebbe essere restituito quando il conducente 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 conducente.

Convalida

La qualità del servizio funzionalità è testato nelle prove NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ). Ciò include una serie di test per la validazione ( TestGenerated/ValidationTest#Test/ ) per garantire che il conducente rifiuta priorità non validi e una serie di test chiamato DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) al fine di garantire che le maniglie del driver scadenze in modo corretto.