Driver Neural Networks API

Halaman ini menyediakan ringkasan cara mengimplementasikan driver Neural Networks API (NNAPI). Untuk detail selengkapnya, lihat dokumentasi yang ada dalam file definisi HAL di hardware/interfaces/neuralnetworks. Contoh implementasi driver 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 menentukan 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 framework dan driver digambarkan pada gambar 1.

Alur Jaringan Neural

Gambar 1. Alur Jaringan Neural

Inisialisasi

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

Untuk menentukan cara mengalokasikan komputasi ke perangkat yang tersedia, framework menggunakan kemampuan untuk memahami seberapa cepat dan seberapa hemat energi setiap driver dapat melakukan eksekusi. Untuk memberikan informasi ini, driver harus memberikan angka performa standar berdasarkan eksekusi workload referensi.

Untuk menentukan nilai yang ditampilkan oleh driver sebagai respons terhadap IDevice::getCapabilities_1_3, gunakan aplikasi tolok ukur NNAPI guna mengukur performa untuk jenis data yang sesuai. Model MobileNet v1 dan v2, asr_float, serta tts_float direkomendasikan untuk mengukur performa nilai floating point 32 bit 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 informasi performa driver hanya untuk floating point dan tensor terkuantisasi, serta tidak menyertakan jenis data skalar.

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

Di antara mulai ulang 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 dapat mengalami penurunan performa atau perilaku yang salah.

Kompilasi

Framework menentukan perangkat yang akan digunakan saat menerima permintaan dari aplikasi. Di Android 10, aplikasi dapat menemukan dan menentukan perangkat yang dipilih framework. Untuk mengetahui informasi selengkapnya, lihat Penemuan dan Penetapan Perangkat.

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

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

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

Framework ini menginstruksikan setiap driver yang dipilih untuk bersiap mengeksekusi subset model dengan memanggil IDevice::prepareModel_1_3. Setiap driver kemudian mengompilasi subset-nya. Misalnya, driver dapat membuat kode atau membuat salinan bobot yang diurutkan ulang. Karena ada banyak waktu antara kompilasi model dan eksekusi permintaan, resource seperti memori perangkat yang besar tidak boleh ditetapkan selama kompilasi.

Jika berhasil, driver akan menampilkan handle @1.3::IPreparedModel. Jika driver menampilkan kode kegagalan saat menyiapkan subset model, framework akan menjalankan seluruh model pada CPU.

Guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat meng-cache artefak kompilasi. Untuk informasi selengkapnya, lihat Pembuatan Cache 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 sudah 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 performa dan mengurangi overhead threading dibandingkan panggilan asinkron karena kontrol ditampilkan ke proses aplikasi hanya setelah eksekusi selesai. Ini berarti driver tidak memerlukan mekanisme terpisah untuk memberi tahu proses aplikasi bahwa eksekusi selesai.

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

Parameter Request yang diteruskan ke metode eksekusi mencantumkan operand input dan output yang digunakan untuk eksekusi. Memori yang menyimpan data operand harus menggunakan urutan baris utama dengan dimensi pertama yang melakukan iterasi paling lambat dan tidak memiliki padding di akhir baris. Untuk mengetahui 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 akan ditampilkan ke framework. Selama eksekusi, output atau operand internal model dapat memiliki satu atau beberapa dimensi yang tidak diketahui atau peringkat yang tidak diketahui. Jika setidaknya satu operasi output memiliki dimensi atau peringkat yang tidak diketahui, driver harus menampilkan informasi output berukuran dinamis.

Untuk driver dengan NN HAL 1.1 atau yang lebih rendah, hanya status error yang ditampilkan saat permintaan selesai. Dimensi untuk operand 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, framework bertanggung jawab untuk mencadangkan memori perantara dan untuk mengurutkan panggilan ke setiap driver.

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

Framework ini dapat meminta pengemudi untuk menyimpan lebih dari satu model yang disiapkan. Misalnya, menyiapkan model m1, menyiapkan m2, mengeksekusi permintaan r1 pada m1, mengeksekusi r2 pada m2, mengeksekusi r3 pada m1, mengeksekusi r4 pada m2, merilis (dijelaskan dalam Pembersihan) m1, dan merilis m2.

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

Di Android 10 atau yang lebih tinggi, jika beberapa eksekusi dengan model siap yang sama dieksekusi berturut-turut dengan cepat, klien dapat memilih untuk menggunakan objek burst eksekusi untuk berkomunikasi antara proses aplikasi dan driver. Untuk mengetahui informasi selengkapnya, lihat Eksekusi Burst dan Antrean Pesan Cepat.

Guna meningkatkan performa untuk beberapa eksekusi secara berurutan dengan cepat, driver dapat mempertahankan buffer sementara atau meningkatkan kecepatan clock. Pembuatan thread watchdog direkomendasikan untuk melepaskan resource jika tidak ada permintaan baru yang dibuat setelah jangka waktu yang tetap.

Bentuk output

Untuk permintaan yang satu atau beberapa operand output belum menetapkan semua dimensi, driver harus memberikan daftar bentuk output yang berisi informasi dimensi untuk setiap operand output setelah dieksekusi. Untuk mengetahui informasi selengkapnya tentang dimensi, lihat OutputShape.

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

Pengaturan Waktu

Di Android 10, aplikasi dapat meminta waktu eksekusi jika aplikasi telah menentukan satu perangkat untuk digunakan selama proses kompilasi. Untuk mengetahui detailnya, lihat MeasureTiming dan Penemuan dan Penetapan Perangkat. Dalam hal ini, driver NN HAL 1.2 harus mengukur durasi eksekusi atau melaporkan UINT64_MAX (untuk menunjukkan bahwa durasi tersebut tidak tersedia) saat mengeksekusi permintaan. Pengemudi harus meminimalkan penalti performa yang dihasilkan dari pengukuran durasi eksekusi.

Pengemudi melaporkan durasi berikut dalam mikrodetik dalam struktur Timing:

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

Durasi ini harus mencakup waktu saat eksekusi ditangguhkan, misalnya, saat eksekusi telah didahului oleh tugas lain, atau saat menunggu resource tersedia.

Saat driver belum diminta untuk mengukur durasi eksekusi, atau saat terjadi error eksekusi, driver harus melaporkan durasi sebagai UINT64_MAX. Bahkan saat pengemudi diminta untuk mengukur durasi eksekusi, pengemudi dapat melaporkan UINT64_MAX untuk waktu di perangkat, waktu di driver, atau keduanya. Jika driver melaporkan kedua durasi sebagai nilai selain UINT64_MAX, waktu eksekusi pada driver harus sama dengan atau melebihi waktu di perangkat.

Eksekusi berpagar

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

Dalam eksekusi fence, framework 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. Objek IFencedExecutionCallback juga harus ditampilkan untuk memungkinkan framework membuat kueri status error dan informasi durasi.

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

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

Alur kontrol

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

Kualitas layanan

Di Android 11, NNAPI menyertakan peningkatan kualitas layanan (QoS) dengan memungkinkan aplikasi menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diperkirakan untuk penyiapan model, dan jumlah waktu maksimum yang diperkirakan untuk penyelesaian eksekusi. Untuk mengetahui informasi selengkapnya, lihat Kualitas Layanan.

Pembersihan

Saat aplikasi selesai menggunakan model yang disiapkan, framework akan merilis referensinya ke objek @1.3::IPreparedModel. Jika tidak lagi direferensikan, objek IPreparedModel akan otomatis dihancurkan dalam layanan driver yang membuatnya. Resource khusus model dapat diklaim kembali saat ini dalam implementasi destruktor oleh driver. Jika layanan driver ingin objek IPreparedModel dihancurkan secara otomatis saat tidak lagi diperlukan oleh klien, layanan tersebut tidak boleh menyimpan referensi apa pun ke objek IPreparedModel setelah objek IPreparedeModel ditampilkan 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 tersebut akan mengganggu kemampuan framework untuk mengalokasikan pekerjaan dengan benar. Driver harus melaporkan bagian yang tidak dapat ditanganinya ke framework dan membiarkan framework menangani bagian lainnya.

Framework ini menyediakan implementasi CPU untuk semua operasi NNAPI kecuali untuk 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 framework machine learning seluler lebih dipilih daripada implementasi CPU NNAPI.

Fungsi utilitas

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

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

  • VLogging: VLOG adalah makro wrapper di sekitar LOG Android yang hanya mencatat pesan ke dalam log jika tag yang sesuai ditetapkan di properti debug.nn.vlog. initVLogMask() harus dipanggil sebelum panggilan ke VLOG. Makro VLOG_IS_ON dapat digunakan untuk memeriksa apakah VLOG saat ini sudah diaktifkan, sehingga kode logging yang rumit dapat dilewati jika tidak diperlukan. Nilai properti harus berupa salah satu dari yang 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 dengan spasi, koma, atau titik dua, yang menunjukkan logging 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 yang sama dari versi HAL yang berbeda tanpa kehilangan informasi. Misalnya, memanggil compliantWithV1_0 pada V1_2::Model akan menampilkan false jika modelnya menyertakan 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 (yaitu, jika versi baru jenis tidak dapat sepenuhnya merepresentasikan nilai).

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

  • Properti kueri 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*: 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 model berisi operasi yang mereferensikan indeks operand 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 Jaringan Neural. Sebagai contoh, lihat pemanggilan makro NNTRACE_* pada contoh driver.

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

  • graphDump: Menulis representasi model dalam format Graphviz (.dot) ke aliran data yang ditentukan (jika tersedia) atau ke logcat (jika tidak ada aliran data 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 framework), sedangkan CTS melatih driver secara tidak langsung melalui framework. Hal ini akan 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:

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

    • 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 diskonnya tiga kali)

  • 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 driver dengan implementasi referensi NNAPI. Untuk driver dengan NN HAL 1.2 atau yang lebih tinggi, jika hasilnya tidak memenuhi kriteria presisi, CTS akan melaporkan error dan mengeluarkan file spesifikasi untuk model yang gagal di bagian /data/local/tmp untuk proses debug. Untuk detail selengkapnya tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h.

Uji kegagalan (fuzz testing)

Tujuan pengujian fuzz adalah untuk menemukan error, pernyataan, pelanggaran memori, atau perilaku yang tidak ditentukan secara umum dalam kode yang sedang 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 kasus pengujian sebelumnya untuk menghasilkan input acak baru. Misalnya, libFuzzer lebih memilih kasus pengujian yang berjalan pada baris kode baru. Hal ini sangat mengurangi waktu yang dibutuhkan pengujian untuk menemukan kode yang bermasalah.

Untuk melakukan pengujian fuzz guna memvalidasi implementasi driver, modifikasi frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp pada 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 pengemudi, driver harus memvalidasi argumen panggilan yang mereka terima. Validasi ini diverifikasi oleh VTS. Kode validasi ada dalam frameworks/ml/nn/common/include/ValidateHal.h.

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

Android Machine Learning Test Suite

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

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

Tolok ukur NNAPI dapat ditemukan dalam dua project dalam AOSP:

Model dan set data

Tolok ukur NNAPI menggunakan model dan set data berikut.

  • Float MobileNetV1 dan u8 dikuantisasi dalam berbagai ukuran, dijalankan terhadap sebagian kecil (1.500 gambar) dari Set Data Gambar Terbuka v4.
  • Float dan u8 MobileNetV2 dikuantisasi dalam berbagai ukuran, dijalankan terhadap sebagian kecil (1.500 gambar) dari Set Data Gambar Terbuka v4.
  • Model akustik berbasis memori jangka pendek (LSTM) untuk text-to-speech, dijalankan terhadap sebagian kecil set CMU Arctic.
  • Model akustik berbasis LSTM untuk pengenalan ucapan otomatis, dijalankan pada sebagian kecil set data 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 yang berat atau dalam kasus ekstrem perilaku klien.

Semua uji error menyediakan fitur berikut:

  • Deteksi hang: Jika klien NNAPI mengalami hang selama pengujian, pengujian gagal dengan alasan kegagalan HANG dan paket pengujian akan berpindah ke pengujian berikutnya.
  • Deteksi error klien NNAPI: Pengujian bertahan saat terjadi error klien dan pengujian gagal dengan alasan kegagalan CRASH.
  • Deteksi tabrakan pengemudi: Pengujian dapat mendeteksi error driver yang menyebabkan kegagalan pada panggilan NNAPI. Perhatikan bahwa mungkin terjadi error dalam proses driver yang tidak menyebabkan kegagalan NNAPI dan tidak menyebabkan pengujian gagal. Untuk mengatasi jenis kegagalan ini, sebaiknya jalankan perintah tail di log sistem untuk menemukan error atau error terkait driver.
  • Penargetan semua akselerator yang tersedia: Pengujian dijalankan terhadap semua driver yang tersedia.

Semua uji error memiliki empat kemungkinan hasil berikut:

  • SUCCESS: Eksekusi selesai tanpa error.
  • FAILURE: Eksekusi gagal. Biasanya disebabkan oleh kegagalan saat menguji model, yang menunjukkan bahwa driver 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 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 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 akan ditampilkan 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 dalam versi HAL Jaringan Neural dan Android.

Android 11

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

  • Dukungan untuk kuantisasi 8-bit yang ditandatangani dalam NNAPI. Menambahkan jenis operasi TENSOR_QUANT8_ASYMM_SIGNED. Driver dengan NN HAL 1.3 yang mendukung operasi dengan kuantisasi yang tidak ditandatangani juga harus mendukung varian bertanda dari operasi tersebut. Saat menjalankan versi bertanda tangan dan tidak ditandatangani 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 operand bertanda tangan, dan empat operasi lainnya mendukung kuantisasi bertanda tangan, tetapi tidak mengharuskan hasilnya sama.
  • Dukungan untuk eksekusi dengan fence saat framework memanggil metode IPreparedModel::executeFenced untuk meluncurkan eksekusi asinkron dengan fence pada model yang telah disiapkan dengan vektor fence sinkronisasi yang akan ditunggu. Untuk mengetahui 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 mengetahui informasi selengkapnya, lihat Alur kontrol.
  • Peningkatan kualitas layanan (QoS) karena aplikasi dapat menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diharapkan untuk penyiapan model, dan jumlah waktu maksimum yang diharapkan untuk penyelesaian eksekusi. Untuk mengetahui informasi selengkapnya, lihat Kualitas Layanan.
  • Dukungan untuk domain memori yang menyediakan antarmuka alokator untuk buffer yang dikelola driver. Hal ini memungkinkan penerusan memori native perangkat di seluruh eksekusi, sehingga menekan penyalinan dan transformasi data yang tidak perlu di antara eksekusi berurutan pada driver yang sama. Untuk mengetahui informasi selengkapnya, lihat Domain memori.

Android 10

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

  • Struct Capabilities mencakup semua jenis data, termasuk jenis data skalar, dan merepresentasikan performa yang tidak santai menggunakan vektor, bukan kolom bernama.
  • Metode getVersionString dan getType memungkinkan framework untuk 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 memberi tahu framework 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 jika satu atau beberapa operand output memiliki dimensi atau peringkat yang tidak diketahui. Lihat Bentuk output.
  • Dukungan untuk ekstensi vendor, yang merupakan kumpulan jenis data dan operasi yang ditentukan vendor. Driver 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 proses aplikasi dan driver, sehingga mengurangi latensi. Lihat Eksekusi Burst dan Antrean Pesan Cepat.
  • Dukungan untuk AHardwareBuffer agar driver dapat melakukan eksekusi tanpa menyalin data. Lihat AHardwareBuffer.
  • Meningkatkan dukungan untuk caching artefak kompilasi guna mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai. Lihat Pembuatan Cache 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 update untuk banyak operasi yang sudah ada. Update ini terutama terkait dengan hal berikut:

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

Daftar di bawah ini menunjukkan operasi yang diubah di Android 10. Untuk detail selengkapnya tentang perubahan ini, 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. Driver dapat menggunakan ini untuk menyesuaikan persiapannya, karena mengetahui bahwa aplikasi lebih memilih untuk menghemat baterai atau akan mengeksekusi model dalam panggilan berturut-turut yang cepat.
  • 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 menetapkan Model.relaxComputationFloat32toFloat16 ke true. Struktur Capabilities memiliki kolom tambahan relaxedFloat32toFloat16Performance sehingga driver dapat melaporkan performanya yang tidak stabil ke framework.

Android 8.1

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