Driver Neural Networks API

Halaman ini memberikan ringkasan tentang cara menerapkan driver Neural Networks API (NNAPI). Untuk detail selengkapnya, lihat dokumentasi yang ditemukan 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 diilustrasikan pada gambar 1.

Alur Jaringan Neural

Gambar 1. Alur Jaringan Neural

Inisialisasi

Saat inisialisasi, framework mengkueri driver untuk mengetahui kemampuannya menggunakan IDevice::getCapabilities_1_3. Struktur @1.3::Capabilities mencakup semua jenis data dan mewakili performa non-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 beban kerja referensi.

Untuk menentukan nilai yang ditampilkan driver sebagai respons terhadap IDevice::getCapabilities_1_3, gunakan aplikasi benchmark NNAPI untuk mengukur performa untuk jenis data yang sesuai. Model MobileNet v1 dan v2, asr_float, dan tts_float direkomendasikan untuk mengukur performa untuk nilai floating point 32-bit dan model kuantisasi MobileNet v1 dan v2 direkomendasikan untuk nilai kuantisasi 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 mengkueri informasi lainnya, 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 menunjukkan 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. Driver dapat menentukan bahwa driver 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 subsetnya. Misalnya, driver dapat membuat kode atau membuat salinan bobot yang diurutkan ulang. Karena mungkin ada waktu yang signifikan antara kompilasi model dan eksekusi permintaan, resource seperti sebagian besar memori perangkat 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.

Untuk mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat menyimpan artefak kompilasi dalam cache. 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 dengan panggilan asinkron karena kontrol dikembalikan 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 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 urutan yang tidak diketahui. Jika setidaknya satu operand output memiliki dimensi atau peringkat yang tidak diketahui, driver harus menampilkan informasi output yang 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 mencakup beberapa driver, framework bertanggung jawab untuk menyimpan memori perantara dan untuk mengurutkan panggilan ke setiap driver.

Beberapa permintaan dapat dimulai secara paralel di @1.3::IPreparedModel yang sama. Pengemudi dapat menjalankan permintaan secara paralel atau melakukan serialisasi eksekusi.

Framework 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 sejumlah model serentak yang terbatas mungkin harus melakukan inisialisasi pada eksekusi pertama.

Di Android 10 atau yang lebih tinggi, jika beberapa eksekusi dengan model yang disiapkan sama dijalankan secara berurutan 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. Membuat thread watchdog direkomendasikan untuk melepaskan resource jika tidak ada permintaan baru yang dibuat setelah jangka waktu tetap.

Bentuk output

Untuk permintaan dengan satu atau beberapa operand output yang tidak memiliki semua dimensi yang ditentukan, 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 yang berukuran terlalu kecil, driver harus menunjukkan operand output mana yang ukuran buffer-nya tidak memadai dalam daftar bentuk output, dan harus melaporkan informasi dimensi sebanyak mungkin, menggunakan nol untuk dimensi yang tidak diketahui.

Waktu

Di Android 10, aplikasi dapat meminta 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 tidak tersedia) saat menjalankan 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: Mencakup waktu eksekusi di 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 di driver harus sama dengan atau melebihi waktu di perangkat.

Eksekusi berpagar

Di Android 11, NNAPI memungkinkan eksekusi menunggu daftar handle 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 memberikan sinyal atau menunggu sync_fence. Untuk mengetahui informasi selengkapnya tentang sync_fence, lihat Framework sinkronisasi.

Dalam eksekusi dengan 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 memberi sinyal 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 mengeksekusinya secara kondisional (IF) atau berulang kali (WHILE). Untuk mengetahui informasi selengkapnya tentang cara menerapkannya, lihat Alur kontrol.

Kualitas layanan

Di Android 11, NNAPI menyertakan kualitas layanan (QoS) yang lebih baik dengan memungkinkan aplikasi menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diperkirakan untuk menyiapkan model, dan jumlah waktu maksimum yang diperkirakan untuk menyelesaikan 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 di layanan driver yang membuatnya. Resource khusus model dapat diperoleh 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 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 disukai 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 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 yang akan 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.

  • Membuat kueri 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*: Menampilkan true jika objek NN HAL valid sesuai dengan spesifikasi versi HAL-nya. Jenis OEM dan jenis ekstensi 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 grafik 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 penerapan NNAPI, gunakan pengujian VTS dan CTS yang disertakan dalam framework Android. VTS menjalankan driver Anda secara langsung (tanpa menggunakan framework), sedangkan CTS menjalankannya secara tidak langsung melalui framework. Pengujian 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 di CTS dan VTS untuk NNAPI adalah sebagai berikut:

  • Floating point: abs(expected - actual) <= atol + rtol  * abs(expected); dengan:

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

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

  • 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 penerapan 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 mengetahui detail selengkapnya tentang kriteria presisi, lihat TestRandomGraph.cpp dan TestHarness.h.

Uji kegagalan (fuzz testing)

Tujuan pengujian fuzz adalah menemukan error, pernyataan, pelanggaran memori, atau perilaku umum yang tidak ditentukan 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 melakukan fuzzing karena menggunakan cakupan baris dari 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 driver, driver harus memvalidasi argumen panggilan yang diterima. Validasi ini diverifikasi oleh VTS. Kode validasi ada di frameworks/ml/nn/common/include/ValidateHal.h.

Driver 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

Benchmark 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.
  • MobileNetV2 float dan u8 yang dikuantisasi dalam berbagai ukuran, dijalankan terhadap subkumpulan kecil (1.500 gambar) Open Images Dataset v4.
  • Model akustik berbasis long short-term memory (LSTM) untuk text-to-speech, berjalan pada 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 dari 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 stres dan daftar lengkap pengujian error, lihat platform/test/mlts/benchmark/README.txt.

Menggunakan MLTS

Untuk menggunakan MLTS:

  1. Hubungkan perangkat target ke workstation dan pastikan perangkat dapat dijangkau melalui adb. Mengekspor 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 benchmark, 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 mencakup 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 tanpa tanda tangan juga harus mendukung varian bertanda tangan 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 disiapkan dengan vektor fence sinkronisasi yang akan ditunggu. Untuk informasi selengkapnya, lihat Eksekusi berpagar.
  • Dukungan untuk alur kontrol. Menambahkan operasi IF dan WHILE, yang menggunakan model lain sebagai argumen dan menjalankannya secara bersyarat (IF) atau berulang kali (WHILE). Untuk mengetahui informasi selengkapnya, lihat Alur kontrol.
  • Peningkatan kualitas layanan (QoS) karena aplikasi dapat menunjukkan prioritas relatif modelnya, jumlah waktu maksimum yang diperkirakan untuk model disiapkan, dan jumlah waktu maksimum yang diperkirakan untuk eksekusi selesai. Untuk informasi selengkapnya, lihat Kualitas Layanan.
  • Dukungan untuk domain memori yang menyediakan antarmuka pengalokasi 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 mencakup perubahan penting berikut.

  • Struct Capabilities mencakup semua jenis data, termasuk jenis data skalar, dan mewakili performa non-santai menggunakan vektor, bukan kolom bernama.
  • Metode getVersionString dan getType memungkinkan framework 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 Pengaturan waktu.
  • Dukungan untuk eksekusi dengan satu atau beberapa operand output yang memiliki dimensi atau tingkat yang tidak diketahui. Lihat Bentuk output.
  • Dukungan untuk ekstensi vendor, yang merupakan kumpulan operasi dan jenis 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 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 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 update untuk banyak operasi yang sudah ada. Update ini secara khusus 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 diluaskan
  • Dukungan untuk input dengan kuantisasi campuran di ANEURALNETWORKS_CONCATENATION

Daftar di bawah menunjukkan operasi yang diubah di Android 10. Untuk mengetahui detail lengkap perubahan, lihat OperationCode dalam dokumentasi referensi NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

Android 9

NN HAL 1.1 diperkenalkan di Android 9 dan menyertakan perubahan penting berikut.

  • IDevice::prepareModel_1_1 menyertakan parameter ExecutionPreference. Pengemudi dapat menggunakannya untuk menyesuaikan persiapannya, dengan mengetahui bahwa aplikasi lebih memilih untuk menghemat baterai atau akan menjalankan 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 dan/atau presisi float 16-bit dengan menetapkan Model.relaxComputationFloat32toFloat16 ke true. Struktur Capabilities memiliki kolom tambahan relaxedFloat32toFloat16Performance sehingga driver dapat melaporkan performa longgarnya ke framework.

Android 8.1

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