Драйверы API нейронных сетей

На этой странице представлен обзор того, как реализовать драйвер API нейронных сетей (NNAPI). Дополнительные сведения см. в документации, найденной в файлах определений HAL в hardware/interfaces/neuralnetworks . Пример реализации драйвера находится в frameworks/ml/nn/driver/sample .

Дополнительные сведения об API нейронных сетей см. в разделе API нейронных сетей .

Нейронные сети HAL

Нейронные сети (NN) HAL определяют абстракцию различных устройств , таких как графические процессоры (GPU) и цифровые сигнальные процессоры (DSP), которые находятся в продукте (например, телефоне или планшете). Драйверы для этих устройств должны соответствовать NN HAL. Интерфейс указан в файлах определения HAL в hardware/interfaces/neuralnetworks .

Общий поток интерфейса между фреймворком и драйвером изображен на рисунке 1.

Поток нейронных сетей

Рисунок 1. Поток нейронных сетей

Инициализация

При инициализации платформа запрашивает у драйвера его возможности, используя IDevice::getCapabilities_1_3 . Структура @1.3::Capabilities включает все типы данных и представляет нерасслабленную производительность с помощью вектора.

Чтобы определить, как распределять вычисления между доступными устройствами, платформа использует возможности, чтобы понять, насколько быстро и насколько эффективно каждый драйвер может выполнять выполнение. Чтобы предоставить эту информацию, драйвер должен предоставить стандартизированные показатели производительности, основанные на выполнении эталонных рабочих нагрузок.

Чтобы определить значения, которые драйвер возвращает в ответ на IDevice::getCapabilities_1_3 , используйте тестовое приложение NNAPI для измерения производительности для соответствующих типов данных. Модели MobileNet v1 и v2, asr_float и tts_float рекомендуются для измерения производительности для 32-битных значений с плавающей запятой, а квантованные модели MobileNet v1 и v2 рекомендуются для 8-битных квантованных значений. Дополнительные сведения см. в разделе Тестовый набор для машинного обучения Android .

В Android 9 и более ранних версиях структура Capabilities включает сведения о производительности драйвера только для тензоров с плавающей запятой и квантованных тензоров и не включает скалярные типы данных.

В рамках процесса инициализации платформа может запросить дополнительную информацию, используя IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensions и IDevice::getNumberOfCacheFilesNeeded .

Между перезагрузками продукта платформа ожидает, что все запросы, описанные в этом разделе, всегда будут сообщать одни и те же значения для данного драйвера. В противном случае приложение, использующее этот драйвер, может демонстрировать снижение производительности или неправильное поведение.

Сборник

Платформа определяет, какие устройства использовать, когда получает запрос от приложения. В Android 10 приложения могут обнаруживать и указывать устройства, которые выбирает платформа. Дополнительные сведения см. в разделе Обнаружение и назначение устройств .

Во время компиляции модели платформа отправляет модель каждому драйверу-кандидату, вызывая IDevice::getSupportedOperations_1_3 . Каждый драйвер возвращает массив логических значений, указывающих, какие операции модели поддерживаются. Драйвер может определить, что он не может поддерживать данную операцию по ряду причин. Например:

  • Драйвер не поддерживает этот тип данных.
  • Драйвер поддерживает только операции с определенными входными параметрами. Например, драйвер может поддерживать операции свертки 3x3 и 5x5, но не 7x7.
  • Драйвер имеет ограничения памяти, не позволяющие ему обрабатывать большие графики или входные данные.

Во время компиляции входные, выходные и внутренние операнды модели, как описано в OperandLifeTime , могут иметь неизвестные размерности или ранг. Дополнительные сведения см. в разделе Выходная форма .

Платформа инструктирует каждый выбранный драйвер подготовиться к выполнению подмножества модели, вызывая IDevice::prepareModel_1_3 . Затем каждый драйвер компилирует свое подмножество. Например, драйвер может сгенерировать код или создать переупорядоченную копию весов. Поскольку между компиляцией модели и выполнением запросов может пройти значительное время, такие ресурсы, как большие блоки памяти устройства, не должны назначаться во время компиляции.

В случае успеха драйвер возвращает дескриптор @1.3::IPreparedModel . Если драйвер возвращает код ошибки при подготовке своего подмножества модели, платформа запускает всю модель на ЦП.

Чтобы сократить время компиляции при запуске приложения, драйвер может кэшировать артефакты компиляции. Дополнительные сведения см. в разделе Кэширование компиляции .

Исполнение

Когда приложение запрашивает платформу для выполнения запроса, платформа по умолчанию вызывает метод HAL IPreparedModel::executeSynchronously_1_3 для выполнения синхронного выполнения на подготовленной модели. Запрос также может выполняться асинхронно с помощью метода execute_1_3 , метода executeFenced (см. Огражденное выполнение ) или выполняться с использованием пакетного выполнения .

Вызовы синхронного выполнения повышают производительность и сокращают накладные расходы на многопоточность по сравнению с асинхронными вызовами, поскольку управление возвращается процессу приложения только после завершения выполнения. Это означает, что драйверу не нужен отдельный механизм для уведомления процесса приложения о завершении выполнения.

При использовании асинхронного метода execute_1_3 управление возвращается процессу приложения после начала выполнения, и драйвер должен уведомить платформу о завершении выполнения с помощью @1.3::IExecutionCallback .

Параметр Request , передаваемый методу execute, содержит список входных и выходных операндов, используемых для выполнения. Память, в которой хранятся данные операнда, должна использовать порядок строк с первым измерением, итерация которого является самой медленной, и не иметь заполнения в конце любой строки. Дополнительные сведения о типах операндов см. в разделе Операнды .

Для драйверов NN HAL 1.2 или более поздних версий при завершении запроса в инфраструктуру возвращаются статус ошибки, форма вывода и информация о времени. Во время выполнения выходные или внутренние операнды модели могут иметь одну или несколько неизвестных размерностей или неизвестный ранг. Когда по крайней мере один выходной операнд имеет неизвестную размерность или ранг, драйвер должен возвращать выходные данные динамического размера.

Для драйверов с NN HAL 1.1 или ниже после выполнения запроса возвращается только статус ошибки. Размерности для входных и выходных операндов должны быть полностью указаны для успешного завершения выполнения. Внутренние операнды могут иметь одно или несколько неизвестных измерений, но они должны иметь определенный ранг.

Для пользовательских запросов, которые охватывают несколько драйверов, платформа отвечает за резервирование промежуточной памяти и за последовательность вызовов каждого драйвера.

Несколько запросов могут быть инициированы параллельно на одном и том же @1.3::IPreparedModel . Драйвер может выполнять запросы параллельно или сериализовать выполнение.

Фреймворк может попросить драйвер сохранить более одной подготовленной модели. Например, подготовьте модель m1 , подготовьте m2 , выполните запрос r1 на m1 , выполните r2 на m2 , выполните r3 на m1 , выполните r4 на m2 , освободите (описано в разделе « Очистка ») m1 и освободите m2 .

Чтобы избежать медленного первого выполнения, которое может привести к плохому взаимодействию с пользователем (например, к заиканию первого кадра), драйвер должен выполнять большинство инициализаций на этапе компиляции. Инициализация при первом выполнении должна быть ограничена действиями, которые негативно влияют на работоспособность системы при раннем выполнении, такими как резервирование больших временных буферов или увеличение тактовой частоты устройства. Драйверам, которые могут подготовить только ограниченное количество параллельных моделей, возможно, придется выполнить их инициализацию при первом выполнении.

В Android 10 или более поздней версии в случаях, когда несколько запусков с одной и той же подготовленной моделью выполняются в быстрой последовательности, клиент может выбрать использование объекта пакета выполнения для связи между процессами приложения и драйвера. Дополнительные сведения см. в разделе Пакетные выполнения и очереди быстрых сообщений .

Чтобы повысить производительность при многократном выполнении в быстрой последовательности, драйвер может удерживать временные буферы или увеличивать тактовую частоту. Рекомендуется создать сторожевой поток для высвобождения ресурсов, если новые запросы не создаются по истечении фиксированного периода времени.

Выходная форма

Для запросов, в которых для одного или нескольких выходных операндов не указаны все измерения, драйвер после выполнения должен предоставить список выходных фигур, содержащих информацию о размерах для каждого выходного операнда. Дополнительные сведения об измерениях см. в разделе OutputShape .

Если выполнение завершается ошибкой из-за недостаточного размера выходного буфера, драйвер должен указать, какие выходные операнды имеют недостаточный размер буфера в списке выходных фигур, и должен сообщить как можно больше информации о размерах, используя ноль для неизвестных размеров.

Сроки

В Android 10 приложение может запросить время выполнения, если приложение указало одно устройство для использования в процессе компиляции. Дополнительные сведения см. MeasureTiming и Device Discovery and Assignment . В этом случае драйвер NN HAL 1.2 должен измерять продолжительность выполнения или сообщать UINT64_MAX (чтобы указать, что продолжительность недоступна) при выполнении запроса. Драйвер должен свести к минимуму любые потери производительности, возникающие в результате измерения продолжительности выполнения.

Драйвер сообщает следующие значения длительности в микросекундах в структуре Timing :

  • Время выполнения на устройстве: не включает время выполнения в драйвере, работающем на хост-процессоре.
  • Время выполнения в драйвере: включает время выполнения на устройстве.

Эти длительности должны включать время, когда выполнение приостановлено, например, когда выполнение было вытеснено другими задачами или когда оно ожидает освобождения ресурса.

Если драйверу не было предложено измерить продолжительность выполнения или возникла ошибка выполнения, драйвер должен сообщать продолжительность как UINT64_MAX . Даже когда драйвер попросили измерить продолжительность выполнения, он может вместо этого сообщить UINT64_MAX для времени на устройстве, времени в драйвере или обоих. Когда драйвер сообщает обе длительности как значение, отличное от UINT64_MAX , время выполнения в драйвере должно быть равно или превышать время на устройстве.

Огражденное исполнение

В Android 11 NNAPI позволяет выполнениям ожидать списка дескрипторов sync_fence и, при необходимости, возвращать объект sync_fence , о котором сигнализируется, когда выполнение завершено. Это снижает накладные расходы для небольших моделей последовательностей и вариантов использования потоковой передачи. Огражденное выполнение также обеспечивает более эффективное взаимодействие с другими компонентами, которые могут сигнализировать или ожидать sync_fence . Дополнительные сведения о sync_fence см. в разделе Synchronization Framework .

При изолированном выполнении платформа вызывает метод IPreparedModel::executeFenced для запуска изолированного асинхронного выполнения на подготовленной модели с ожидаемым вектором ограждений синхронизации. Если асинхронная задача завершается до возврата вызова, для sync_fence может быть возвращен пустой дескриптор. Также должен быть возвращен объект IFencedExecutionCallback , чтобы платформа могла запрашивать информацию о статусе ошибки и продолжительности.

После завершения выполнения следующие два значения времени , измеряющие продолжительность выполнения, можно запросить с помощью IFencedExecutionCallback::getExecutionInfo .

  • timingLaunched : продолжительность с момента executeFenced до момента, когда executeFenced сигнализирует о возвращаемом syncFence .
  • timingFenced : продолжительность, с которой сигнализируются все ограничения синхронизации, которых ожидает выполнение, до момента, когда executeFenced сигнализирует о возвращенном syncFence .

Поток управления

Для устройств под управлением Android 11 или более поздней версии NNAPI включает две операции потока управления, IF и WHILE , которые принимают другие модели в качестве аргументов и выполняют их условно ( IF ) или повторно ( WHILE ). Дополнительные сведения о том, как это реализовать, см. в разделе Поток управления .

Качество обслуживания

В Android 11 NNAPI включает улучшенное качество обслуживания (QoS), позволяя приложению указывать относительные приоритеты своих моделей, максимальное количество времени, ожидаемое для подготовки модели, и максимальное количество времени, ожидаемое для выполнения. должен быть завершен. Дополнительные сведения см. в разделе Качество обслуживания .

Очистка

Когда приложение завершает использование подготовленной модели, платформа освобождает ссылку на объект @1.3::IPreparedModel . Когда на объект IPreparedModel больше не ссылаются, он автоматически уничтожается в службе драйвера, которая его создала. Ресурсы, специфичные для модели, могут быть восстановлены в это время в реализации драйвера деструктора. Если служба драйвера хочет, чтобы объект IPreparedModel автоматически уничтожался, когда он больше не нужен клиенту, она не должна содержать никаких ссылок на объект IPreparedModel после того, как объект IPreparedeModel был возвращен с помощью IPreparedModelCallback::notify_1_3 .

использование процессора

Ожидается, что драйверы будут использовать ЦП для настройки вычислений. Драйверы не должны использовать ЦП для выполнения вычислений графа, потому что это препятствует способности платформы правильно распределять работу. Драйвер должен сообщать фреймворку о тех частях, которые он не может обработать, и пусть фреймворк обрабатывает все остальное.

Платформа обеспечивает реализацию ЦП для всех операций NNAPI, кроме операций, определяемых поставщиком. Дополнительные сведения см. в разделе Расширения поставщика .

Операции, представленные в Android 10 (уровень API 29), имеют только эталонную реализацию ЦП для проверки правильности тестов CTS и VTS. Оптимизированные реализации, включенные в мобильные платформы машинного обучения, предпочтительнее реализации ЦП NNAPI.

Вспомогательные функции

Кодовая база NNAPI включает служебные функции, которые могут использоваться службами драйверов.

Файл frameworks/ml/nn/common/include/Utils.h содержит различные служебные функции, например те, которые используются для ведения журнала и преобразования между различными версиями NN HAL.

  • LOG : VLOG — это макрос-оболочка для журнала Android, который регистрирует сообщение только в том случае, если в свойстве debug.nn.vlog установлен соответствующий тег. initVLogMask() должен вызываться перед любыми вызовами VLOG . Макрос VLOG_IS_ON можно использовать для проверки того, включен ли в данный момент VLOG , что позволяет пропустить сложный код регистрации, если он не нужен. Значение свойства должно быть одним из следующих:

    • Пустая строка, указывающая на то, что запись в журнал производиться не будет.
    • Маркер 1 или all , указывающий, что необходимо вести все журналы.
    • Список тегов, разделенных пробелами, запятыми или двоеточиями, указывающих, какая регистрация должна выполняться. Теги: compilation , cpuexe , driver , execution , manager и model .

  • compliantWithV1_* : возвращает true , если объект NN HAL можно преобразовать в тот же тип другой версии HAL без потери информации. Например, вызов compliantWithV1_0 для V1_2::Model возвращает false , если модель включает типы операций, введенные в NN HAL 1.1 или NN HAL 1.2.

  • convertToV1_* : Преобразует объект NN HAL из одной версии в другую. Предупреждение регистрируется, если преобразование приводит к потере информации (то есть, если новая версия типа не может полностью представить значение).

  • Capabilities: функции nonExtensionOperandPerformance и update могут использоваться для построения поля Capabilities::operandPerformance .

  • Запрос свойств типов: isExtensionOperandType , isExtensionOperationType , nonExtensionSizeOfData , nonExtensionOperandSizeOfData , nonExtensionOperandTypeIsScalar , tensorHasUnspecifiedDimensions .

Файл frameworks/ml/nn/common/include/ValidateHal.h содержит служебные функции для проверки того, что объект NN HAL действителен в соответствии со спецификацией его версии HAL.

  • validate* : возвращает true , если объект NN HAL действителен в соответствии со спецификацией его версии HAL. Типы OEM и типы расширений не проверяются. Например, validateModel возвращает false , если модель содержит операцию, которая ссылается на индекс операнда, который не существует, или операцию, которая не поддерживается в этой версии HAL.

Файл frameworks/ml/nn/common/include/Tracing.h содержит макросы, упрощающие добавление информации о системной трассировке в код нейронных сетей. В качестве примера см. вызовы макросов NNTRACE_* в образце драйвера .

Файл frameworks/ml/nn/common/include/GraphDump.h содержит служебную функцию для создания дампа содержимого Model в графической форме в целях отладки.

  • graphDump : записывает представление модели в формате Graphviz ( .dot ) в указанный поток (если предоставлен) или в logcat (если поток не предоставлен).

Проверка

Чтобы протестировать реализацию NNAPI, используйте тесты VTS и CTS, включенные в платформу Android. VTS использует ваши драйверы напрямую (без использования фреймворка), тогда как CTS использует их косвенно через фреймворк. Они проверяют каждый метод API и проверяют, что все операции, поддерживаемые драйверами, работают правильно и дают результаты, соответствующие требованиям точности.

Требования к точности в CTS и VTS для NNAPI следующие:

  • С плавающей запятой: абс (ожидаемое - фактическое) <= atol + rtol * абс (ожидаемое); куда:

    • Для fp32 atol = 1e-5f, rtol = 5.0f * 1,1920928955078125e-7
    • Для fp16 atol = rtol = 5,0f * 0,0009765625f

  • Квантование: смещение на единицу (кроме mobilenet_quantized , которое отличается смещением на три)

  • Логическое значение: точное совпадение

Одним из способов, которым CTS тестирует NNAPI, является создание фиксированных псевдослучайных графов, используемых для тестирования и сравнения результатов выполнения каждого драйвера с эталонной реализацией NNAPI. Для драйверов с NN HAL 1.2 или выше, если результаты не соответствуют критериям точности, CTS сообщает об ошибке и создает дамп файла спецификации для неисправной модели в /data/local/tmp для отладки. Дополнительные сведения о критериях точности см. TestRandomGraph.cpp и TestHarness.h .

Нечеткое тестирование

Цель нечеткого тестирования — найти сбои, утверждения, нарушения памяти или общее неопределенное поведение в тестируемом коде из-за таких факторов, как неожиданные входные данные. Для нечеткого тестирования NNAPI Android использует тесты, основанные на libFuzzer , которые эффективны при фаззинге, поскольку они используют линейное покрытие предыдущих тестовых случаев для создания новых случайных входных данных. Например, libFuzzer отдает предпочтение тестовым примерам, которые выполняются на новых строках кода. Это значительно сокращает время, затрачиваемое тестами на поиск проблемного кода.

Чтобы выполнить нечеткое тестирование для проверки реализации вашего драйвера, измените frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp в тестовой утилите libneuralnetworks_driver_fuzzer , найденной в AOSP, чтобы включить код вашего драйвера. Для получения дополнительной информации о нечетком тестировании NNAPI см. frameworks/ml/nn/runtime/test/android_fuzzing/README.md .

Безопасность

Поскольку процессы приложений взаимодействуют напрямую с процессом драйвера, драйверы должны проверять аргументы получаемых вызовов. Эта проверка подтверждается VTS. Код проверки находится в frameworks/ml/nn/common/include/ValidateHal.h .

Драйверы также должны гарантировать, что приложения не могут мешать другим приложениям при использовании одного и того же устройства.

Набор тестов машинного обучения для Android

Android Machine Learning Test Suite (MLTS) — это эталонный тест NNAPI, включенный в CTS и VTS для проверки точности реальных моделей на устройствах поставщиков. Бенчмарк оценивает задержку и точность, а также сравнивает результаты драйверов с результатами использования TF Lite , работающего на ЦП, для той же модели и наборов данных. Это гарантирует, что точность драйвера не хуже эталонной реализации ЦП.

Разработчики платформы Android также используют MLTS для оценки задержки и точности драйверов.

Бенчмарк NNAPI можно найти в двух проектах AOSP:

Модели и наборы данных

Тест NNAPI использует следующие модели и наборы данных.

  • MobileNetV1 float и u8, квантованные в разных размерах, работают с небольшим подмножеством (1500 изображений) Open Images Dataset v4.
  • MobileNetV2 с плавающей запятой и u8, квантованные в разных размерах, работают с небольшим подмножеством (1500 изображений) набора данных Open Images v4.
  • Акустическая модель на основе долговременной кратковременной памяти (LSTM) для преобразования текста в речь, работающая с небольшим подмножеством набора CMU Arctic.
  • Акустическая модель на основе LSTM для автоматического распознавания речи, работающая с небольшим подмножеством набора данных LibriSpeech.

Дополнительные сведения см. в разделе platform/test/mlts/models .

Нагрузочное тестирование

Набор тестов для машинного обучения Android включает серию краш-тестов для проверки устойчивости драйверов в условиях интенсивного использования или в крайних случаях поведения клиентов.

Все краш-тесты обеспечивают следующие возможности:

  • Обнаружение зависания: если клиент NNAPI зависает во время теста, тест завершается с ошибкой по причине HANG , и набор тестов переходит к следующему тесту.
  • Обнаружение сбоя клиента NNAPI: тесты выдерживают сбои клиента, а тесты завершаются сбоем по причине сбоя CRASH .
  • Обнаружение сбоя драйвера: тесты могут обнаружить сбой драйвера, который вызывает сбой при вызове NNAPI. Обратите внимание, что в процессах драйвера могут быть сбои, которые не вызывают сбой NNAPI и не приводят к сбою теста. Чтобы покрыть этот тип сбоя, рекомендуется выполнить команду tail в системном журнале для ошибок или сбоев, связанных с драйвером.
  • Ориентация на все доступные ускорители: тесты выполняются для всех доступных драйверов.

Все краш-тесты имеют следующие четыре возможных исхода:

  • SUCCESS : Выполнение завершено без ошибок.
  • FAILURE : выполнение не выполнено. Обычно вызывается сбоем при тестировании модели, указывающим на то, что драйверу не удалось скомпилировать или выполнить модель.
  • HANG : Процесс тестирования перестал отвечать.
  • CRASH : Процесс тестирования завершился сбоем.

Дополнительные сведения о стресс-тестировании и полный список краш-тестов см. в platform/test/mlts/benchmark/README.txt .

Использование МЛТС

Для использования МЛТС:

  1. Подключите целевое устройство к вашей рабочей станции и убедитесь, что оно доступно через adb . Экспортируйте переменную среды ANDROID_SERIAL целевого устройства, если подключено более одного устройства.

  2. cd в исходный каталог Android верхнего уровня.

    source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh

    В конце выполнения теста результаты представляются в виде HTML-страницы и передаются в xdg-open .

Дополнительные сведения см. в разделе platform/test/mlts/benchmark/README.txt .

Версии HAL для нейронных сетей

В этом разделе описаны изменения, внесенные в версии Android и Neural Networks HAL.

Андроид 11

Android 11 представляет NN HAL 1.3, который включает следующие заметные изменения.

  • Поддержка подписанного 8-битного квантования в NNAPI. Добавляет тип операнда TENSOR_QUANT8_ASYMM_SIGNED . Драйверы с NN HAL 1.3, поддерживающие операции беззнакового квантования, также должны поддерживать знаковые варианты этих операций. При выполнении подписанных и неподписанных версий большинства квантованных операций драйверы должны давать одинаковые результаты до смещения 128. Есть пять исключений из этого требования: CAST , HASHTABLE_LOOKUP , LSH_PROJECTION , PAD_V2 и QUANTIZED_16BIT_LSTM . Операция QUANTIZED_16BIT_LSTM не поддерживает операнды со знаком, а остальные четыре операции поддерживают квантование со знаком, но не требуют, чтобы результаты были одинаковыми.
  • Поддержка изолированных исполнений, когда платформа вызывает метод IPreparedModel::executeFenced для запуска изолированного асинхронного выполнения на подготовленной модели с ожидаемым вектором ограждений синхронизации. Дополнительные сведения см. в разделе Защищенное выполнение .
  • Поддержка потока управления. Добавляет операции IF и WHILE , которые принимают другие модели в качестве аргументов и выполняют их условно ( IF ) или повторно ( WHILE ). Дополнительные сведения см. в разделе Поток управления .
  • Улучшенное качество обслуживания (QoS), поскольку приложения могут указывать относительные приоритеты своих моделей, максимальное количество времени, ожидаемое для подготовки модели, и максимальное количество времени, ожидаемое для завершения выполнения. Дополнительные сведения см. в разделе Качество обслуживания .
  • Поддержка доменов памяти, предоставляющих интерфейсы распределителя для буферов, управляемых драйвером. Это позволяет передавать встроенную память устройства между выполнениями, подавляя ненужное копирование и преобразование данных между последовательными выполнениями на одном и том же драйвере. Дополнительные сведения см. в разделе Домены памяти .

Андроид 10

Android 10 представляет NN HAL 1.2, который включает следующие заметные изменения.

  • Структура Capabilities включает все типы данных, включая скалярные типы данных, и представляет нерасслабленную производительность с использованием вектора, а не именованных полей.
  • getVersionString и getType позволяют платформе получать информацию о типе устройства ( DeviceType ) и версии. См. Обнаружение и назначение устройств .
  • Метод executeSynchronously вызывается по умолчанию для синхронного выполнения. Метод execute_1_2 указывает платформе выполнять выполнение асинхронно. См. Исполнение .
  • Параметр MeasureTiming для executeSynchronously , execute_1_2 и пакетного выполнения указывает, должен ли драйвер измерять продолжительность выполнения. Результаты заносятся в Timing структуру. См. Сроки .
  • Поддержка исполнений, в которых один или несколько выходных операндов имеют неизвестное измерение или ранг. См. Форма вывода .
  • Поддержка расширений поставщиков, которые представляют собой наборы операций и типов данных, определенных поставщиком. Драйвер сообщает о поддерживаемых расширениях с помощью метода IDevice::getSupportedExtensions . См. Расширения поставщика .
  • Возможность пакетного объекта управлять набором пакетных выполнений с использованием быстрых очередей сообщений (FMQ) для связи между приложениями и процессами драйвера, что снижает задержку. См. Пакетные выполнения и Очереди быстрых сообщений .
  • Поддержка AHardwareBuffer, позволяющая драйверу выполнять выполнение без копирования данных. См. AHardwareBuffer .
  • Улучшена поддержка кэширования артефактов компиляции для сокращения времени компиляции при запуске приложения. См. Кэширование компиляции .

В Android 10 представлены следующие типы операндов и операций.

  • Типы операндов

    • ANEURALNETWORKS_BOOL
    • ANEURALNETWORKS_FLOAT16
    • ANEURALNETWORKS_TENSOR_BOOL8
    • ANEURALNETWORKS_TENSOR_FLOAT16
    • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
    • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL

  • Операции

    • ANEURALNETWORKS_ABS
    • ANEURALNETWORKS_ARGMAX
    • ANEURALNETWORKS_ARGMIN
    • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
    • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
    • ANEURALNETWORKS_CAST
    • ANEURALNETWORKS_CHANNEL_SHUFFLE
    • ANEURALNETWORKS_DETECTION_POSTPROCESSING
    • ANEURALNETWORKS_EQUAL
    • ANEURALNETWORKS_EXP
    • ANEURALNETWORKS_EXPAND_DIMS
    • ANEURALNETWORKS_GATHER
    • ANEURALNETWORKS_GENERATE_PROPOSALS
    • ANEURALNETWORKS_GREATER
    • ANEURALNETWORKS_GREATER_EQUAL
    • ANEURALNETWORKS_GROUPED_CONV_2D
    • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
    • ANEURALNETWORKS_INSTANCE_NORMALIZATION
    • ANEURALNETWORKS_LESS
    • ANEURALNETWORKS_LESS_EQUAL
    • ANEURALNETWORKS_LOG
    • ANEURALNETWORKS_LOGICAL_AND
    • ANEURALNETWORKS_LOGICAL_NOT
    • ANEURALNETWORKS_LOGICAL_OR
    • ANEURALNETWORKS_LOG_SOFTMAX
    • ANEURALNETWORKS_MAXIMUM
    • ANEURALNETWORKS_MINIMUM
    • ANEURALNETWORKS_NEG
    • ANEURALNETWORKS_NOT_EQUAL
    • ANEURALNETWORKS_PAD_V2
    • ANEURALNETWORKS_POW
    • ANEURALNETWORKS_PRELU
    • ANEURALNETWORKS_QUANTIZE
    • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
    • ANEURALNETWORKS_RANDOM_MULTINOMIAL
    • ANEURALNETWORKS_REDUCE_ALL
    • ANEURALNETWORKS_REDUCE_ANY
    • ANEURALNETWORKS_REDUCE_MAX
    • ANEURALNETWORKS_REDUCE_MIN
    • ANEURALNETWORKS_REDUCE_PROD
    • ANEURALNETWORKS_REDUCE_SUM
    • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
    • ANEURALNETWORKS_ROI_ALIGN
    • ANEURALNETWORKS_ROI_POOLING
    • ANEURALNETWORKS_RSQRT
    • ANEURALNETWORKS_SELECT
    • ANEURALNETWORKS_SIN
    • ANEURALNETWORKS_SLICE
    • ANEURALNETWORKS_SPLIT
    • ANEURALNETWORKS_SQRT
    • ANEURALNETWORKS_TILE
    • ANEURALNETWORKS_TOPK_V2
    • ANEURALNETWORKS_TRANSPOSE_CONV_2D
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

Android 10 представляет обновления для многих существующих операций. Обновления в основном связаны со следующим:

  • Поддержка схемы памяти NCHW
  • Поддержка тензоров с рангом, отличным от 4, в операциях softmax и нормализации.
  • Поддержка расширенных извилин
  • Поддержка входов со смешанным квантованием в ANEURALNETWORKS_CONCATENATION

В приведенном ниже списке показаны операции, измененные в Android 10. Полную информацию об изменениях см. в разделе OperationCode в справочной документации NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

Андроид 9

NN HAL 1.1 представлен в Android 9 и включает следующие заметные изменения.

  • IDevice::prepareModel_1_1 включает параметр ExecutionPreference . Водитель может использовать это для настройки подготовки, зная, что приложение предпочитает экономить заряд батареи или будет выполнять модель в быстрых последовательных вызовах.
  • Добавлено девять новых операций: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
  • Приложение может указать, что 32-разрядные вычисления с плавающей запятой могут выполняться с использованием 16-разрядного диапазона и/или точности с плавающей запятой, задав для параметра Model.relaxComputationFloat32toFloat16 значение true . Структура Capabilities имеет дополнительное поле relaxedFloat32toFloat16Performance , чтобы драйвер мог сообщать платформе о сниженной производительности.

Андроид 8.1

Первоначальный Neural Networks HAL (1.0) был выпущен в Android 8.1. Для получения дополнительной информации см. /neuralnetworks/1.0/ .