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

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

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

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

HAL нейронных сетей (NN) определяет абстракцию различных устройств , таких как графические процессоры (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 , передаваемый методу выполнения, перечисляет входные и выходные операнды, используемые для выполнения. Память, в которой хранятся данные операнда, должна использовать порядок строк, при этом первое измерение выполняет самую медленную итерацию и не должно иметь заполнения в конце любой строки. Дополнительные сведения о типах операндов см. в разделе Операнды .

Для драйверов 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 см. в разделе Платформа синхронизации .

При изолированном выполнении платформа вызывает метод 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.

  • VLogging: VLOG — это макрос-обертка вокруг LOG 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 из одной версии в другую. Предупреждение регистрируется, если преобразование приводит к потере информации (то есть, если новая версия типа не может полностью представить значение).

  • Возможности: функции 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 ) в указанный поток (если он указан) или в логарифм (если поток не указан).

Валидация

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

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

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

    • Для fp32 atol=1e-5f, rtol=5.0f*1.1920928955078125e-7
    • Для fp16 atol = rtol = 5.0f * 0.0009765625f

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

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

Одним из способов тестирования NNAPI CTS является создание фиксированных псевдослучайных графов, используемых для тестирования и сравнения результатов выполнения каждого драйвера с эталонной реализацией 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 (MLTS) — это тест NNAPI, включенный в CTS и VTS, для проверки точности реальных моделей на устройствах поставщиков. Тест оценивает задержку и точность и сравнивает результаты драйверов с результатами использования TF Lite, работающего на ЦП, для той же модели и наборов данных. Это гарантирует, что точность драйвера не будет хуже, чем у эталонной реализации ЦП.

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

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

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

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

  • MobileNetV1 с плавающей запятой и u8, квантованные в разных размерах, выполняются на небольшом подмножестве (1500 изображений) набора данных Open Images 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/ .