Qualidade de serviço

No Android 11 e versões mais recentes, a NNAPI oferece uma melhor qualidade de serviço (QoS) ao permitir que um app indique as prioridades relativas dos modelos, o tempo máximo esperado para um determinado modelo ser preparado e o tempo máximo esperado para uma determinada execução ser concluída. Além disso, o Android 11 introduz outros valores de erro da NNAPI, permitindo que um serviço indique com mais precisão o que deu errado quando uma falha ocorre para que o app cliente possa reagir e se recuperar melhor.

Prioridade

No Android 11 ou versões mais recentes, os modelos são preparados com uma prioridade na NN HAL 1.3. Essa prioridade é relativa a outros modelos preparados pertencentes ao mesmo app. Execuções de maior prioridade podem usar mais recursos de computação do que as de menor prioridade e podem forçar a interrupção ou a privação de execuções de menor prioridade.

A chamada de NN HAL 1.3 que inclui Priority como argumento explícito é IDevice::prepareModel_1_3. Observe que IDevice::prepareModelFromCache_1_3 inclui Priority implicitamente nos argumentos do cache.

Há muitas estratégias possíveis para oferecer suporte a prioridades, dependendo dos recursos do driver e do acelerador. Confira algumas estratégias:

  • Para drivers com suporte prioritário integrado, propague diretamente o campo Priority para o acelerador.
  • Use uma fila de prioridade por app para oferecer suporte a diferentes prioridades, mesmo antes que uma execução chegue ao acelerador.

  • Pause ou cancele modelos de baixa prioridade que estão sendo executados para liberar o acelerador para executar modelos de alta prioridade. Faça isso inserindo checkpoints em modelos de baixa prioridade que, quando alcançados, consultam uma sinalização para determinar se a execução atual precisa ser interrompida prematuramente ou particionando o modelo em submodelos e consultando a flag entre as execuções de submodelos. O uso de checkpoints ou submodelos em modelos preparados com uma prioridade pode introduzir uma sobrecarga extra que não está presente para modelos sem prioridade em versões anteriores à NN HAL 1.3.

    • Para oferecer suporte à preempção, preserve o contexto de execução, incluindo a próxima operação ou submodelo a ser executado e todos os dados de operando intermediário relevantes. Use esse contexto para retomar a execução mais tarde.
    • A compatibilidade total com preempção não é necessária. Portanto, o contexto de execução não precisa ser preservado. Como as execuções do modelo NNAPI são deterministas, elas podem ser reiniciadas do zero posteriormente.

O Android permite que os serviços diferenciem diferentes apps de chamada usando um AID (UID do Android). O HIDL tem mecanismos integrados para extrair o UID do app de chamada usando o método ::android::hardware::IPCThreadState::getCallingUid. Veja uma lista de AIDs em libcutils/include/cutils/android_filesystem_config.h.

Prazos

No Android 11 e versões mais recentes, a preparação e as execuções de modelo podem ser iniciadas com um argumento de prazo OptionalTimePoint. Para motoristas que conseguem estimar quanto tempo uma tarefa leva, esse prazo permite cancelar a tarefa antes de ela ser iniciada se ele estimar que ela não pode ser concluída antes do prazo. Da mesma forma, o prazo permite que o motorista cancele uma tarefa em andamento que ele estima que não será concluída antes do prazo. O argumento de prazo não força um motorista a cancelar uma tarefa se ela não for concluída dentro do prazo ou se o prazo tiver passado. O argumento de prazo pode ser usado para liberar recursos de computação no driver e retornar o controle ao aplicativo mais rapidamente do que é possível sem o prazo.

As chamadas da NN HAL 1.3 que incluem prazos OptionalTimePoint como argumento são:

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

Para ver uma implementação de referência do recurso de prazo para cada um dos métodos acima, consulte o driver de amostra da NNAPI em frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Códigos de erro

O Android 11 inclui quatro valores de código de erro na NN HAL 1.3 para melhorar a geração de relatórios de erros, permitindo que os drivers comuniquem melhor o estado e os apps para uma recuperação mais tranquila. Estes são os valores do código de erro em ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

No Android 10 ou versões anteriores, um driver só pode indicar uma falha pelo código de erro GENERAL_FAILURE. No Android 11, os dois códigos de erro MISSED_DEADLINE podem ser usados para indicar que a carga de trabalho foi cancelada porque o prazo foi alcançado ou porque o driver previu que a carga de trabalho não seria concluída dentro do prazo. Os dois códigos de erro RESOURCE_EXHAUSTED podem ser usados para indicar que a tarefa falhou devido a uma limitação de recursos no driver, por exemplo, o driver não ter memória suficiente para a chamada.

A versão TRANSIENT de ambos os erros indica que o problema é temporário e que futuras chamadas para a mesma tarefa podem ser bem-sucedidas após um pequeno atraso. Por exemplo, esse código de erro será retornado quando o driver estiver ocupado com trabalhos anteriores de longa duração ou uso intensivo de recursos, mas que a nova tarefa será concluída com sucesso se o driver não estiver ocupado com o trabalho anterior. A versão PERSISTENT de ambos os erros indica que futuras chamadas para a mesma tarefa sempre falharão. Por exemplo, esse código de erro precisa ser retornado quando o motorista estima que a tarefa não será concluída no prazo, mesmo em condições perfeitas, ou que o modelo é inerentemente muito grande e excede os recursos do driver.

Validação

A qualidade da funcionalidade do serviço é testada nos testes VTS da NNAPI (VtsHalNeuralnetworksV1_3Target). Isso inclui um conjunto de testes de validação (TestGenerated/ValidationTest#Test/) para garantir que o driver rejeite prioridades inválidas e um conjunto de testes chamado DeadlineTest (TestGenerated/DeadlineTest#Test/) para garantir que ele processe os prazos corretamente.