A partir de Android 11, la NNAPI ofrece una mejor calidad de servicio (QoS) al permitir que una aplicación indique las prioridades relativas de sus modelos, la cantidad máxima de tiempo que se espera para preparar un modelo determinado y la cantidad máxima de tiempo que se espera para una ejecución dada para ser completada. Además, Android 11 presenta 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 se preparan con prioridad en el NN HAL 1.3. Esta prioridad es relativa a otros modelos preparados que pertenecen a la misma aplicación. Las ejecuciones de mayor prioridad pueden usar más recursos informáticos que las ejecuciones de menor prioridad y pueden adelantarse o privar a las 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 caché.
Hay muchas estrategias posibles para apoyar las prioridades dependiendo de las capacidades del conductor y del acelerador. Aquí hay varias estrategias:
- Para los controladores que tienen soporte de prioridad incorporado, propague directamente el campo
Priorityal acelerador. - Use una cola de prioridad por aplicación para admitir diferentes prioridades incluso antes de que una ejecución alcance el acelerador.
Pause o cancele los modelos de baja prioridad que se están ejecutando actualmente 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 generar una sobrecarga adicional que no está presente en los modelos sin prioridad en versiones anteriores 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 en un momento posterior.
- No es necesario el soporte de preferencia completo, por lo que no es necesario conservar el contexto de ejecución. Debido a que las ejecuciones del modelo NNAPI son deterministas, las ejecuciones se pueden reiniciar desde cero en un momento posterior.
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 llama 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 el conductor estima que la tarea no se puede completar antes de la fecha límite. De manera similar, la fecha límite le 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 cancelar una tarea si la tarea no está completa antes de la fecha límite o si la fecha límite ya pasó. El argumento de la fecha límite se puede usar 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 plazos de 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ódigo de error en NN HAL 1.3 para mejorar el informe de errores, lo que permite a los conductores comunicar mejor su estado y que las aplicaciones se recuperen con más gracia. 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 anterior, un controlador solo podría indicar una falla a través del 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 anuló 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 las futuras llamadas a la misma tarea podrían tener éxito después de un breve retraso. Por ejemplo, este código de error debe devolverse cuando el controlador está ocupado con un trabajo anterior de larga duración o que consume muchos recursos, pero la nueva tarea 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 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ía antes de 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 de 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 llamado DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) para garantizar que el controlador maneje los plazos correctamente.