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

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

Более подробную информацию об API нейронных сетей см. в разделе API нейронных сетей .

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

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

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

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

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

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

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

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

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

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

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

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

Компиляция

Фреймворк определяет, какие устройства использовать, когда получает запрос от приложения. В Android 10 приложения могут обнаруживать и указывать устройства, из которых фреймворк выбирает. Для получения дополнительной информации см. Device Discovery and Assignment .

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

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

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

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

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

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

Исполнение

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

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

При использовании асинхронного метода 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 или выше, в случаях, когда несколько выполнений с одной и той же подготовленной моделью выполняются в быстрой последовательности, клиент может выбрать использование объекта burst выполнения для связи между процессами приложения и драйвера. Для получения дополнительной информации см. Burst Executions и Fast Message Queues .

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

Форма выходного сигнала

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

Полезные функции

Кодовая база 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 содержит макросы для упрощения добавления информации systracing в код Neural Networks. Для примера см. вызовы макроса NNTRACE_* в образце драйвера .

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

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

Проверка

Чтобы протестировать реализацию 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 , которое смещение на три)

  • Булево: точное совпадение

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

Тестирование методом «fuzz»

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

Чтобы выполнить fuzz-тестирование для проверки реализации вашего драйвера, измените frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp в тестовой утилите libneuralnetworks_driver_fuzzer , которая находится в AOSP, чтобы включить код вашего драйвера. Для получения дополнительной информации о fuzz-тестировании 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 , работающего на CPU, для той же модели и наборов данных. Это гарантирует, что точность драйвера не хуже, чем у эталонной реализации CPU.

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

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

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

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

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

Использовать МЛТС

Чтобы использовать MLTS:

  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 ) и информацию о версии. См. Device Discovery and Assignment .
  • Метод executeSynchronously вызывается по умолчанию для выполнения синхронного выполнения. Метод execute_1_2 сообщает фреймворку о необходимости выполнения асинхронного выполнения. См. Выполнение .
  • Параметр MeasureTiming для executeSynchronously , execute_1_2 и burst execution указывает, должен ли драйвер измерять длительность выполнения. Результаты сообщаются в структуре Timing . См. Timing .
  • Поддержка исполнений, где один или несколько выходных операндов имеют неизвестный размер или ранг. См. Выходная форма .
  • Поддержка расширений поставщика, которые представляют собой наборы операций и типов данных, определенных поставщиком. Драйвер сообщает о поддерживаемых расширениях через метод IDevice::getSupportedExtensions . См. Расширения поставщика .
  • Возможность объекта burst управлять набором burst-выполнений с использованием быстрых очередей сообщений (FMQ) для связи между процессами приложения и драйвера, что сокращает задержку. См. Burst Executions и Fast Message Queues .
  • Поддержка 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/ .