Qualité de service

À partir d'Android 11, le NNAPI offre une meilleure qualité de service (QoS) en permettant à une application d'indiquer les priorités relatives de ses modèles, le temps maximum attendu pour la préparation d'un modèle donné et le temps maximum attendu pour la préparation d'un modèle donné. une exécution donnée à terminer. De plus, Android 11 introduit des valeurs d'erreur NNAPI supplémentaires permettant à un service d'indiquer plus précisément ce qui n'a pas fonctionné en cas de panne afin que l'application cliente puisse mieux réagir et récupérer.

Priorité

Pour Android 11 ou supérieur, les modèles sont préparés en priorité dans le NN HAL 1.3. Cette priorité est relative aux autres modèles préparés appartenant à la même application. Les exécutions à priorité plus élevée peuvent utiliser plus de ressources de calcul que les exécutions à priorité inférieure, et peuvent anticiper ou affamer les exécutions à priorité inférieure.

L'appel NN HAL 1.3 qui inclut Priority comme argument explicite est IDevice::prepareModel_1_3 . Notez que IDevice::prepareModelFromCache_1_3 inclut implicitement Priority dans les arguments du cache.

Il existe de nombreuses stratégies possibles pour soutenir les priorités en fonction des capacités du conducteur et de l'accélérateur. Voici plusieurs stratégies :

  • Pour les pilotes dotés d’une prise en charge prioritaire intégrée, propagez directement le champ Priority à l’accélérateur.
  • Utilisez une file d'attente prioritaire par application pour prendre en charge différentes priorités avant même qu'une exécution n'atteigne l'accélérateur.

  • Mettez en pause ou annulez les modèles de faible priorité en cours d'exécution pour libérer l'accélérateur afin qu'il exécute les modèles de haute priorité. Pour ce faire, soit en insérant des points de contrôle dans les modèles de faible priorité qui, une fois atteints, interrogent un indicateur pour déterminer si l'exécution en cours doit être interrompue prématurément, soit en partitionnant le modèle en sous-modèles et en interrogeant l'indicateur entre les exécutions de sous-modèles. Notez que l'utilisation de points de contrôle ou de sous-modèles dans les modèles préparés avec une priorité peut introduire une surcharge supplémentaire qui n'est pas présente pour les modèles sans priorité dans les versions inférieures à NN HAL 1.3.

    • Pour prendre en charge la préemption, préservez le contexte d'exécution, y compris la prochaine opération ou sous-modèle à exécuter et toutes les données d'opérande intermédiaire pertinentes. Utilisez ce contexte d'exécution pour reprendre l'exécution ultérieurement.
    • La prise en charge complète de la préemption n’est pas nécessaire, le contexte d’exécution n’a donc pas besoin d’être préservé. Les exécutions du modèle NNAPI étant déterministes, les exécutions peuvent être redémarrées à partir de zéro ultérieurement.

Android permet aux services de différencier les différentes applications d'appel grâce à l'utilisation d'un AID (Android UID). HIDL dispose de mécanismes intégrés pour récupérer l'UID de l'application appelante via la méthode ::android::hardware::IPCThreadState::getCallingUid . Une liste des AID peut être trouvée dans libcutils/include/cutils/android_filesystem_config.h .

Délais

À partir d'Android 11, la préparation et les exécutions du modèle peuvent être lancées avec un argument de date limite OptionalTimePoint . Pour les conducteurs capables d'estimer la durée d'une tâche, ce délai permet au conducteur d'abandonner la tâche avant qu'elle ne commence s'il estime que la tâche ne peut pas être terminée avant la date limite. De même, la date limite permet au conducteur d'abandonner une tâche en cours dont il estime qu'elle ne sera pas terminée avant la date limite. L'argument date limite n'oblige pas un pilote à abandonner une tâche si la tâche n'est pas terminée dans les délais ou si la date limite est dépassée. L'argument date limite peut être utilisé pour libérer des ressources de calcul au sein du pilote et redonner le contrôle à l'application plus rapidement qu'il n'est possible sans la date limite.

Les appels NN HAL 1.3 qui incluent les délais OptionalTimePoint comme argument sont :

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

Pour voir une implémentation de référence de la fonctionnalité de date limite pour chacune des méthodes ci-dessus, consultez l'exemple de pilote NNAPI à frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Codes d'erreur

Android 11 inclut quatre valeurs de code d'erreur dans NN HAL 1.3 pour améliorer le rapport d'erreurs, permettant aux conducteurs de mieux communiquer leur état et aux applications de récupérer plus facilement. Ce sont les valeurs du code d'erreur dans ErrorStatus .

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

Sous Android 10 ou version antérieure, un pilote ne pouvait indiquer une panne que via le code d'erreur GENERAL_FAILURE . À partir d'Android 11, les deux codes d'erreur MISSED_DEADLINE peuvent être utilisés pour indiquer que la charge de travail a été abandonnée parce que la date limite a été atteinte ou parce que le pilote a prédit que la charge de travail ne se terminerait pas avant la date limite. Les deux codes d'erreur RESOURCE_EXHAUSTED peuvent être utilisés pour indiquer que la tâche a échoué en raison d'une limitation de ressources au sein du pilote, par exemple le pilote ne disposant pas de suffisamment de mémoire pour l'appel.

La version TRANSIENT des deux erreurs indique que le problème est temporaire et que les futurs appels à la même tâche pourraient réussir après un court délai. Par exemple, ce code d'erreur doit être renvoyé lorsque le conducteur est occupé avec un travail antérieur de longue durée ou gourmand en ressources, mais que la nouvelle tâche se terminerait avec succès si le conducteur n'était pas occupé avec le travail précédent. La version PERSISTENT des deux erreurs indique que les futurs appels à la même tâche échoueront toujours. Par exemple, ce code d'erreur doit être renvoyé lorsque le conducteur estime que la tâche ne sera pas terminée dans les délais, même dans des conditions parfaites, ou que le modèle est intrinsèquement trop volumineux et dépasse les ressources du conducteur.

Validation

La fonctionnalité de qualité de service est testée dans les tests NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ). Cela inclut un ensemble de tests de validation ( TestGenerated/ValidationTest#Test/ ) pour garantir que le pilote rejette les priorités non valides et un ensemble de tests appelé DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) pour garantir que le pilote gère correctement les délais.