Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Driver API Jaringan Neural

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

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

Jaringan Neural HAL

Neural Networks (NN) HAL mendefinisikan abstraksi dari berbagai perangkat , seperti unit pemrosesan grafis (GPU) dan prosesor sinyal digital (DSP), yang ada dalam 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 framework dan driver digambarkan dalam gambar 1.

Aliran Jaringan Neural

Gambar 1. Aliran Jaringan Neural

Inisialisasi

Saat inisialisasi, kerangka kerja menanyakan driver untuk kemampuannya menggunakan IDevice::getCapabilities_1_3 . Struktur @1.3::Capabilities mencakup semua tipe data dan merepresentasikan kinerja nonrelaxed menggunakan vektor.

Untuk menentukan cara mengalokasikan komputasi ke perangkat yang tersedia, framework menggunakan kapabilitas 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 kinerja tipe data yang sesuai. Model MobileNet v1 dan v2, asr_float , dan tts_float direkomendasikan untuk mengukur kinerja untuk nilai floating point 32-bit dan model terkuantisasi MobileNet v1 dan v2 direkomendasikan untuk nilai terkuantisasi 8-bit. Untuk informasi selengkapnya, lihat Rangkaian Pengujian Machine Learning Android .

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

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

Di antara produk reboot, 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 menentukan perangkat mana yang akan digunakan ketika menerima permintaan dari aplikasi. Di Android 10, aplikasi bisa menemukan dan menentukan perangkat yang dipilih framework. Untuk informasi lebih lanjut, lihat Penemuan dan Penugasan Perangkat .

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

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

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

Kerangka kerja menginstruksikan setiap driver yang dipilih untuk bersiap mengeksekusi subset model dengan memanggil IDevice::prepareModel_1_3 . Setiap driver kemudian mengkompilasi subsetnya. Misalnya, pengemudi dapat membuat kode atau membuat salinan urutan bobot. Karena mungkin terdapat banyak waktu antara kompilasi model dan eksekusi permintaan, resource seperti potongan 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, framework akan menjalankan seluruh model di CPU.

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

Eksekusi

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

Panggilan eksekusi sinkron meningkatkan performa 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 saat eksekusi selesai, menggunakan @1.3::IExecutionCallback .

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

Untuk driver NN HAL 1.2 atau yang lebih tinggi, saat permintaan selesai, status kesalahan, bentuk keluaran , dan informasi pengaturan waktu dikembalikan ke kerangka kerja. Selama eksekusi, keluaran atau operan internal model dapat memiliki satu atau beberapa 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 yang berukuran dinamis.

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

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

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

Kerangka kerja dapat meminta pengemudi untuk menyimpan lebih dari satu model yang disiapkan. Misalnya, siapkan model m1 , siapkan m2 , jalankan permintaan r1 pada m1 , jalankan r2 pada m2 , jalankan r3 pada m1 , jalankan r4 pada m2 , lepaskan (dijelaskan dalam 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 dalam fase kompilasi. Inisialisasi pada eksekusi pertama harus dibatasi pada tindakan yang berdampak negatif pada kesehatan sistem ketika dilakukan lebih awal, seperti menyimpan buffer sementara yang besar atau meningkatkan clock rate perangkat. Driver yang hanya dapat menyiapkan model konkuren dalam jumlah terbatas mungkin harus melakukan inisialisasi pada eksekusi pertama.

Di Android 10 atau lebih tinggi, jika beberapa eksekusi dengan model yang dipersiapkan yang sama dijalankan 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 Antrian Pesan Cepat .

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

Bentuk keluaran

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

Jika eksekusi gagal karena buffer keluaran berukuran kecil, driver harus menunjukkan operand 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.

Pengaturan waktu

Di Android 10, aplikasi bisa meminta waktu eksekusi jika aplikasi telah menentukan satu perangkat untuk digunakan selama proses kompilasi. Untuk detailnya, lihat MeasureTiming dan Device Discovery and Assignment . Dalam kasus ini, pengandar 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 yang dihasilkan dari pengukuran durasi eksekusi.

Pengemudi melaporkan durasi berikut dalam mikrodetik dalam struktur Timing :

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

Durasi ini harus menyertakan waktu saat eksekusi ditangguhkan, misalnya, saat eksekusi telah didahului oleh tugas lain atau saat menunggu sumber daya tersedia.

Jika pengemudi belum diminta untuk mengukur durasi eksekusi, atau saat ada kesalahan eksekusi, pengemudi harus melaporkan durasi sebagai UINT64_MAX . Bahkan saat pengemudi diminta untuk mengukur durasi eksekusi, ia malah 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 pada driver harus sama atau melebihi waktu pada perangkat.

Eksekusi berpagar

Di Android 11, NNAPI memungkinkan eksekusi menunggu daftar pegangan sync_fence dan secara opsional mengembalikan objek sync_fence , yang diberi tanda saat eksekusi selesai. 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 lebih lanjut tentang sync_fence , lihat Synchronization Framework .

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

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

  • timingLaunched : Durasi dari ketika executeFenced dipanggil untuk saat executeFenced sinyal kembali syncFence .
  • timingFenced : Durasi dari ketika semua pagar sync bahwa menunggu eksekusi untuk yang mengisyaratkan ketika executeFenced sinyal kembali syncFence .

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 menjalankannya secara bersyarat ( IF ) atau berulang kali ( WHILE ). Untuk informasi lebih lanjut tentang cara mengimplementasikan ini, lihat Alur kontrol .

Kualitas pelayanan

Di Android 11, NNAPI menyertakan 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 eksekusi untuk diselesaikan. Untuk informasi lebih lanjut, lihat Quality of Service .

Membersihkan

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

penggunaan CPU

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

Framework ini menyediakan implementasi CPU untuk semua operasi NNAPI kecuali untuk operasi yang ditentukan vendor. Untuk informasi lebih lanjut, 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. Penerapan yang dioptimalkan yang termasuk dalam kerangka kerja pembelajaran mesin seluler lebih disukai daripada penerapan 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 mengonversi 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 salah satu dari berikut ini:

    • String kosong, menunjukkan bahwa tidak ada logging yang harus dilakukan.
    • Token 1 atau all , menunjukkan bahwa semua logging harus dilakukan.
    • Daftar tag, dibatasi oleh spasi, koma, atau titik dua, yang menunjukkan logging mana yang harus dilakukan. Tag tersebut adalah compilation , cpuexe , driver , execution , manager , dan model .
  • compliantWithV1_* : Mengembalikan nilai 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 mengembalikan false jika model menyertakan jenis operasi yang diperkenalkan di NN HAL 1.1 atau NN HAL 1.2.

  • convertToV1_* : Mengonversi objek NN HAL dari satu versi ke versi lain. Peringatan dicatat jika hasil konversi kehilangan informasi (yaitu, jika versi baru dari jenis tidak dapat sepenuhnya mewakili nilai).

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

  • isExtensionOperandType isExtensionOperationType properti jenis: 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 nilai true jika objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya. Jenis OEM dan jenis ekstensi tidak divalidasi. Misalnya, validateModel mengembalikan nilai 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. Sebagai contoh, 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 keperluan debugging.

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

Validasi

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

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

  • Floating-point: abs (diharapkan - aktual) <= atol + rtol * abs (diharapkan); dimana:

    • Untuk fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • Untuk fp16, atol = rtol = 5.0f * 0.0009765625f
  • Quantized: off-by-one (kecuali untuk mobilenet_quantized , yang off-by-three)

  • Boolean: sama persis

Salah satu cara CTS menguji NNAPI adalah dengan menghasilkan 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 hasil tidak memenuhi kriteria presisi, CTS melaporkan kesalahan dan membuang file spesifikasi untuk model yang gagal di bawah /data/local/tmp untuk debugging. Untuk rincian lebih lanjut tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h .

Pengujian fuzz

Tujuan pengujian fuzz adalah untuk menemukan error, pernyataan, pelanggaran memori, atau perilaku umum yang tidak ditentukan dalam kode yang diuji karena faktor-faktor seperti input 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 menyukai kasus pengujian yang dijalankan pada baris kode baru. Ini sangat mengurangi jumlah waktu yang dibutuhkan pengujian untuk menemukan kode yang bermasalah.

Untuk melakukan pengujian fuzz untuk 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 dalam frameworks/ml/nn/common/include/ValidateHal.h .

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

Rangkaian Pengujian 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. Tolok ukur mengevaluasi latensi dan akurasi, dan membandingkan hasil driver dengan hasil menggunakan TF Lite yang berjalan pada CPU, untuk model dan kumpulan data yang sama. Ini memastikan bahwa akurasi driver tidak lebih buruk daripada implementasi referensi CPU.

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

Tolok ukur NNAPI dapat ditemukan di dua proyek di AOSP:

Model dan kumpulan data

Tolok ukur NNAPI menggunakan model dan set data berikut.

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

Untuk informasi lebih lanjut, lihat platform/test/mlts/models .

Tes stres

Rangkaian Pengujian Machine Learning Android menyertakan serangkaian uji error untuk memvalidasi ketahanan driver dalam kondisi penggunaan yang berat atau dalam kasus-kasus tertentu dari perilaku klien.

Semua uji kerusakan menyediakan fitur-fitur berikut:

  • Deteksi hang : Jika klien NNAPI hang selama pengujian, pengujian gagal dengan alasan kegagalan HANG dan rangkaian pengujian berpindah ke pengujian berikutnya.
  • Deteksi error klien NNAPI: Pengujian bertahan dari error 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 error dalam proses driver yang tidak menyebabkan kegagalan NNAPI dan tidak menyebabkan pengujian gagal. Untuk menutupi kegagalan semacam ini, disarankan untuk menjalankan perintah tail pada log sistem untuk kesalahan atau crash terkait driver.
  • Menargetkan semua akselerator yang tersedia: Pengujian dijalankan terhadap semua driver yang tersedia.

Semua uji kerusakan memiliki empat kemungkinan hasil berikut:

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

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

Menggunakan MLTS

Untuk menggunakan MLTS:

  1. Hubungkan perangkat target ke workstation Anda dan pastikan itu dapat dijangkau melalui adb . Ekspor variabel lingkungan ANDROID_SERIAL perangkat target jika lebih dari satu perangkat terhubung.
  2. cd ke direktori sumber level 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 lebih lanjut, lihat platform/test/mlts/benchmark/README.txt .

Versi HAL Neural Networks

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

Android 11

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

  • Dukungan untuk kuantisasi 8-bit yang ditandatangani di NNAPI. Menambahkan jenis operand TENSOR_QUANT8_ASYMM_SIGNED . Driver dengan NN HAL 1.3 yang mendukung operasi dengan penghitungan unsigned juga harus mendukung varian bertanda tangan dari operasi tersebut. Saat menjalankan versi bertanda tangan dan tidak bertanda tangan dari sebagian besar operasi terkuantisasi, driver harus memberikan 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 bertanda tangan dan empat operasi lainnya mendukung kuantisasi bertanda tangan tetapi tidak memerlukan hasil yang sama.
  • Dukungan untuk eksekusi berpagar di mana framework memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron berpagar pada model yang disiapkan dengan vektor pagar sinkronisasi untuk menunggu. Untuk informasi lebih lanjut, lihat Eksekusi berpagar .
  • Dukungan untuk aliran kontrol. Menambahkan operasi IF dan WHILE , yang menggunakan model lain sebagai argumen dan menjalankannya secara bersyarat ( IF ) atau berulang kali ( WHILE ). Untuk informasi lebih lanjut, lihat Alur 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 penyelesaian eksekusi. Untuk informasi lebih lanjut, lihat Quality of Service .
  • 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 yang berurutan pada driver yang sama. Untuk informasi lebih lanjut, lihat Domain memori .

Android 10

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

  • Capabilities struct mencakup semua tipe data termasuk tipe data skalar, dan merepresentasikan kinerja nonrelaxed menggunakan vektor daripada bidang bernama.
  • Metode getVersionString dan getType memungkinkan framework untuk mengambil jenis perangkat ( DeviceType ) dan informasi versi. Lihat Penemuan dan Penugasan Perangkat .
  • Metode executeSynchronously dipanggil secara default untuk melakukan eksekusi secara sinkron. Metode execute_1_2 memberi tahu 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 Pengaturan 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. Driver melaporkan ekstensi yang didukung melalui metode IDevice::getSupportedExtensions . Lihat Ekstensi Vendor .
  • Kemampuan objek burst untuk mengontrol sekumpulan eksekusi burst menggunakan antrian pesan cepat (FMQ) untuk berkomunikasi antara aplikasi dan proses driver, 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 caching artefak kompilasi guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai. Lihat Caching Kompilasi .

Android 10 memperkenalkan jenis dan operasi operand berikut.

  • 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 pembaruan untuk banyak operasi yang sudah ada. Pembaruan terutama terkait dengan berikut ini:

  • 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 ini menunjukkan operasi yang dimodifikasi di Android 10. Untuk detail lengkap dari 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 . Seorang pengemudi dapat menggunakan ini untuk menyesuaikan persiapannya, mengetahui bahwa aplikasi lebih memilih untuk menghemat baterai atau akan menjalankan model dalam panggilan berurutan yang cepat.
  • Sembilan operasi baru telah ditambahkan: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
  • Sebuah aplikasi dapat menentukan bahwa komputasi float 32-bit dapat dijalankan menggunakan rentang dan / atau presisi 16-bit dengan menyetel Model.relaxComputationFloat32toFloat16 ke true . Capabilities struct memiliki bidang tambahan relaxedFloat32toFloat16Performance sehingga pengemudi dapat melaporkan kinerja santai ke framework.

Android 8.1

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