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 una determinata esecuzione da completare. 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 e ripristinarsi meglio.

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ù alta possono utilizzare più risorse di elaborazione rispetto alle esecuzioni con priorità più bassa e possono anticipare o indebolire le esecuzioni 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 capacità del conducente e dell'acceleratore. Ecco diverse strategie:

• Per i driver che dispongono del supporto prioritario integrato, propagare 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 modelli ad alta priorità. Puoi farlo inserendo checkpoint nei modelli a bassa priorità che, una volta raggiunti, interrogano un flag per determinare se l'esecuzione corrente deve essere interrotta prematuramente o suddividendo il modello in sottomodelli ed interrogando il flag tra le esecuzioni dei sottomodelli. Si noti che l'utilizzo 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 rilevanti dell'operando intermedio. Utilizzare questo contesto di esecuzione per riprendere l'esecuzione in un secondo momento.
  • Non è necessario il supporto completo della prelazione, quindi non è necessario preservare il contesto di esecuzione. Poiché le esecuzioni del modello NNAPI sono deterministiche, è possibile riavviarle 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 dispone di 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 l'esecuzione del modello 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 ritiene che l'attività non possa 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 scadenza non forza un driver ad interrompere un'attività se l'attività non viene completata entro la scadenza o se la scadenza è scaduta. L'argomento scadenza può essere utilizzato per liberare risorse di calcolo all'interno del driver e restituire il controllo all'app più velocemente di quanto sarebbe 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 vedere un'implementazione di riferimento della funzionalità di scadenza per ciascuno dei metodi sopra indicati, vedere il driver di esempio NNAPI in frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Codici di errore

Android 11 include quattro valori di codici 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 riprendersi in modo più agevole. 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 conducente aveva 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 la mancanza di memoria sufficiente del driver 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 conducente è occupato con un lavoro precedente di lunga durata o ad alto utilizzo di risorse, ma che la nuova attività verrebbe completata correttamente se il conducente non fosse occupato con il lavoro precedente. La versione PERSISTENT di entrambi gli errori indica che è previsto che le chiamate future alla stessa attività falliscano sempre. 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.

Validazione

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