Driver API Jaringan Neural

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

Untuk informasi lebih lanjut tentang Neural Networks API, lihat Neural Networks API .

Jaringan Neural HAL

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). Driver untuk perangkat ini harus sesuai dengan NN HAL. Antarmuka ditentukan dalam file definisi HAL di hardware/interfaces/neuralnetworks .

Alur umum antarmuka antara kerangka kerja dan driver digambarkan pada Gambar 1.

Aliran Jaringan Neural

Gambar 1. Alur Jaringan Syaraf Tiruan

Inisialisasi

Saat inisialisasi, kerangka kerja menanyakan kemampuan drivernya menggunakan IDevice::getCapabilities_1_3 . Struktur @1.3::Capabilities mencakup semua tipe data dan mewakili kinerja non-relaks menggunakan vektor.

Untuk menentukan cara mengalokasikan komputasi ke perangkat yang tersedia, kerangka kerja ini menggunakan kemampuan untuk memahami seberapa cepat dan seberapa efisien energi setiap driver dapat melakukan eksekusi. Untuk memberikan informasi ini, pengemudi harus memberikan angka kinerja standar berdasarkan pelaksanaan beban kerja referensi.

Untuk menentukan nilai yang dikembalikan driver sebagai respons terhadap IDevice::getCapabilities_1_3 , gunakan aplikasi benchmark NNAPI untuk mengukur performa tipe data terkait. Model MobileNet v1 dan v2, asr_float , dan tts_float direkomendasikan untuk mengukur kinerja nilai floating point 32-bit dan model terkuantisasi MobileNet v1 dan v2 direkomendasikan untuk nilai terkuantisasi 8-bit. Untuk informasi selengkapnya, lihat Rangkaian Uji Pembelajaran Mesin Android .

Di Android 9 dan yang lebih rendah, struktur Capabilities menyertakan informasi performa driver hanya untuk floating point dan tensor terkuantisasi, serta tidak menyertakan tipe data skalar.

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

Di antara proses reboot produk, framework mengharapkan semua kueri yang dijelaskan di bagian ini selalu melaporkan nilai yang sama untuk driver tertentu. Jika tidak, aplikasi yang menggunakan driver tersebut mungkin menunjukkan penurunan kinerja atau perilaku yang salah.

Kompilasi

Framework ini menentukan perangkat mana yang akan digunakan saat menerima permintaan dari suatu aplikasi. Di Android 10, aplikasi dapat menemukan dan menentukan perangkat yang dipilih oleh framework. Untuk informasi lebih lanjut, lihat Penemuan dan Penetapan Perangkat .

Pada waktu kompilasi model, kerangka kerja mengirimkan model ke setiap kandidat driver dengan memanggil IDevice::getSupportedOperations_1_3 . Setiap driver mengembalikan array boolean yang menunjukkan operasi model mana yang didukung. Seorang pengemudi dapat menentukan bahwa ia tidak dapat mendukung operasi tertentu karena sejumlah alasan. Misalnya:

  • Pengemudi tidak mendukung tipe data.
  • Pengemudi hanya mendukung operasi dengan parameter masukan tertentu. Misalnya, driver mungkin mendukung operasi konvolusi 3x3 dan 5x5, tetapi tidak mendukung operasi konvolusi 7x7.
  • Pengemudi memiliki keterbatasan memori yang mencegahnya menangani grafik atau masukan yang besar.

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

Kerangka kerja ini menginstruksikan setiap driver yang dipilih untuk bersiap mengeksekusi subset model dengan memanggil IDevice::prepareModel_1_3 . Setiap driver kemudian mengkompilasi subsetnya. Misalnya, driver mungkin menghasilkan kode atau membuat salinan bobot yang disusun ulang. Karena terdapat banyak waktu antara kompilasi model dan eksekusi permintaan, sumber daya seperti sejumlah besar memori perangkat tidak boleh ditetapkan selama kompilasi.

Jika berhasil, driver mengembalikan pegangan @1.3::IPreparedModel . Jika driver mengembalikan kode kegagalan saat menyiapkan subset modelnya, kerangka kerja akan menjalankan seluruh model pada CPU.

Untuk mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat menyimpan artefak kompilasi dalam cache. Untuk informasi lebih lanjut, lihat Kompilasi Caching .

Eksekusi

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

Panggilan eksekusi sinkron meningkatkan kinerja dan mengurangi overhead threading dibandingkan dengan panggilan asinkron karena kontrol dikembalikan ke proses aplikasi hanya setelah eksekusi selesai. Artinya, driver tidak memerlukan mekanisme terpisah untuk memberi tahu proses aplikasi bahwa eksekusi telah selesai.

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

Parameter Request yang diteruskan ke metode eksekusi mencantumkan operan input dan output yang digunakan untuk eksekusi. Memori yang menyimpan data operan harus menggunakan urutan baris-mayor dengan dimensi pertama yang melakukan iterasi paling lambat dan tidak memiliki padding di akhir baris mana pun. Untuk informasi selengkapnya tentang jenis operan, lihat Operan .

Untuk driver NN HAL 1.2 atau lebih tinggi, ketika permintaan selesai, status kesalahan, bentuk keluaran , dan informasi waktu dikembalikan ke kerangka kerja. Selama eksekusi, keluaran atau operan internal model dapat memiliki satu atau lebih dimensi yang tidak diketahui atau peringkat yang tidak diketahui. Ketika setidaknya satu operan keluaran memiliki dimensi atau peringkat yang tidak diketahui, driver harus mengembalikan informasi keluaran berukuran dinamis.

Untuk driver dengan NN HAL 1.1 atau lebih rendah, hanya status kesalahan yang dikembalikan ketika permintaan selesai. Dimensi operan masukan dan keluaran harus ditentukan sepenuhnya agar eksekusi dapat diselesaikan dengan sukses. Operan internal dapat memiliki satu atau lebih dimensi yang tidak diketahui, namun harus memiliki peringkat tertentu.

Untuk permintaan pengguna yang mencakup beberapa driver, kerangka kerja bertanggung jawab untuk memesan memori perantara dan mengurutkan panggilan ke setiap driver.

Beberapa permintaan dapat dimulai secara paralel pada @1.3::IPreparedModel yang sama. Pengemudi dapat menjalankan permintaan secara paralel atau membuat serial eksekusi.

Kerangka kerja ini dapat meminta pengemudi untuk menyimpan lebih dari satu model yang telah disiapkan. Misalnya, siapkan model m1 , siapkan m2 , jalankan permintaan r1 di m1 , jalankan r2 di m2 , jalankan r3 di m1 , jalankan r4 di m2 , lepaskan (dijelaskan di Pembersihan ) m1 , dan lepaskan m2 .

Untuk menghindari eksekusi pertama yang lambat yang dapat mengakibatkan pengalaman pengguna yang buruk (misalnya, frame pertama tersendat), driver harus melakukan sebagian besar inisialisasi pada tahap kompilasi. Inisialisasi pada eksekusi pertama harus dibatasi pada tindakan yang berdampak negatif terhadap kesehatan sistem jika dilakukan lebih awal, seperti memesan buffer sementara yang besar atau meningkatkan kecepatan jam perangkat. Driver yang hanya dapat menyiapkan sejumlah model bersamaan mungkin harus melakukan inisialisasi pada eksekusi pertama.

Di Android 10 atau lebih tinggi, jika beberapa eksekusi dengan model yang disiapkan sama dieksekusi secara berurutan, klien dapat memilih untuk menggunakan objek burst eksekusi untuk berkomunikasi antara proses aplikasi dan driver. Untuk informasi lebih lanjut, lihat Eksekusi Burst dan Antrean Pesan Cepat .

Untuk meningkatkan kinerja beberapa eksekusi secara berurutan, driver dapat mempertahankan buffer sementara atau meningkatkan kecepatan jam. Disarankan untuk membuat thread pengawas untuk melepaskan sumber daya jika tidak ada permintaan baru yang dibuat setelah jangka waktu tertentu.

Bentuk keluaran

Untuk permintaan di mana satu atau lebih operan keluaran tidak memiliki semua dimensi yang ditentukan, driver harus menyediakan daftar bentuk keluaran yang berisi informasi dimensi untuk setiap operan keluaran setelah eksekusi. Untuk informasi selengkapnya tentang dimensi, lihat OutputShape .

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

Waktu

Di Android 10, aplikasi bisa menanyakan waktu eksekusi jika aplikasi telah menentukan satu perangkat untuk digunakan selama proses kompilasi. Untuk detailnya, lihat MeasureTiming serta Penemuan dan Penugasan Perangkat . Dalam hal ini, driver NN HAL 1.2 harus mengukur durasi eksekusi atau melaporkan UINT64_MAX (untuk menunjukkan bahwa durasi tidak tersedia) saat menjalankan permintaan. Pengemudi harus meminimalkan penalti kinerja apa pun yang diakibatkan oleh pengukuran durasi eksekusi.

Pengemudi melaporkan durasi berikut dalam mikrodetik di struktur Timing :

  • Waktu eksekusi pada perangkat: Tidak termasuk waktu eksekusi pada driver, yang berjalan pada prosesor host.
  • Waktu eksekusi di driver: Termasuk waktu eksekusi di perangkat.

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

Ketika pengemudi belum diminta mengukur durasi eksekusi, atau ketika terjadi kesalahan eksekusi, pengemudi harus melaporkan durasi sebagai UINT64_MAX . Bahkan ketika driver diminta mengukur durasi eksekusi, driver dapat melaporkan UINT64_MAX untuk waktu di perangkat, waktu di driver, atau keduanya. Ketika driver melaporkan kedua durasi sebagai nilai selain UINT64_MAX , waktu eksekusi di driver harus sama atau melebihi waktu di perangkat.

Eksekusi berpagar

Di Android 11, NNAPI mengizinkan eksekusi menunggu daftar pengendali sync_fence dan secara opsional mengembalikan objek sync_fence , yang diberi sinyal saat eksekusi selesai. Hal ini mengurangi overhead untuk model urutan kecil dan kasus penggunaan streaming. Eksekusi berpagar juga memungkinkan interoperabilitas yang lebih efisien dengan komponen lain yang dapat memberi sinyal atau menunggu sync_fence . Untuk informasi selengkapnya tentang sync_fence , lihat Kerangka sinkronisasi .

Dalam eksekusi berpagar, kerangka kerja memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron berpagar pada model yang telah disiapkan dengan vektor pagar sinkronisasi yang harus ditunggu. Jika tugas asinkron selesai sebelum panggilan kembali, pegangan kosong dapat dikembalikan untuk sync_fence . Objek IFencedExecutionCallback juga harus dikembalikan agar kerangka kerja dapat menanyakan status kesalahan dan informasi durasi.

Setelah eksekusi selesai, dua nilai waktu berikut yang mengukur durasi eksekusi dapat ditanyakan melalui IFencedExecutionCallback::getExecutionInfo .

  • timingLaunched : Durasi dari saat executeFenced dipanggil hingga saat executeFenced sinyal syncFence yang dikembalikan.
  • timingFenced : Durasi dari saat semua pagar sinkronisasi yang menunggu eksekusi diberi sinyal hingga saat executeFenced sinyal syncFence yang dikembalikan.

Aliran kontrol

Untuk perangkat yang menjalankan Android 11 atau lebih tinggi, NNAPI menyertakan dua operasi aliran kontrol, IF dan WHILE , yang menggunakan model lain sebagai argumen dan mengeksekusinya secara kondisional ( IF ) atau berulang kali ( WHILE ). Untuk informasi selengkapnya tentang cara menerapkan ini, lihat Aliran kontrol .

Kualitas pelayanan

Di Android 11, NNAPI mencakup peningkatan kualitas layanan (QoS) dengan memungkinkan aplikasi menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diharapkan untuk menyiapkan model, dan jumlah waktu maksimum yang diharapkan untuk suatu eksekusi. untuk diselesaikan. Untuk informasi lebih lanjut, lihat Kualitas Layanan .

Membersihkan

Ketika aplikasi selesai menggunakan model yang telah disiapkan, kerangka kerja melepaskan referensinya ke objek @1.3::IPreparedModel . Ketika objek IPreparedModel tidak lagi direferensikan, objek tersebut secara otomatis dimusnahkan di layanan driver yang membuatnya. Sumber daya khusus model dapat diperoleh kembali saat ini dalam implementasi driver destruktor. Jika layanan driver ingin objek IPreparedModel dimusnahkan secara otomatis ketika tidak diperlukan lagi oleh klien, layanan driver tidak boleh menyimpan referensi apa pun ke objek IPreparedModel setelah objek IPreparedeModel dikembalikan melalui IPreparedModelCallback::notify_1_3 .

penggunaan CPU

Pengemudi diharapkan menggunakan CPU untuk mengatur komputasi. Pengemudi tidak boleh menggunakan CPU untuk melakukan perhitungan grafik karena hal itu mengganggu kemampuan kerangka kerja untuk mengalokasikan pekerjaan dengan benar. Pengemudi harus melaporkan bagian-bagian yang tidak dapat ditanganinya kepada kerangka kerja dan membiarkan kerangka kerja menangani sisanya.

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

Operasi yang diperkenalkan di Android 10 (API level 29) hanya memiliki implementasi CPU referensi untuk memverifikasi bahwa pengujian CTS dan VTS sudah benar. Implementasi yang dioptimalkan yang disertakan dalam kerangka pembelajaran mesin seluler lebih disukai daripada implementasi CPU NNAPI.

Fungsi utilitas

Basis kode NNAPI mencakup fungsi utilitas yang dapat digunakan oleh layanan driver.

File frameworks/ml/nn/common/include/Utils.h berisi berbagai macam fungsi utilitas, seperti yang digunakan untuk logging dan untuk mengkonversi antara versi NN HAL yang berbeda.

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

    • String kosong, menunjukkan bahwa tidak ada pencatatan yang dilakukan.
    • Token 1 atau all , menunjukkan bahwa semua pencatatan harus dilakukan.
    • Daftar tag, dibatasi oleh spasi, koma, atau titik dua, yang menunjukkan pencatatan mana yang harus dilakukan. Tagnya adalah compilation , cpuexe , driver , execution , manager , dan model .

  • compliantWithV1_* : Mengembalikan true jika objek NN HAL dapat dikonversi ke tipe yang sama dari versi HAL yang berbeda tanpa kehilangan informasi. Misalnya, memanggil compliantWithV1_0 pada V1_2::Model akan menghasilkan false jika model menyertakan tipe operasi yang diperkenalkan di NN HAL 1.1 atau NN HAL 1.2.

  • convertToV1_* : Mengonversi objek NN HAL dari satu versi ke versi lainnya. Peringatan dicatat jika konversi mengakibatkan hilangnya informasi (yaitu, jika versi baru dari jenis tersebut tidak dapat sepenuhnya mewakili nilainya).

  • Kemampuan: Fungsi nonExtensionOperandPerformance dan update dapat digunakan untuk membantu membangun bidang Capabilities::operandPerformance .

  • Mengkueri properti tipe: isExtensionOperandType , isExtensionOperationType , nonExtensionSizeOfData , nonExtensionOperandSizeOfData , nonExtensionOperandTypeIsScalar , tensorHasUnspecifiedDimensions .

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

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

File frameworks/ml/nn/common/include/Tracing.h berisi makro untuk menyederhanakan penambahan informasi systracing ke kode Neural Networks. Misalnya, lihat pemanggilan makro NNTRACE_* di driver sampel .

File frameworks/ml/nn/common/include/GraphDump.h berisi fungsi utilitas untuk membuang konten Model dalam bentuk grafis untuk tujuan debugging.

  • graphDump : Menulis representasi model dalam format Graphviz ( .dot ) ke aliran tertentu (jika tersedia) atau ke logcat (jika tidak ada aliran yang disediakan).

Validasi

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

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

  • Titik-mengambang: abs(diharapkan - aktual) <= atol + rtol * abs(diharapkan); Di mana:

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

  • Terkuantisasi: off-by-one (kecuali mobilenet_quantized , yang off-by-three)

  • Boolean: sama persis

Salah satu cara CTS menguji NNAPI adalah dengan membuat grafik pseudorandom tetap yang digunakan untuk menguji dan membandingkan hasil eksekusi dari setiap driver dengan implementasi referensi NNAPI. Untuk driver dengan NN HAL 1.2 atau lebih tinggi, jika hasilnya tidak memenuhi kriteria presisi, CTS melaporkan kesalahan dan membuang file spesifikasi untuk model yang gagal di bawah /data/local/tmp untuk debugging. Untuk detail selengkapnya tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h .

Pengujian bulu halus

Tujuan pengujian fuzz adalah untuk menemukan kerusakan, pernyataan, pelanggaran memori, atau perilaku umum yang tidak terdefinisi dalam kode yang diuji karena faktor-faktor seperti masukan yang tidak terduga. Untuk pengujian fuzz NNAPI, Android menggunakan pengujian berdasarkan libFuzzer , yang efisien dalam fuzzing karena menggunakan cakupan garis dari kasus pengujian sebelumnya untuk menghasilkan masukan acak baru. Misalnya, libFuzzer lebih menyukai kasus pengujian yang dijalankan pada baris kode baru. Hal ini sangat mengurangi jumlah waktu yang diperlukan 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 di utilitas pengujian libneuralnetworks_driver_fuzzer yang terdapat di AOSP untuk menyertakan kode driver 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 driver, driver harus memvalidasi argumen panggilan yang mereka terima. Validasi ini diverifikasi oleh VTS. Kode validasi ada di frameworks/ml/nn/common/include/ValidateHal.h .

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

Rangkaian Uji Pembelajaran Mesin Android

Android Machine Learning Test Suite (MLTS) adalah tolok ukur NNAPI yang disertakan dalam CTS dan VTS untuk memvalidasi keakuratan model nyata pada perangkat vendor. Benchmark mengevaluasi latensi dan akurasi, dan membandingkan hasil driver dengan hasil menggunakan TF Lite yang berjalan pada CPU, untuk model dan kumpulan data yang sama. Hal ini memastikan keakuratan driver tidak lebih buruk daripada implementasi referensi CPU.

Pengembang platform Android juga menggunakan MLTS untuk mengevaluasi latensi dan keakuratan driver.

Tolok ukur NNAPI dapat ditemukan di dua proyek di AOSP:

Model dan kumpulan data

Tolok ukur NNAPI menggunakan model dan himpunan data berikut.

  • MobileNetV1 float dan u8 dikuantisasi dalam ukuran berbeda, dijalankan pada subset kecil (1500 gambar) dari Open Images Dataset v4.
  • MobileNetV2 float dan u8 dikuantisasi dalam ukuran berbeda, dijalankan pada subset kecil (1500 gambar) dari Open Images Dataset v4.
  • Model akustik berbasis memori jangka pendek panjang (LSTM) untuk text-to-speech, dijalankan dengan subset kecil dari kumpulan CMU Arktik.
  • Model akustik berbasis LSTM untuk pengenalan ucapan otomatis, dijalankan pada sebagian kecil kumpulan data LibriSpeech.

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

Tes stres

Android Machine Learning Test Suite mencakup serangkaian uji kerusakan untuk memvalidasi ketahanan pengemudi dalam kondisi penggunaan berat atau dalam kasus perilaku klien.

Semua uji tabrakan menyediakan fitur berikut:

  • Deteksi hang: Jika klien NNAPI hang selama pengujian, pengujian gagal dengan alasan kegagalan HANG dan rangkaian pengujian berpindah ke pengujian berikutnya.
  • Deteksi kerusakan klien NNAPI: Pengujian bertahan dari kerusakan klien dan pengujian gagal dengan alasan kegagalan CRASH .
  • Deteksi kerusakan driver: Pengujian dapat mendeteksi kerusakan driver yang menyebabkan kegagalan pada panggilan NNAPI. Perhatikan bahwa mungkin ada crash dalam proses driver yang tidak menyebabkan kegagalan NNAPI dan tidak menyebabkan kegagalan pengujian. Untuk menutupi kegagalan semacam ini, disarankan untuk menjalankan perintah tail pada log sistem untuk kesalahan atau kerusakan terkait driver.
  • Menargetkan semua akselerator yang tersedia: Pengujian dijalankan terhadap semua driver yang tersedia.

Semua uji tabrak memiliki empat kemungkinan hasil berikut:

  • SUCCESS : Eksekusi selesai tanpa kesalahan.
  • FAILURE : Eksekusi gagal. Biasanya disebabkan oleh kegagalan saat menguji suatu model, yang menunjukkan bahwa driver gagal mengkompilasi atau mengeksekusi model.
  • HANG : Proses pengujian menjadi tidak responsif.
  • CRASH : Proses pengujian terhenti.

Untuk informasi selengkapnya tentang pengujian stres dan daftar lengkap pengujian kerusakan, lihat platform/test/mlts/benchmark/README.txt .

Gunakan MLTS

Untuk menggunakan MLTS:

  1. Hubungkan perangkat target ke stasiun kerja Anda dan pastikan perangkat tersebut dapat dijangkau melalui adb . Ekspor variabel lingkungan ANDROID_SERIAL perangkat target jika lebih dari satu perangkat terhubung.

  2. cd ke direktori sumber tingkat atas 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 benchmark, hasilnya disajikan sebagai halaman HTML dan diteruskan ke xdg-open .

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

Versi HAL Jaringan Neural

Bagian ini menjelaskan perubahan yang diperkenalkan pada versi HAL Android dan Neural Networks.

Android 11

Android 11 memperkenalkan NN HAL 1.3, yang mencakup perubahan penting berikut.

  • Dukungan untuk kuantisasi 8-bit yang ditandatangani di NNAPI. Menambahkan tipe operan TENSOR_QUANT8_ASYMM_SIGNED . Driver dengan NN HAL 1.3 yang mendukung operasi dengan kuantisasi tak bertanda tangan juga harus mendukung varian operasi tersebut yang ditandatangani. Saat menjalankan versi sebagian besar operasi terkuantisasi yang ditandatangani dan tidak ditandatangani, driver harus menghasilkan hasil yang sama hingga offset 128. Ada lima pengecualian untuk persyaratan ini: CAST , HASHTABLE_LOOKUP , LSH_PROJECTION , PAD_V2 , dan QUANTIZED_16BIT_LSTM . Operasi QUANTIZED_16BIT_LSTM tidak mendukung operan yang ditandatangani dan empat operasi lainnya mendukung kuantisasi yang ditandatangani tetapi tidak memerlukan hasil yang sama.
  • Dukungan untuk eksekusi berpagar di mana kerangka kerja memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron berpagar pada model yang telah disiapkan dengan vektor pagar sinkronisasi yang harus ditunggu. Untuk informasi lebih lanjut, lihat Eksekusi berpagar .
  • Dukungan untuk aliran kontrol. Menambahkan operasi IF dan WHILE , yang mengambil model lain sebagai argumen dan mengeksekusinya secara kondisional ( IF ) atau berulang kali ( WHILE ). Untuk informasi lebih lanjut, lihat Aliran kontrol .
  • Peningkatan kualitas layanan (QoS) karena aplikasi dapat menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diharapkan untuk menyiapkan model, dan jumlah waktu maksimum yang diharapkan untuk menyelesaikan eksekusi. Untuk informasi lebih lanjut, lihat Kualitas Layanan .
  • Dukungan untuk domain memori yang menyediakan antarmuka pengalokasi untuk buffer yang dikelola driver. Hal ini memungkinkan untuk meneruskan memori asli perangkat di seluruh eksekusi, menekan penyalinan dan transformasi data yang tidak perlu antara eksekusi berturut-turut pada driver yang sama. Untuk informasi selengkapnya, lihat Domain memori .

Android 10

Android 10 memperkenalkan NN HAL 1.2, yang mencakup perubahan penting berikut.

  • Struktur Capabilities mencakup semua tipe data termasuk tipe data skalar, dan mewakili kinerja non-relaks menggunakan vektor, bukan bidang bernama.
  • Metode getVersionString dan getType memungkinkan kerangka kerja mengambil jenis perangkat ( DeviceType ) dan informasi versi. Lihat Penemuan dan Penetapan Perangkat .
  • Metode executeSynchronously dipanggil secara default untuk melakukan eksekusi secara sinkron. Metode execute_1_2 memberitahu kerangka kerja untuk melakukan eksekusi secara asinkron. Lihat Eksekusi .
  • Parameter MeasureTiming untuk executeSynchronously , execute_1_2 , dan eksekusi burst menentukan apakah driver akan mengukur durasi eksekusi. Hasilnya dilaporkan dalam struktur Timing . Lihat Waktu .
  • Dukungan untuk eksekusi di mana satu atau lebih operan keluaran memiliki dimensi atau peringkat yang tidak diketahui. Lihat Bentuk keluaran .
  • Dukungan untuk ekstensi vendor, yang merupakan kumpulan operasi dan tipe data yang ditentukan vendor. Pengemudi melaporkan ekstensi yang didukung melalui metode IDevice::getSupportedExtensions . Lihat Ekstensi Vendor .
  • Kemampuan objek burst untuk mengontrol serangkaian eksekusi burst menggunakan antrian pesan cepat (FMQ) untuk berkomunikasi antara proses aplikasi dan driver, sehingga mengurangi latensi. Lihat Eksekusi Burst dan Antrian Pesan Cepat .
  • Dukungan untuk AHardwareBuffer untuk memungkinkan driver melakukan eksekusi tanpa menyalin data. Lihat AHardwareBuffer .
  • Peningkatan dukungan untuk cache artefak kompilasi guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai. Lihat Caching Kompilasi .

Android 10 memperkenalkan jenis dan operasi operan berikut.

  • Jenis operan

    • 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 pembaruan pada banyak operasi yang ada. Pembaruan tersebut terutama terkait dengan hal-hal berikut:

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

Daftar di bawah menunjukkan operasi yang dimodifikasi di Android 10. Untuk detail selengkapnya tentang perubahan tersebut, 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 di Android 9 dan menyertakan perubahan penting berikut.

  • IDevice::prepareModel_1_1 menyertakan parameter ExecutionPreference . Pengemudi dapat menggunakan ini untuk menyesuaikan persiapannya, mengetahui bahwa aplikasi lebih memilih untuk menghemat baterai atau akan menjalankan model dalam panggilan cepat yang berurutan.
  • Sembilan operasi baru telah ditambahkan: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
  • Aplikasi dapat menentukan bahwa komputasi float 32-bit dapat dijalankan menggunakan rentang float 16-bit dan/atau presisi dengan menyetel Model.relaxComputationFloat32toFloat16 ke true . Struktur Capabilities memiliki bidang tambahan relaxedFloat32toFloat16Performance sehingga pengemudi dapat melaporkan kinerja santainya ke kerangka kerja.

Android 8.1

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