Driver Neural Networks API

Halaman ini menyediakan ringkasan tentang cara mengimplementasikan Neural Networks API (NNAPI) {i>driver<i}. Untuk detail lebih lanjut, lihat dokumentasi yang terdapat dalam definisi HAL file di hardware/interfaces/neuralnetworks Contoh implementasi {i>driver<i} ada di frameworks/ml/nn/driver/sample

Untuk informasi selengkapnya tentang Neural Networks API, lihat Neural Networks API.

HAL Jaringan Neural

Neural Networks (NN) HAL mendefinisikan abstraksi berbagai perangkat, seperti unit pemrosesan grafis (GPU) dan pemroses sinyal digital (DSP), yang ada dalam suatu produk (misalnya, ponsel atau tablet). Pendorong untuk tindakan ini perangkat harus sesuai dengan NN HAL. Antarmuka yang ditetapkan dalam HAL file definisi di hardware/interfaces/neuralnetworks

Alur umum antarmuka antara framework dan {i>driver<i} digambarkan pada gambar 1.

Alur Jaringan Neural

Gambar 1. Alur Jaringan Neural

Inisialisasi

Saat inisialisasi, framework akan mengkueri driver untuk mengetahui kemampuannya menggunakan IDevice::getCapabilities_1_3 Struktur @1.3::Capabilities mencakup semua jenis data dan merepresentasikan performa yang tidak santai menggunakan vektor.

Untuk menentukan cara mengalokasikan komputasi ke perangkat yang tersedia, framework ini menggunakan kemampuan untuk memahami seberapa cepat efisien setiap {i>driver<i} dapat melakukan eksekusi. Untuk memberikan informasi ini, {i>driver <i}harus memberikan angka kinerja standar berdasarkan eksekusi workload referensi.

Untuk menentukan nilai yang ditampilkan oleh pengemudi sebagai respons terhadap IDevice::getCapabilities_1_3, gunakan aplikasi tolok ukur NNAPI untuk mengukur performa untuk jenis data yang sesuai. MobileNet v1 dan v2, asr_float, dan model tts_float direkomendasikan untuk mengukur performa untuk 32-bit nilai floating point dan model terkuantisasi MobileNet v1 dan v2 direkomendasikan untuk nilai terkuantisasi 8-bit. Untuk informasi selengkapnya, lihat Android Machine Learning Test Suite.

Di Android 9 dan yang lebih rendah, struktur Capabilities menyertakan performa pengemudi informasi hanya untuk floating point dan tensor terkuantisasi, jenis data skalar.

Sebagai bagian dari proses inisialisasi, kerangka kerja dapat meminta informasi lebih lanjut, menggunakan IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, dan IDevice::getNumberOfCacheFilesNeeded.

Di antara perangkat dimulai ulang, framework mengharapkan semua kueri yang dijelaskan dalam agar selalu melaporkan nilai yang sama untuk {i>driver<i} tertentu. Jika tidak, aplikasi menggunakan {i>driver<i} itu dapat menyebabkan penurunan kinerja atau perilaku yang tidak tepat.

Kompilasi

Framework menentukan perangkat mana yang akan digunakan ketika menerima permintaan dari . Di Android 10, aplikasi dapat menemukan dan menentukan perangkat yang dipilih oleh kerangka kerja. Untuk informasi selengkapnya, lihat Penemuan dan Penetapan Perangkat.

Pada waktu kompilasi model, framework akan mengirimkan model ke setiap kandidat pengemudi dengan memanggil IDevice::getSupportedOperations_1_3 Setiap driver menampilkan array boolean yang menunjukkan mendukung operasi model. Pengemudi dapat menentukan bahwa ia tidak mendukung operasi tertentu karena sejumlah alasan. Contoh:

  • Driver tidak mendukung jenis data ini.
  • Driver hanya mendukung operasi dengan parameter input tertentu. Sebagai contoh, driver mungkin mendukung 3x3 dan 5x5, tetapi tidak mendukung konvolusi 7x7 operasional bisnis.
  • {i>Driver<i} memiliki batasan memori yang mencegahnya menangani grafik atau input.

Selama kompilasi, input, output, dan operand internal model, seperti dijelaskan dalam OperandLifeTime, dapat memiliki dimensi atau peringkat yang tidak diketahui. Untuk informasi selengkapnya, lihat Bentuk output.

Framework ini menginstruksikan setiap pengemudi yang dipilih untuk bersiap menjalankan subset model dengan memanggil IDevice::prepareModel_1_3 Setiap driver kemudian mengompilasi subset-nya. Misalnya, seorang pengemudi mungkin menghasilkan kode atau membuat salinan bobot yang diurutkan ulang. Karena bisa jadi ada banyak waktu antara kompilasi model dengan eksekusi permintaan, sumber daya seperti bongkahan memori perangkat yang besar tidak ditetapkan selama kompilasi.

Jika berhasil, pengemudi akan menampilkan @1.3::IPreparedModel nama sebutan channel. Jika {i>driver<i} mengembalikan kode kegagalan saat mempersiapkan {i>subset<i}-nya , framework menjalankan seluruh model pada CPU.

Guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat artefak kompilasi cache. Untuk informasi selengkapnya, lihat Kompilasi Menyimpan ke cache.

Eksekusi

Saat aplikasi meminta framework untuk mengeksekusi permintaan, framework akan memanggil tindakan IPreparedModel::executeSynchronously_1_3 Metode HAL secara default untuk melakukan eksekusi sinkron pada model yang sudah disiapkan. Permintaan juga dapat dieksekusi secara asinkron menggunakan execute_1_3 , metode executeFenced (lihat Eksekusi berpagar), atau dieksekusi menggunakan eksekusi burst.

Panggilan eksekusi sinkron meningkatkan performa dan mengurangi threading overhead dibandingkan dengan panggilan asinkron karena kontrol dikembalikan ke metode proses aplikasi hanya setelah eksekusi selesai. Ini berarti bahwa {i>driver<i} tidak memerlukan mekanisme terpisah untuk memberi tahu proses aplikasi bahwa dan eksekusi telah selesai.

Dengan metode execute_1_3 asinkron, kontrol akan kembali ke aplikasi setelah eksekusi dimulai, dan pengemudi harus memberi tahu kerangka kerja ketika eksekusi selesai, dengan menggunakan @1.3::IExecutionCallback.

Parameter Request yang diteruskan ke metode eksekusi mencantumkan input dan output operand yang digunakan untuk eksekusi. Memori yang menyimpan data operand harus gunakan urutan baris-utama dengan dimensi pertama yang melakukan iterasi paling lambat dan tidak memiliki {i>padding<i} di akhir baris mana pun. Untuk informasi selengkapnya tentang jenis operand, lihat Operand.

Untuk driver NN HAL 1.2 atau yang lebih tinggi, saat permintaan selesai, status error, bentuk output, dan informasi waktu ditampilkan ke dalam kerangka kerja. Selama eksekusi, output atau operand internal model bisa memiliki satu atau beberapa dimensi atau peringkat yang tidak diketahui. Saat setidaknya satu output operand memiliki dimensi atau peringkat yang tidak diketahui, pengemudi harus menampilkan informasi output berukuran dinamis.

Untuk pengemudi dengan NN HAL 1.1 atau lebih rendah, hanya status kesalahan yang ditampilkan selesai. Dimensi untuk operand input dan output harus sepenuhnya yang ditentukan agar eksekusi berhasil diselesaikan. Operand internal dapat memiliki satu atau beberapa dimensi yang tidak diketahui, tetapi dimensi tersebut harus memiliki peringkat yang ditentukan.

Untuk permintaan pengguna yang mencakup beberapa driver, framework bertanggung jawab untuk yang mencadangkan memori perantara dan untuk mengurutkan panggilan ke setiap driver.

Beberapa permintaan dapat dimulai secara paralel pada @1.3::IPreparedModel Driver dapat menjalankan permintaan secara paralel atau membuat serialisasi eksekusi.

Framework ini dapat meminta pengemudi untuk menyimpan lebih dari satu model yang disiapkan. Sebagai contoh, menyiapkan model m1, menyiapkan m2, mengeksekusi permintaan r1 pada m1, mengeksekusi r2 pada m2, jalankan r3 pada m1, jalankan r4 pada m2, rilis (dijelaskan di Pembersihan) m1, lalu rilis m2.

Untuk menghindari eksekusi pertama yang lambat yang dapat mengakibatkan pengalaman pengguna yang buruk (untuk misalnya, ketersendatan frame pertama), driver harus melakukan sebagian besar inisialisasi pada fase kompilasi. Inisialisasi pada eksekusi pertama harus dibatasi pada tindakan yang berdampak negatif pada kesehatan sistem bila dilakukan dini, seperti mencadangkan {i>buffer <i}sementara yang besar atau meningkatkan kecepatan jam perangkat. {i>Driver<i} yang hanya dapat menyiapkan sejumlah model serentak mungkin memiliki perlu melakukan inisialisasi pada eksekusi pertama.

Di Android 10 atau yang lebih tinggi, dalam kasus di mana beberapa dengan model persiapan yang sama dan dieksekusi dengan cepat, klien dapat memilih untuk menggunakan burst untuk berkomunikasi antara aplikasi dan proses driver. Untuk selengkapnya informasi, lihat Burst Executions dan Fast Message Queues.

Guna meningkatkan performa untuk beberapa eksekusi secara berurutan dengan cepat, driver dapat berpegang pada {i>buffer <i}sementara atau meningkatkan kecepatan jam. Membuat watchdog thread disarankan untuk melepaskan resource jika tidak ada permintaan baru yang dibuat setelah periode waktu tertentu.

Bentuk output

Untuk permintaan yang satu atau beberapa operand output tidak memiliki semua dimensi yang ditentukan, {i>driver<i} harus memberikan daftar bentuk output yang berisi informasi dimensi untuk setiap operand output setelah eksekusi. Untuk selengkapnya informasi tentang dimensi, lihat OutputShape

Jika eksekusi gagal karena buffer output berukuran kecil, driver harus menunjukkan operand output mana yang memiliki ukuran buffer yang tidak mencukupi dalam daftar bentuk output, dan harus melaporkan informasi dimensi sebanyak mungkin, menggunakan nol untuk dimensi yang tidak diketahui.

Waktu

Di Android 10, aplikasi dapat meminta eksekusi waktu jika aplikasi telah menentukan satu perangkat yang akan digunakan selama proses kompilasi. Sebagai detail, lihat MeasureTiming dan Penemuan dan Penetapan Perangkat. Dalam hal ini, Driver NN HAL 1.2 harus mengukur durasi eksekusi atau melaporkan UINT64_MAX (ke menunjukkan bahwa durasi tidak tersedia) saat mengeksekusi permintaan. Pengemudi harus meminimalkan penalti performa yang disebabkan oleh pengukuran eksekusi durasi.

Pengemudi melaporkan durasi berikut dalam mikrodetik dalam Timing struktur:

  • Waktu eksekusi di perangkat: Tidak termasuk waktu eksekusi dalam {i>driver<i}, yang berjalan pada prosesor {i>host<i}.
  • Waktu eksekusi di driver: Termasuk waktu eksekusi pada perangkat.

Durasi ini harus mencakup waktu saat eksekusi ditangguhkan, karena ketika eksekusi telah didahului oleh tugas lain atau ketika menunggu sumber daya tersedia.

Ketika {i>driver<i} belum diminta untuk mengukur durasi eksekusi, atau kapan terjadi kesalahan eksekusi, {i>driver<i} harus melaporkan durasi UINT64_MAX. Bahkan saat pengemudi diminta untuk mengukur eksekusi sebagai gantinya, tindakan ini dapat melaporkan UINT64_MAX untuk waktu di perangkat, waktu di {i>driver<i}, atau keduanya. Saat pengemudi melaporkan kedua durasi tersebut sebagai nilai selain UINT64_MAX, waktu eksekusi dalam driver harus sama dengan atau melebihi waktu pada perangkat.

Eksekusi berpagar

Di Android 11, NNAPI mengizinkan eksekusi menunggu daftar handle sync_fence dan secara opsional menampilkan objek sync_fence, yang akan diberi sinyal saat eksekusi selesai. Hal ini mengurangi {i>overhead<i} untuk model urutan dan kasus penggunaan streaming. Eksekusi berpagar juga memungkinkan lebih banyak interoperabilitas yang efisien dengan komponen lain yang dapat memberi sinyal atau menunggu sync_fence. Untuk mengetahui informasi selengkapnya tentang sync_fence, lihat Framework sinkronisasi.

Dalam eksekusi dengan fence, framework akan memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron dengan fence pada model yang telah disiapkan dengan vektor fence sinkronisasi yang akan ditunggu. Jika tugas asinkron selesai sebelum panggilan ditampilkan, handle kosong dapat ditampilkan untuk sync_fence. Channel Objek IFencedExecutionCallback juga harus ditampilkan untuk mengizinkan framework untuk melakukan kueri status {i>error<i} dan informasi durasi.

Setelah eksekusi selesai, dua hal berikut nilai timing untuk mengukur durasi eksekusi, IFencedExecutionCallback::getExecutionInfo

  • timingLaunched: Durasi dari saat executeFenced dipanggil hingga executeFenced dipanggil menandakan syncFence yang ditampilkan.
  • timingFenced: Durasi sejak semua fence sinkronisasi yang ditunggu eksekusi akan diberi sinyal saat executeFenced memberikan sinyal syncFence yang ditampilkan.

Alur kontrol

Untuk perangkat yang menjalankan Android 11 atau yang lebih tinggi, NNAPI mencakup dua operasi alur kontrol, IF dan WHILE, yang menggunakan model lain sebagai argumen dan menjalankannya secara bersyarat (IF) atau berulang kali (WHILE). Sebagai informasi selengkapnya tentang cara menerapkannya, lihat Alur kontrol.

Kualitas layanan

Di Android 11, NNAPI menyertakan peningkatan kualitas (QoS) dengan memungkinkan aplikasi menunjukkan prioritas relatif waktu maksimum yang diharapkan untuk mempersiapkan model, dan jumlah waktu maksimum yang diharapkan untuk menyelesaikan eksekusi. Sebagai informasi selengkapnya, lihat Kualitas Layanan.

Pembersihan

Saat aplikasi selesai menggunakan model yang sudah disiapkan, framework akan merilis referensinya ke @1.3::IPreparedModel . Saat objek IPreparedModel tidak lagi direferensikan, objek tersebut secara otomatis dihancurkan di layanan {i>driver<i} yang membuatnya. Spesifik per model sumber daya dapat diklaim kembali saat ini dalam implementasi {i>driver<i} dari destruktor. Jika layanan pengemudi ingin objek IPreparedModel otomatis dihancurkan bila tidak lagi dibutuhkan oleh klien, maka harus tidak ditahan referensi apa pun ke objek IPreparedModel setelah objek IPreparedeModel dikembalikan melalui IPreparedModelCallback::notify_1_3

Penggunaan CPU

Driver diharapkan menggunakan CPU untuk menyiapkan komputasi. Pengemudi tidak seharusnya menggunakan CPU untuk melakukan komputasi grafik karena hal itu mengganggu proses kemampuan kerangka kerja untuk mengalokasikan pekerjaan dengan benar. Pengemudi harus melaporkan bagian yang tidak dapat ditangani kerangka kerja dan membiarkan kerangka kerja menangani beristirahat.

Framework ini menyediakan implementasi CPU untuk semua operasi NNAPI kecuali untuk operasi yang ditentukan vendor. Untuk informasi selengkapnya, lihat Ekstensi Vendor.

Tujuan yang diperkenalkan di Android 10 (level API 29) hanya memiliki implementasi CPU referensi untuk memverifikasi bahwa uji CTS dan VTS sudah benar. Implementasi yang dioptimalkan disertakan dalam machine learning seluler framework lebih disukai daripada implementasi CPU NNAPI.

Fungsi utilitas

Codebase NNAPI menyertakan fungsi utilitas yang dapat digunakan oleh driver layanan IT perusahaan mereka.

Tujuan frameworks/ml/nn/common/include/Utils.h berisi berbagai fungsi utilitas, seperti yang digunakan untuk melakukan {i>logging<i} dan untuk mengonversi antara berbagai versi NN HAL.

  • VLogging: VLOG adalah makro wrapper di sekitar LOG Android yang hanya mencatat pesan jika tag yang sesuai disetel di debug.nn.vlog saat ini. initVLogMask() harus dipanggil sebelum panggilan ke VLOG. Makro VLOG_IS_ON dapat berupa digunakan untuk memeriksa apakah VLOG saat ini diaktifkan, sehingga memungkinkan logging yang rumit kode yang akan dilewati jika tidak diperlukan. Nilai properti harus salah satu hal berikut:

    • String kosong, menunjukkan bahwa tidak ada logging yang harus dilakukan.
    • Token 1 atau all, yang menunjukkan bahwa semua logging harus dilakukan.
    • Daftar tag, yang dipisahkan oleh spasi, koma, atau titik dua, yang menunjukkan {i>logging<i} mana yang harus dilakukan. Tag-nya adalah compilation, cpuexe, driver, execution, manager, dan model.

  • compliantWithV1_*: Menampilkan true jika objek NN HAL dapat dikonversi ke jenis versi HAL yang sama tanpa kehilangan informasi. Sebagai Misalnya, memanggil compliantWithV1_0 di V1_2::Model akan menampilkan false jika model mencakup jenis operasi yang diperkenalkan dalam NN HAL 1.1 atau NN HAL 1.2.

  • convertToV1_*: Mengonversi objek NN HAL dari satu versi ke versi lainnya. Peringatan akan dicatat jika konversi menyebabkan hilangnya informasi (yang adalah, jika jenis versi baru tidak dapat sepenuhnya merepresentasikan nilai).

  • Kemampuan: nonExtensionOperandPerformance dan update fungsi dapat digunakan untuk membangun Capabilities::operandPerformance kolom tersebut.

  • Properti kueri jenis: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData, nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

Tujuan frameworks/ml/nn/common/include/ValidateHal.h berisi fungsi utilitas untuk memvalidasi bahwa objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya.

  • validate*: Menampilkan true jika objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya. Jenis dan jenis ekstensi OEM tidak divalidasi. Misalnya, validateModel menampilkan false jika berisi operasi yang mereferensikan indeks operand yang tidak ada, atau operasi yang tidak didukung pada versi HAL itu.

Tujuan frameworks/ml/nn/common/include/Tracing.h file berisi makro untuk menyederhanakan penambahan informasi systracing ke kode Jaringan Neural. Sebagai contoh, lihat pemanggilan makro NNTRACE_* pada contoh driver.

Tujuan frameworks/ml/nn/common/include/GraphDump.h file berisi fungsi utilitas untuk membuang konten Model dalam bentuk untuk tujuan proses debug.

  • graphDump: Menulis representasi model di Graphviz (.dot) ke streaming yang ditentukan (jika tersedia) atau ke logcat (jika tidak ada streaming yang disediakan).

Validasi

Untuk menguji implementasi NNAPI, gunakan pengujian VTS dan CTS yang disertakan dalam framework Android. VTS melatih pengemudi Anda secara langsung (tanpa menggunakan ), sedangkan CTS melatihnya secara tidak langsung melalui kerangka kerja. Ini menguji setiap metode API dan memverifikasi bahwa semua operasi didukung oleh {i>driver<i} bekerja dengan benar dan memberikan hasil yang memenuhi persyaratan presisi.

Persyaratan presisi dalam CTS dan VTS untuk NNAPI adalah sebagai berikut:

  • Floating point: abs(yang diharapkan - aktual) <= atol + rtol * abs(diharapkan); dalam hal ini:

    • Untuk fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • Untuk fp16, atol = rtol = 5.0f * 0,0009765625f

  • Terkuantisasi: diskon satu per satu (kecuali untuk mobilenet_quantized, yang kurang dari tiga)

  • Boolean: pencocokan persis

Salah satu cara CTS menguji NNAPI adalah dengan membuat grafik pseudorandom tetap yang digunakan untuk menguji dan membandingkan hasil eksekusi dari setiap {i>driver<i} dengan Implementasi referensi NNAPI. Untuk pengemudi dengan NN HAL 1.2 atau lebih tinggi, jika tidak memenuhi kriteria presisi, CTS melaporkan error dan mengeluarkan file spesifikasi untuk model yang gagal pada /data/local/tmp untuk proses debug. Untuk detail selengkapnya tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h

Uji kegagalan (fuzz testing)

Tujuan dari uji fuzz adalah untuk menemukan kerusakan, pernyataan, pelanggaran memori, atau perilaku yang tidak ditentukan secara umum dalam kode yang sedang diuji karena faktor seperti input yang tidak terduga. Untuk pengujian fuzz NNAPI, Android menggunakan pengujian berdasarkan libFuzzer, yang merupakan efisien dalam fuzzing karena mereka menggunakan cakupan garis kasus uji sebelumnya untuk menghasilkan input acak baru. Misalnya, libFuzzer mendukung kasus pengujian yang menjalankan baris kode baru. Ini sangat mengurangi waktu yang dibutuhkan pengujian untuk menemukan kode yang bermasalah.

Untuk melakukan pengujian fuzz guna memvalidasi implementasi driver Anda, ubah frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp dalam utilitas pengujian libneuralnetworks_driver_fuzzer yang ditemukan di AOSP untuk menyertakan kode {i>driver<i} Anda. Untuk informasi selengkapnya tentang pengujian fuzz NNAPI, lihat frameworks/ml/nn/runtime/test/android_fuzzing/README.md

Keamanan

Karena proses aplikasi berkomunikasi langsung dengan proses {i>driver<i}, pengemudi harus memvalidasi argumen panggilan yang diterima. Validasi ini diverifikasi oleh VTS. Kode validasi ada di dalam frameworks/ml/nn/common/include/ValidateHal.h

Pengemudi juga harus memastikan bahwa aplikasi tidak boleh mengganggu aplikasi saat menggunakan perangkat yang sama.

Android Machine Learning Test Suite

Android Machine Learning Test Suite (MLTS) adalah benchmark NNAPI yang disertakan dalam CTS dan VTS untuk memvalidasi akurasi model nyata di perangkat vendor. Tujuan benchmark mengevaluasi latensi dan akurasi, serta membandingkan performa driver hasil dengan hasil menggunakan TF Lite yang berjalan pada CPU, untuk model dan set data yang sama. Hal ini memastikan bahwa akurasi pengemudi tidak lebih buruk dibandingkan implementasi referensi CPU.

Developer platform Android juga menggunakan MLTS untuk mengevaluasi latensi dan akurasi pengemudi.

Tolok ukur NNAPI dapat ditemukan dalam dua project dalam AOSP:

Model dan set data

Tolok ukur NNAPI menggunakan model dan set data berikut.

  • Float dan u8 MobileNetV1 dikuantisasi dalam berbagai ukuran, dijalankan terhadap subset kecil (1.500 gambar) dari Set Data Gambar Terbuka v4.
  • Float dan u8 MobileNetV2 dikuantisasi dalam berbagai ukuran, dijalankan terhadap subset kecil (1.500 gambar) dari Set Data Gambar Terbuka v4.
  • model akustik berbasis memori jangka pendek (LSTM) untuk text-to-speech, berlari melawan sebagian kecil dari kumpulan CMU Arctic.
  • Model akustik berbasis LSTM untuk pengenalan ucapan otomatis, yang dijalankan di subset kecil dari {i>dataset<i} LibriSpeech.

Untuk mengetahui informasi selengkapnya, lihat platform/test/mlts/models.

Pengujian stres

Android Machine Learning Test Suite menyertakan serangkaian uji error untuk memvalidasi ketahanan pengemudi dalam kondisi penggunaan berat atau di sudut jalan kasus yang dialami klien perilaku model.

Semua uji error menyediakan fitur berikut:

  • Deteksi hang: Jika klien NNAPI berhenti selama pengujian, pengujian gagal dengan alasan kegagalan HANG dan rangkaian pengujian melanjutkan ke pengujian berikutnya.
  • Deteksi error klien NNAPI: Pengujian bertahan dari error dan pengujian klien gagal dengan alasan kegagalan CRASH.
  • Deteksi tabrakan pengemudi: Pengujian dapat mendeteksi tabrakan pengemudi yang menyebabkan kegagalan pada panggilan NNAPI. Perhatikan bahwa mungkin terjadi error di proses driver yang tidak menyebabkan kegagalan NNAPI dan tidak menyebabkan pengujian gagal. Untuk menangani kegagalan semacam ini, sebaiknya jalankan tail pada log sistem untuk {i>error<i} atau masalah terkait {i>driver<i}.
  • Penargetan semua akselerator yang tersedia: Pengujian dijalankan terhadap semua {i>driver<i} yang tersedia.

Semua uji error memiliki empat kemungkinan hasil berikut:

  • SUCCESS: Eksekusi selesai tanpa error.
  • FAILURE: Eksekusi gagal. Biasanya disebabkan oleh kegagalan ketika menguji model, yang menunjukkan bahwa {i>driver<i} gagal mengompilasi atau mengeksekusi model.
  • HANG: Proses pengujian menjadi tidak responsif.
  • CRASH: Proses pengujian mengalami error.

Untuk informasi selengkapnya tentang pengujian daya tahan dan daftar lengkap uji error, lihat platform/test/mlts/benchmark/README.txt

Menggunakan MLTS

Untuk menggunakan MLTS:

  1. Hubungkan perangkat target ke workstation dan pastikan perangkat tersebut dapat dijangkau melalui adb terlebih dahulu. Ekspor perangkat target ANDROID_SERIAL variabel lingkungan jika lebih dari satu perangkat terhubung.

  2. cd ke direktori sumber level teratas Android.

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

    Di akhir proses tolok ukur, hasilnya dibacakan sebagai halaman HTML dan diteruskan ke xdg-open.

Untuk mengetahui informasi selengkapnya, lihat platform/test/mlts/benchmark/README.txt.

Versi HAL Jaringan Neural

Bagian ini menjelaskan perubahan yang diperkenalkan di Android dan Neural Versi HAL Jaringan.

Android 11

Android 11 memperkenalkan NN HAL 1.3, yang menyertakan mengikuti perubahan penting.

  • Dukungan untuk kuantisasi 8-bit yang ditandatangani dalam NNAPI. Menambahkan TENSOR_QUANT8_ASYMM_SIGNED jenis operand. Pengemudi dengan NN HAL 1.3 yang mendukung operasi dengan kuantisasi yang tidak ditandatangani juga harus mendukung varian bertanda tangan operasi tersebut. Saat menjalankan versi yang ditandatangani dan tidak ditandatangani, terkuantisasi, pengemudi harus memberikan hasil yang sama hingga offset sebesar 128. Ada lima pengecualian untuk persyaratan ini: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2, dan QUANTIZED_16BIT_LSTM. Operasi QUANTIZED_16BIT_LSTM tidak mendukung operand bertanda dan empat operasi lainnya mendukung kuantisasi yang ditandatangani tetapi tidak memerlukan hasilnya sama.
  • Dukungan untuk eksekusi dengan fence di mana framework memanggil IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron dengan fence pada model yang telah disiapkan dengan vektor fence sinkronisasi yang akan ditunggu. Untuk informasi selengkapnya, lihat Eksekusi berpagar.
  • Dukungan untuk alur kontrol. Menambahkan operasi IF dan WHILE, yang menggunakan model lain sebagai argumen dan menjalankannya secara bersyarat (IF) atau berulang kali (WHILE). Untuk informasi selengkapnya, lihat Alur kontrol.
  • Peningkatan kualitas layanan (QoS) karena aplikasi dapat menunjukkan prioritas modelnya, jumlah waktu maksimum yang diharapkan untuk model yang akan dipersiapkan, dan jumlah waktu maksimum yang diharapkan untuk pelaksanaan tugas. Untuk informasi selengkapnya, lihat Kualitas Layanan.
  • Dukungan untuk domain memori yang menyediakan antarmuka alokator untuk {i>buffer<i} yang dikelola oleh {i>driver<i}. Hal ini memungkinkan penerusan memori native perangkat di seluruh eksekusi, sehingga menekan penyalinan dan transformasi data yang tidak perlu di antara eksekusi berurutan pada {i>driver<i} yang sama. Untuk informasi selengkapnya, lihat Domain memori.

Android 10

Android 10 memperkenalkan NN HAL 1.2, yang menyertakan mengikuti perubahan penting.

  • Struktur Capabilities mencakup semua jenis data termasuk skalar tipe data, dan merepresentasikan kinerja yang tidak santai menggunakan vektor, bukan daripada {i>field<i} bernama.
  • Metode getVersionString dan getType memungkinkan framework untuk mengambil informasi jenis perangkat (DeviceType) dan versi. Lihat Penemuan dan Penetapan Perangkat.
  • Metode executeSynchronously dipanggil secara default untuk melakukan dan mengeksekusinya secara sinkron. Metode execute_1_2 memberi tahu framework untuk menjalankan eksekusi secara asinkron. Lihat Eksekusi.
  • Parameter MeasureTiming ke executeSynchronously, execute_1_2, dan eksekusi burst menentukan apakah driver akan mengukur eksekusi durasi. Hasilnya dilaporkan dalam struktur Timing. Lihat Waktu.
  • Dukungan untuk eksekusi jika satu atau beberapa operand output memiliki alamat yang tidak diketahui dimensi atau peringkat. Lihat Bentuk output.
  • Dukungan untuk ekstensi vendor, yang merupakan kumpulan dari kumpulan yang ditentukan vendor operasi dan tipe data. Pengemudi melaporkan ekstensi yang didukung melalui metode IDevice::getSupportedExtensions. Lihat Ekstensi Vendor.
  • Kemampuan objek burst untuk mengontrol serangkaian eksekusi burst menggunakan antrean pesan cepat (FMQ) untuk berkomunikasi antara aplikasi dan driver proses, sehingga mengurangi latensi. Lihat Burst Executions dan Fast Message Queues.
  • Dukungan untuk AHardwareBuffer agar driver dapat melakukan eksekusi tanpa menyalin data. Lihat AHardwareBuffer.
  • Meningkatkan dukungan untuk caching artefak kompilasi guna mengurangi waktu digunakan untuk kompilasi saat aplikasi dimulai. Lihat Pembuatan Cache Kompilasi.

Android 10 memperkenalkan jenis operand berikut dan operasional bisnis.

  • Jenis operand

    • 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

  • Operasi

    • 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 memperkenalkan update untuk banyak operasional bisnis. Pembaruan utamanya terkait dengan berikut ini:

  • Dukungan untuk tata letak memori NCHW
  • Dukungan untuk tensor dengan peringkat yang berbeda dari 4 pada softmax dan operasi normalisasi
  • Dukungan untuk konvolusi yang dilebarkan
  • Dukungan untuk input dengan kuantisasi campuran dalam ANEURALNETWORKS_CONCATENATION

Daftar di bawah ini menunjukkan operasi yang dimodifikasi dalam Android 10. Untuk lengkap detail perubahan, lihat OperationCode dalam dokumentasi referensi 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

Android 9

NN HAL 1.1 diperkenalkan pada Android 9 dan mencakup hal-hal berikut perubahan.

  • IDevice::prepareModel_1_1 menyertakan ExecutionPreference . Pengemudi dapat menggunakan ini untuk menyesuaikan persiapannya, mengetahui bahwa aplikasi lebih memilih untuk menghemat baterai atau akan mengeksekusi model dalam beberapa panggilan cepat berturut-turut.
  • Sembilan operasi baru telah ditambahkan: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE.
  • Aplikasi dapat menetapkan bahwa komputasi float 32-bit dapat dijalankan menggunakan rentang float 16-bit dan/atau presisi dengan menetapkan Model.relaxComputationFloat32toFloat16 hingga true. Capabilities struct memiliki kolom tambahan relaxedFloat32toFloat16Performance, jadi {i>driver<i} dapat melaporkan kinerja yang longgar ke kerangka kerja.

Android 8.1

Neural Networks HAL (1.0) awal dirilis di Android 8.1. Untuk selengkapnya informasi, lihat /neuralnetworks/1.0/