Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Calidad de servicio

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 que se prepare un modelo determinado y la cantidad máxima de tiempo que se espera para una ejecución determinada 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 se preparan 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 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 la caché.

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

  • Para los controladores que tienen soporte prioritario integrado, 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 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 introducir una sobrecarga adicional que no está presente para 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 en un momento posterior.
    • No es necesario el soporte de preferencia total, por lo que no es necesario preservar 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 a los servicios diferenciar entre diferentes aplicaciones de llamadas mediante el uso de un AID (UID de Android). HIDL tiene mecanismos incorporados 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 de OptionalTimePoint . Para los conductores que pueden estimar cuánto tiempo lleva una tarea, esta fecha límite permite al conductor abortar 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 permite al conductor abortar 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 al conductor a abortar una tarea si la tarea no se completa antes de la fecha límite o si la fecha límite ha pasado. 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 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ó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 elegancia. 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 GENERAL_FAILURE , un controlador solo podí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 canceló porque se alcanzó la fecha límite o porque el conductor 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á correctamente si el controlador no está 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 debe devolverse cuando el conductor estima que la tarea no se completará 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 rechaza las prioridades no válidas y un conjunto de pruebas llamado DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) para garantizar que el controlador maneja los plazos correctamente.