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.

El NN HAL 1.3 llamada que incluye Priority como un 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 respaldar las prioridades en función de las capacidades del conductor y del acelerador. Aquí hay varias estrategias:

  • Para los conductores que se han incorporado en apoyo prioritario, se propagan directamente la Priority campo para el 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. Hacerlo por cualquiera de los puntos de control en la inserción de los modelos de baja prioridad que, cuando se alcanza, consulta un indicador para determinar si la ejecución actual debe ser detenido antes de tiempo o dividir el modelo en submodelos y consulta de la bandera entre las 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 las 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 ha incorporado mecanismos para recuperar el UID de la aplicación llamando a través del método ::android::hardware::IPCThreadState::getCallingUid . Una lista de coadyuvantes se pueden encontrar en libcutils/include/cutils/android_filesystem_config.h .

Plazos

A partir de Android 11, la preparación del modelo y las ejecuciones pueden ser lanzados con un OptionalTimePoint argumento plazo. 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.

Los NN HAL 1,3 llamadas que incluyen OptionalTimePoint plazos 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, ver el controlador de ejemplo 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 de los códigos de error en ErrorStatus .

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

En Android 10 o inferior, un conductor sólo podría indicar un fallo a través de la GENERAL_FAILURE código de error. De androide 11, los dos MISSED_DEADLINE códigos de error se pueden utilizar para indicar que la carga de trabajo fue abortado debido a que la fecha límite se haya alcanzado o porque el conductor predijo la carga de trabajo no sería completa dentro del plazo. Los dos RESOURCE_EXHAUSTED códigos de error se pueden utilizar para indicar que la tarea no debido a una limitación de recursos en el controlador, como el conductor no tiene suficiente memoria para la llamada.

El TRANSIENT versión de ambos errores indica que el problema es temporal, y que el futuro llama a la misma tarea podría 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 que la nueva tarea se completará correctamente si el controlador no está ocupado con el trabajo anterior. El PERSISTENT versión de ambos errores indica que siempre se espera que las futuras llamadas a la misma tarea a fallar. 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 calidad de la funcionalidad de servicio se pone a prueba en las pruebas NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ). Esto incluye una serie de pruebas para la validación ( TestGenerated/ValidationTest#Test/ ) para asegurar que el conductor rechaza prioridades no válidas y un conjunto de pruebas llamadas DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) para asegurar que maneja el conductor plazos correctamente.