Ejecuciones en ráfaga y colas de mensajes rápidos

La HAL de redes neuronales 1.2 presenta el concepto de ejecuciones de ráfaga. Las ejecuciones en ráfaga son una secuencia de ejecuciones del mismo modelo preparado que se producen en una sucesión rápida, como las que operan en los fotogramas de una captura de cámara o en muestras de audio sucesivas. Se usa un objeto de ráfaga para controlar un conjunto de ejecuciones de ráfaga y preservar los recursos entre ejecuciones, lo que permite que las ejecuciones tengan una sobrecarga menor. Los objetos Burst permiten tres optimizaciones:

  1. Un objeto de ráfaga se crea antes de una secuencia de ejecuciones y se libera cuando esta finaliza. Debido a esto, la vida útil del objeto de ráfaga le indica al controlador cuánto tiempo debe permanecer en un estado de alto rendimiento.
  2. Un objeto de ráfaga puede preservar recursos entre ejecuciones. Por ejemplo, un controlador puede asignar un objeto de memoria en la primera ejecución y almacenar en caché la asignación en el objeto de ráfaga para reutilizarla en ejecuciones posteriores. Cualquier recurso almacenado en caché se puede liberar cuando se destruye el objeto de ráfaga o cuando el entorno de ejecución de NNAPI notifica al objeto de ráfaga que ya no se requiere el recurso.
  3. Un objeto de ráfaga usa colas de mensajes rápidos (FMQ) para comunicarse entre los procesos de la app y del controlador. Esto puede reducir la latencia, ya que la FMQ pasa por alto HIDL y pasa los datos directamente a otro proceso a través de un FIFO circular atómico en la memoria compartida. El proceso del consumidor sabe cómo quitar un elemento de la cola y comenzar a procesarlo, ya sea a través de la sondeo de la cantidad de elementos en la FIFO o esperando la marca de evento de la FMQ, que indica el productor. Esta marca de evento es un mutex de espacio de usuario rápido (futex).

Una FMQ es una estructura de datos de bajo nivel que no ofrece garantías de tiempo de vida en todos los procesos y no tiene un mecanismo integrado para determinar si el proceso en el otro extremo de la FMQ se ejecuta como se espera. En consecuencia, si el productor de la FMQ falla, es posible que el consumidor quede atascado esperando datos que nunca llegan. Una solución a este problema es que el controlador asocie las FMQ con el objeto de ráfaga de nivel superior para detectar cuándo finalizó la ejecución de la ráfaga.

Debido a que las ejecuciones de ráfaga operan en los mismos argumentos y muestran los mismos resultados que otras instrucciones de ejecución, los FMQ subyacentes deben pasar los mismos datos a los controladores de servicio de NNAPI y desde ellos. Sin embargo, las FMQ solo pueden transferir tipos de datos simples. La transferencia de datos complejos se logra serializando y deserializando búferes anidados (tipos de vectores) directamente en las FMQ y usando objetos de devolución de llamada de HIDL para transferir controladores de grupo de memoria a pedido. El lado del productor de la FMQ debe enviar los mensajes de solicitud o resultado al consumidor de forma atómica con MessageQueue::writeBlocking si la cola está bloqueada o con MessageQueue::write si no lo está.

Interfaces de ráfaga

Las interfaces de ráfaga para el HAL de redes neuronales se encuentran en hardware/interfaces/neuralnetworks/1.2/ y se describen a continuación. Para obtener más información sobre las interfaces de ráfaga en la capa del NDK, consulta frameworks/ml/nn/runtime/include/NeuralNetworks.h.

types.hal

types.hal define el tipo de datos que se envía a través de la FMQ.

  • FmqRequestDatum: Un solo elemento de una representación serializada de un objeto Request de ejecución y un valor MeasureTiming, que se envía a través de la cola de mensajes rápidos.
  • FmqResultDatum: Es un solo elemento de una representación serializada de los valores que se muestran después de una ejecución (ErrorStatus, OutputShapes y Timing), que se muestra a través de la fila de mensajes rápida.

IBurstContext.hal

IBurstContext.hal define el objeto de interfaz HIDL que se encuentra en el servicio de redes neuronales.

  • IBurstContext: Objeto de contexto para administrar los recursos de una ráfaga.

IBurstCallback.hal

IBurstCallback.hal define el objeto de interfaz HIDL para una devolución de llamada creada por el entorno de ejecución de redes neuronales y es utilizado por el servicio de redes neuronales para recuperar objetos hidl_memory correspondientes a los identificadores de ranuras.

  • IBurstCallback: Objeto de devolución de llamada que usa un servicio para recuperar objetos de memoria.

IPreparedModel.hal

IPreparedModel.hal se extiende en HAL 1.2 con un método para crear un objeto IBurstContext a partir de un modelo preparado.

  • configureExecutionBurst: Configura un objeto de ráfaga que se usa para ejecutar varias inferencias en un modelo preparado en rápida sucesión.

Admite ejecuciones en ráfaga en un controlador

La forma más sencilla de admitir objetos burst en un servicio de NNAPI de HIDL es usar la función de utilidad burst ::android::nn::ExecutionBurstServer::create, que se encuentra en ExecutionBurstServer.h y se empaqueta en las bibliotecas estáticas libneuralnetworks_common y libneuralnetworks_util. Esta función de fábrica tiene dos sobrecargas:

  • Una sobrecarga acepta un puntero a un objeto IPreparedModel. Esta función de utilidad usa el método executeSynchronously en un objeto IPreparedModel para ejecutar el modelo.
  • Una sobrecarga acepta un objeto IBurstExecutorWithCache personalizable, que se puede usar para almacenar en caché recursos (como asignaciones de hidl_memory) que persisten en varias ejecuciones.

Cada sobrecarga muestra un objeto IBurstContext (que representa el objeto de ráfaga) que contiene y administra su propio subproceso de objeto de escucha dedicado. Este subproceso recibe solicitudes de la FMQ de requestChannel, realiza la inferencia y, luego, muestra los resultados a través de la FMQ de resultChannel. Este subproceso y todos los demás recursos contenidos en el objeto IBurstContext se liberan automáticamente cuando el cliente del aumento pierde su referencia a IBurstContext.

Como alternativa, puedes crear tu propia implementación de IBurstContext que comprenda cómo enviar y recibir mensajes a través de las FMQ de requestChannel y resultChannel que se pasan a IPreparedModel::configureExecutionBurst.

Las funciones de utilidad de ráfaga se encuentran en ExecutionBurstServer.h.

/**
 * Create automated context to manage FMQ-based executions.
 *
 * This function is intended to be used by a service to automatically:
 * 1) Receive data from a provided FMQ
 * 2) Execute a model with the given information
 * 3) Send the result to the created FMQ
 *
 * @param callback Callback used to retrieve memories corresponding to
 *     unrecognized slots.
 * @param requestChannel Input FMQ channel through which the client passes the
 *     request to the service.
 * @param resultChannel Output FMQ channel from which the client can retrieve
 *     the result of the execution.
 * @param executorWithCache Object which maintains a local cache of the
 *     memory pools and executes using the cached memory pools.
 * @result IBurstContext Handle to the burst context.
 */
static sp<ExecutionBurstServer> create(
        const sp<IBurstCallback>& callback, const FmqRequestDescriptor& requestChannel,
        const FmqResultDescriptor& resultChannel,
        std::shared_ptr<IBurstExecutorWithCache> executorWithCache);

/**
 * Create automated context to manage FMQ-based executions.
 *
 * This function is intended to be used by a service to automatically:
 * 1) Receive data from a provided FMQ
 * 2) Execute a model with the given information
 * 3) Send the result to the created FMQ
 *
 * @param callback Callback used to retrieve memories corresponding to
 *     unrecognized slots.
 * @param requestChannel Input FMQ channel through which the client passes the
 *     request to the service.
 * @param resultChannel Output FMQ channel from which the client can retrieve
 *     the result of the execution.
 * @param preparedModel PreparedModel that the burst object was created from.
 *     IPreparedModel::executeSynchronously will be used to perform the
 *     execution.
 * @result IBurstContext Handle to the burst context.
 */
  static sp<ExecutionBurstServer> create(const sp<IBurstCallback>& callback,
                                         const FmqRequestDescriptor& requestChannel,
                                         const FmqResultDescriptor& resultChannel,
                                         IPreparedModel* preparedModel);

La siguiente es una implementación de referencia de una interfaz de ráfaga que se encuentra en el controlador de muestra de redes neuronales en frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Return<void> SamplePreparedModel::configureExecutionBurst(
        const sp<V1_2::IBurstCallback>& callback,
        const MQDescriptorSync<V1_2::FmqRequestDatum>& requestChannel,
        const MQDescriptorSync<V1_2::FmqResultDatum>& resultChannel,
        configureExecutionBurst_cb cb) {
    NNTRACE_FULL(NNTRACE_LAYER_DRIVER, NNTRACE_PHASE_EXECUTION,
                 "SampleDriver::configureExecutionBurst");
    // Alternatively, the burst could be configured via:
    // const sp<V1_2::IBurstContext> burst =
    //         ExecutionBurstServer::create(callback, requestChannel,
    //                                      resultChannel, this);
    //
    // However, this alternative representation does not include a memory map
    // caching optimization, and adds overhead.
    const std::shared_ptr<BurstExecutorWithCache> executorWithCache =
            std::make_shared<BurstExecutorWithCache>(mModel, mDriver, mPoolInfos);
    const sp<V1_2::IBurstContext> burst = ExecutionBurstServer::create(
            callback, requestChannel, resultChannel, executorWithCache);
    if (burst == nullptr) {
        cb(ErrorStatus::GENERAL_FAILURE, {});
    } else {
        cb(ErrorStatus::NONE, burst);
    }
    return Void();
}