Calidad de servicio

A partir de Android 11, NNAPI ofrece una mejor calidad de servicio (QoS) al permitir que una aplicación indique las prioridades relativas de sus modelos, el tiempo máximo esperado para que un modelo determinado esté preparado y el tiempo máximo esperado para una ejecución dada para ser completada. Además, Android 11 introduce valores de error NNAPI adicionales que permiten que un servicio indique con mayor precisión qué salió mal cuando ocurre una falla para que la aplicación cliente pueda reaccionar y recuperarse mejor.

Prioridad

Para Android 11 o superior, los modelos están preparados con prioridad en el NN HAL 1.3. Esta prioridad es relativa a otros modelos preparados propiedad de la misma aplicación. Las ejecuciones de mayor prioridad pueden utilizar más recursos informáticos que las de menor prioridad y pueden adelantarse o privarse de ejecuciones de menor prioridad.

La llamada NN HAL 1.3 que incluye Priority como argumento explícito es IDevice::prepareModel_1_3 . Tenga en cuenta que IDevice::prepareModelFromCache_1_3 incluye implícitamente Priority en los argumentos de la caché.

Hay muchas estrategias posibles para respaldar las prioridades dependiendo de las capacidades del conductor y del acelerador. Aquí hay varias estrategias:

  • Para los conductores que tienen soporte de prioridad incorporado, propague directamente el campo Priority al acelerador.
  • Utilice una cola de prioridad por aplicación para admitir diferentes prioridades incluso antes de que una ejecución llegue al acelerador.

  • Pause o cancele los modelos de baja prioridad que se están ejecutando para liberar el acelerador para ejecutar modelos de alta prioridad. Haga esto insertando puntos de control en modelos de baja prioridad que, cuando se alcanzan, consultan un indicador para determinar si la ejecución actual debe detenerse prematuramente o dividiendo el modelo en submodelos y consultando el indicador entre ejecuciones de submodelos. Tenga en cuenta que el uso de puntos de control o submodelos en modelos preparados con una prioridad puede introducir una sobrecarga adicional que no está presente en los modelos sin prioridad en versiones inferiores a NN HAL 1.3.

    • Para admitir la preferencia, conserve el contexto de ejecución, incluida la siguiente operación o submodelo que se ejecutará y cualquier dato de operando intermedio relevante. Utilice este contexto de ejecución para reanudar la ejecución más adelante.
    • No es necesario el soporte completo de preferencia, por lo que no es necesario conservar el contexto de ejecución. Dado que las ejecuciones del modelo NNAPI son deterministas, las ejecuciones se pueden reiniciar desde cero más adelante.

Android permite que los servicios diferencien entre diferentes aplicaciones de llamadas mediante el uso de un AID (UID de Android). HIDL tiene mecanismos integrados para recuperar el UID de la aplicación que realiza la llamada a través del método ::android::hardware::IPCThreadState::getCallingUid . Puede encontrar una lista de AID en libcutils/include/cutils/android_filesystem_config.h .

Plazos

A partir de Android 11, la preparación y ejecución 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 cancelar la tarea antes de que comience si estima que la tarea no se puede completar antes de la fecha límite. De manera similar, la fecha límite permite al conductor cancelar una tarea en curso que estima que no se completará antes de la fecha límite. El argumento de la fecha límite no obliga a un conductor a cancelar una tarea si la tarea no se completa antes de la fecha límite o si la fecha límite ya pasó. El argumento de la fecha límite se puede utilizar para liberar recursos informáticos dentro del controlador y devolver el control a la aplicación más rápido de lo que es posible sin la fecha límite.

Las llamadas NN HAL 1.3 que incluyen fechas límite OptionalTimePoint como argumento son:

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

Para ver una implementación de referencia de la función de fecha límite para cada uno de los métodos anteriores, consulte el controlador de muestra NNAPI en frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Códigos de error

Android 11 incluye cuatro valores de códigos de error en NN HAL 1.3 para mejorar los informes de errores, lo que permite a los conductores comunicar mejor su estado y las aplicaciones se recuperan con mayor facilidad. Estos son los valores del código de error en ErrorStatus .

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

En Android 10 o versiones anteriores, un controlador solo podía indicar una falla mediante el código de error GENERAL_FAILURE . Desde Android 11, los dos códigos de error MISSED_DEADLINE se pueden usar para indicar que la carga de trabajo se canceló 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, como 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 futuras llamadas a la misma tarea podrían tener éxito después de un breve retraso. Por ejemplo, este código de error debería devolverse cuando el conductor está ocupado con un trabajo anterior de larga duración o que requiere muchos recursos, pero la nueva tarea se completaría exitosamente si el conductor no estuviera ocupado con el trabajo anterior. La versión PERSISTENT de ambos errores indica que siempre se espera que las futuras llamadas a la misma tarea fallen. Por ejemplo, este código de error debe devolverse cuando el conductor estima que la tarea no se completará en la fecha límite incluso en condiciones perfectas, o que el modelo es inherentemente demasiado grande y excede los recursos del conductor.

Validación

La funcionalidad de calidad del servicio se prueba en las pruebas NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ). Esto incluye un conjunto de pruebas de validación ( TestGenerated/ValidationTest#Test/ ) para garantizar que el controlador rechace prioridades no válidas y un conjunto de pruebas denominada DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) para garantizar que el controlador maneje los plazos correctamente.