A partir de Android 11, la NNAPI ofrece una mejor calidad de servicio (QoS), ya que permite que una app indique las prioridades relativas de sus modelos, el tiempo máximo que se espera para la preparación de un modelo determinado y el tiempo máximo que se espera para que se complete una ejecución determinada. Además, Android 11 presenta valores de error de NNAPI adicionales que permiten que un servicio indique con mayor precisión qué salió mal cuando se produce una falla, de modo que la app cliente pueda reaccionar y recuperarse mejor.
Prioridad
En Android 11 o versiones posteriores, los modelos se preparan con una prioridad en el NN HAL 1.3. Esta prioridad es relativa a otros modelos preparados que pertenecen a la misma app. Las ejecuciones de mayor prioridad pueden usar más recursos de procesamiento que las de menor prioridad y pueden interrumpir o privar las ejecuciones de menor prioridad.
La llamada a NN HAL 1.3 que incluye Priority como argumento explícito es IDevice::prepareModel_1_3.
Ten en cuenta que IDevice::prepareModelFromCache_1_3 incluye implícitamente Priority en los argumentos de la caché.
Existen muchas estrategias posibles para admitir prioridades según las capacidades del controlador y el acelerador. Estas son algunas estrategias:
- Para los controladores que tienen compatibilidad con prioridades integrada, propaga directamente el campo
Priorityal acelerador. - Usa una cola de prioridad por app para admitir diferentes prioridades incluso antes de que una ejecución llegue al acelerador.
Pausar o cancelar los modelos de baja prioridad que se están ejecutando para liberar el acelerador y ejecutar modelos de alta prioridad Para ello, inserta puntos de control en modelos de prioridad baja que, cuando se alcancen, consultan una marca para determinar si la ejecución actual debe detenerse de forma prematura o particiona el modelo en submodelos y consulta la marca entre las ejecuciones de submodelos. Ten en cuenta que el uso de puntos de control o submodelos en modelos preparados con una prioridad puede generar una sobrecarga adicional que no está presente en los modelos sin una prioridad en versiones anteriores a NN HAL 1.3.
- Para admitir la interrupción, conserva el contexto de ejecución, incluida la próxima operación o el submodelo que se ejecutará y cualquier dato intermedio del operando relevante. Usa este contexto de ejecución para reanudar la ejecución más adelante.
- No es necesario admitir la preempción completa, por lo que no se necesita preservar el contexto de ejecución. Debido a que las ejecuciones de modelos de NNAPI son deterministas, las ejecuciones se pueden reiniciar desde cero más adelante.
Android habilita a los servicios a diferenciar entre diferentes apps de llamadas mediante el uso de un AID (UID de Android). HIDL tiene mecanismos integrados para recuperar el UID de la app que realiza la llamada a través del método ::android::hardware::IPCThreadState::getCallingUid. Puedes encontrar una lista de AIDs en libcutils/include/cutils/android_filesystem_config.h.
Fechas límite
A partir de Android 11, la preparación y las ejecuciones de modelos se pueden iniciar con un argumento de fecha límite OptionalTimePoint. Para los conductores que pueden estimar cuánto tiempo lleva una tarea, esta fecha límite les permite abortarla antes de que comience si estiman que no se puede completar antes de la fecha límite. De manera similar, el plazo permite al conductor cancelar una tarea en curso que estima que no se completará antes de la fecha límite.
El argumento de fecha límite no obliga a un controlador a abortar una tarea si esta no se completa antes de la fecha límite o si ya pasó. El argumento de fecha límite se puede usar para liberar recursos de procesamiento dentro del controlador y devolver el control a la app más rápido de lo que es posible sin la fecha límite.
Las llamadas a NN HAL 1.3 que incluyen plazos de OptionalTimePoint como argumento son las siguientes:
IDevice::prepareModel_1_3IDevice::prepareModelFromCache_1_3IPreparedModel::execute_1_3IPreparedModel::executeSynchronously_1_3IPreparedModel::executeFenced
Para ver una implementación de referencia de la función de plazo para cada uno de los métodos anteriores, consulta el controlador de ejemplo de NNAPI en frameworks/ml/nn/driver/sample/SampleDriver.cpp.
Códigos de error
Android 11 incluye cuatro valores de código de error en NN HAL 1.3 para mejorar los informes de errores, lo que permite que los controladores comuniquen mejor su estado y que las apps se recuperen de manera más fluida. Estos son los valores de código de error en ErrorStatus.
MISSED_DEADLINE_TRANSIENTMISSED_DEADLINE_PERSISTENTRESOURCE_EXHAUSTED_TRANSIENTRESOURCE_EXHAUSTED_PERSISTENT
En Android 10 o versiones anteriores, un controlador solo podía indicar una falla a través del código de error GENERAL_FAILURE. A partir de Android 11, se pueden usar los dos códigos de error MISSED_DEADLINE para indicar que la carga de trabajo se abortó porque se alcanzó la fecha límite o porque el controlador predijo que la carga de trabajo no se completaría antes de la fecha límite. Los dos códigos de error RESOURCE_EXHAUSTED se pueden usar para indicar que la tarea falló debido a una limitación de recursos dentro del controlador, por ejemplo, que el controlador no tiene suficiente memoria para la llamada.
La versión TRANSIENT de ambos errores indica que el problema es temporal y que las llamadas futuras a la misma tarea podrían tener éxito después de una breve demora. Por ejemplo, este código de error se debe mostrar cuando el controlador está ocupado con un trabajo anterior de larga duración o intensivo en recursos, pero la tarea nueva se completaría correctamente si el controlador no estuviera ocupado con el trabajo anterior. La versión PERSISTENT de ambos errores indica que siempre se espera que fallen las llamadas futuras a la misma tarea. Por ejemplo, este código de error se debe mostrar cuando el controlador estima que la tarea no se completará antes de la fecha límite, incluso en condiciones perfectas, o que el modelo es demasiado grande y supera los recursos del controlador.
Validación
La funcionalidad de calidad del servicio se prueba en las pruebas de VTS de la NNAPI (VtsHalNeuralnetworksV1_3Target). Esto incluye un conjunto de pruebas de validación (TestGenerated/ValidationTest#Test/) para garantizar que el controlador rechace las prioridades no válidas, y un conjunto de pruebas denominadas DeadlineTest (TestGenerated/DeadlineTest#Test/) para garantizar que el controlador maneje correctamente los plazos.