A HAL de redes neurais 1.2 apresenta o conceito de execuções de pico. Explosão execuções são uma sequência de execuções do mesmo modelo preparado que ocorrem rápida sucessão, como aqueles que operam em quadros de uma captura de câmera ou áudio consecutivo de amostra. Um objeto de burst é usado para controlar um conjunto de execuções de burst e preservar recursos entre as execuções, permitindo que as execuções tenham um overhead menor. Os objetos de ruptura permitem três otimizações:
- Um objeto de burst é criado antes de uma sequência de execuções e liberado quando a sequência terminar. Por isso, o ciclo de vida do burst dicas de objetos para um motorista por quanto tempo ele deve permanecer em um ambiente estado.
- Um objeto burst pode preservar recursos entre execuções. Por exemplo, o driver pode mapear um objeto de memória na primeira execução e armazenar em cache o mapeamento no objeto de burst para reutilização em execuções subsequentes. Qualquer recurso armazenado em cache pode ser liberado quando o objeto de burst é destruído ou quando a NNAPI O ambiente de execução notifica o objeto de burst de que o recurso não é mais necessário.
- Um objeto de explosão usa filas rápidas de mensagens (FMQs, na sigla em inglês) para se comunicar entre os processos do app e do driver. Isso pode reduzir a latência, porque a FMQ ignora o HIDL e transmite dados diretamente para outro processo por um FIFO circular atômico na memória compartilhada. O o processo do consumidor sabe remover um item da fila e começar o processamento Pesquisando o número de elementos no FIFO ou aguardando o evento do FMQ que é sinalizada pelo produtor. Essa flag de evento é um mutex de espaço do usuário rápido (futex).
Uma FMQ é uma estrutura de dados de baixo nível que não oferece garantias de tempo de vida em todos os processos e não tem um mecanismo integrado para determinar se o processo na outra extremidade da FMQ está sendo executado conforme o esperado. Consequentemente, se o produtor do os dados de FMQ morrem, o consumidor pode ficar preso à espera de dados que nunca chegam. Uma solução para esse problema é que o driver associe FMQs ao objeto de burst de nível mais alto para detectar quando a execução de burst terminar.
Como as execuções de burst operam com os mesmos argumentos e retornam os mesmos
resultados que outras rotas de execução, as FMQs subjacentes precisam transmitir os mesmos dados para
e dos drivers de serviço da NNAPI. No entanto, as FMQs só podem transferir
tipos de dados simples. A transferência de dados complexos é feita serializando
e desserializando buffers aninhados (tipos de vetor) diretamente nos FMQs e usando
objetos de callback do HIDL para transferir identificadores de pool de memória sob demanda. O produtor
do FMQ deve enviar as mensagens de solicitação ou de resultado ao consumidor
atomicamente usando MessageQueue::writeBlocking
se a fila estiver bloqueando, ou
usando MessageQueue::write
se a fila não tiver bloqueios.
Interfaces de burst
As interfaces de explosão para a HAL de redes neurais estão em
hardware/interfaces/neuralnetworks/1.2/
e são descritas abaixo. Para mais informações sobre interfaces de explosão na camada
do NDK, consulte
frameworks/ml/nn/runtime/include/NeuralNetworks.h
.
type.hal
types.hal
define o tipo de dados enviados no FMQ.
FmqRequestDatum
: um único elemento de uma representação serializada de um objetoRequest
de execução e um valorMeasureTiming
, que é enviado pela fila de mensagens rápidas.FmqResultDatum
: Um único elemento de uma representação serializada dos valores retornados do uma execução (ErrorStatus
,OutputShapes
eTiming
), que é retornados pela fila de mensagens rápidas.
IBurstContext.hal
IBurstContext.hal
define o objeto de interface HIDL que está no serviço de redes neurais.
IBurstContext
: objeto de contexto para gerenciar os recursos de um burst.
IBurstCallback.hal
IBurstCallback.hal
define o objeto de interface HIDL para um callback criado pelas redes neurais
ambiente de execução e é usado pelo serviço de redes neurais para recuperar hidl_memory
objetos que correspondem aos identificadores de slot.
- IBurstCallback: Objeto de callback usado por um serviço para recuperar objetos de memória.
IPreparedModel.hal
IPreparedModel.hal
é estendido no HAL 1.2 com um método para criar um objeto IBurstContext
de um
modelo preparado.
configureExecutionBurst
: configura um objeto de explosão usado para executar várias inferências em um modelo preparado em sucessão rápida.
Oferecer suporte a execuções de burst em um driver
A maneira mais simples de oferecer suporte a objetos de burst em um serviço NNAPI HIDL é usar o
função utilitária de burst ::android::nn::ExecutionBurstServer::create
, que é
encontrado em
ExecutionBurstServer.h
e empacotados em libneuralnetworks_common
e libneuralnetworks_util
bibliotecas estáticas. Essa função de fábrica tem duas sobrecargas:
- Uma sobrecarga aceita um ponteiro para um objeto
IPreparedModel
. Isso função utilitária usa o métodoexecuteSynchronously
em uma ObjetoIPreparedModel
para executar o modelo. - Uma sobrecarga aceita um objeto
IBurstExecutorWithCache
personalizável, que pode ser usado para armazenar em cache recursos (como mapeamentoshidl_memory
) que persistem em várias execuções.
Cada sobrecarga retorna um objeto IBurstContext
, que representa o burst
) que contém e gerencia a própria linha de execução de listener dedicada. Esta conversa
recebe solicitações do FMQ requestChannel
, realiza a inferência e
retorna os resultados por meio da FMQ resultChannel
. Essa linha de execução e todos os outros
recursos contidos no objeto IBurstContext
são liberados automaticamente
quando o cliente do burst perde a referência a IBurstContext
.
Como alternativa, crie sua própria implementação de IBurstContext
que
entenda como enviar e receber mensagens pelas FMQs requestChannel
e
resultChannel
transmitidas para IPreparedModel::configureExecutionBurst
.
As funções utilitárias de burst estão em
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);
Confira a seguir uma implementação de referência de uma interface de explosão encontrada no
driver de exemplo de redes neurais em
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();
}