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

HAL Jaringan Saraf (NN) menentukan abstraksi dari berbagai perangkat, seperti unit pemrosesan grafis (GPU) dan pemroses 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.

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 lama, struktur Capabilities menyertakan informasi performa driver hanya untuk floating point dan tensor kuantisasi, 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 untuk 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 mengirim model ke setiap driver kandidat dengan memanggil IDevice::getSupportedOperations_1_3. Setiap driver menampilkan array boolean yang menunjukkan operasi model mana yang didukung. Driver dapat menentukan bahwa driver tidak dapat mendukung operasi tertentu karena sejumlah alasan. Contoh:

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

Selama kompilasi, operand input, output, dan 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 mungkin 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 modelnya, framework akan menjalankan seluruh model di CPU.

Untuk mengurangi waktu yang digunakan untuk kompilasi saat aplikasi dimulai, driver dapat menyimpan artefak kompilasi dalam cache. Untuk mengetahui informasi selengkapnya, lihat 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 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 bahwa driver tidak memerlukan mekanisme terpisah untuk memberi tahu proses aplikasi bahwa eksekusi telah 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 pengaturan 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, siapkan model m1, siapkan m2, jalankan permintaan r1 di m1, jalankan r2 di m2, jalankan r3 di m1, jalankan r4 di m2, rilis (dijelaskan dalam Pembersihan) m1, dan rilis m2.

Untuk menghindari eksekusi pertama yang lambat yang dapat menyebabkan pengalaman pengguna yang buruk (misalnya, stutter frame pertama), driver harus melakukan sebagian besar inisialisasi dalam fase kompilasi. Inisialisasi pada eksekusi pertama harus dibatasi pada tindakan yang berdampak negatif pada kesehatan sistem saat dilakukan lebih awal, seperti mencadangkan buffer sementara yang besar atau meningkatkan kecepatan clock perangkat. Driver yang hanya dapat menyiapkan sejumlah kecil model serentak 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.

Untuk meningkatkan performa beberapa eksekusi secara berurutan, driver dapat mempertahankan buffering 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 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 di perangkat: Tidak termasuk waktu eksekusi di driver, yang berjalan di 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.

Jika driver belum diminta untuk mengukur durasi eksekusi, atau saat terjadi error eksekusi, driver harus melaporkan durasi sebagai UINT64_MAX. Meskipun driver telah diminta untuk mengukur durasi eksekusi, driver 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 kecil dan kasus penggunaan streaming. 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 disiapkan dengan vektor fence sinkronisasi yang akan ditunggu. Jika tugas asinkron selesai sebelum panggilan ditampilkan, nama sebutan kosong dapat ditampilkan untuk sync_fence. Objek IFencedExecutionCallback juga harus ditampilkan untuk memungkinkan framework mengkueri status error dan informasi durasi.

Setelah eksekusi selesai, dua nilai timing 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 sejak semua pagar sinkronisasi yang ditunggu eksekusi diberi sinyal hingga saat executeFenced memberi sinyal syncFence yang ditampilkan.

Alur kontrol

Untuk perangkat yang menjalankan Android 11 atau yang lebih baru, 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 ditingkatkan 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 diambil kembali saat ini dalam implementasi penghancur 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 itu akan mengganggu kemampuan framework untuk mengalokasikan pekerjaan dengan benar. Pengemudi 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 telah benar. Implementasi yang dioptimalkan yang disertakan dalam framework machine learning seluler lebih disukai daripada penerapan 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 mengonversi antar-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 diaktifkan, sehingga kode logging yang rumit dapat dilewati jika tidak diperlukan. Nilai properti harus berupa salah satu dari berikut:

    • String kosong, yang menunjukkan bahwa tidak ada logging yang akan 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 HAL NN 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 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 lainnya. Peringatan akan dicatat ke dalam log jika konversi menyebabkan hilangnya informasi (yaitu, jika versi baru jenis tidak dapat sepenuhnya merepresentasikan nilai).

  • Kemampuan: Fungsi nonExtensionOperandPerformance dan update dapat digunakan untuk membantu membuat 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 HAL NN 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 Saraf. Sebagai contoh, lihat pemanggilan makro NNTRACE_* di driver contoh.

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 yang ditentukan (jika disediakan) atau ke logcat (jika tidak ada aliran 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 membuang 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 menyukai kasus pengujian yang berjalan di baris kode baru. Hal ini sangat mengurangi jumlah waktu yang diperlukan pengujian untuk menemukan kode yang bermasalah.

Untuk melakukan pengujian fuzz guna memvalidasi penerapan driver, ubah frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp di utilitas pengujian libneuralnetworks_driver_fuzzer yang ditemukan 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 benchmark NNAPI yang disertakan dalam CTS dan VTS untuk memvalidasi akurasi model sebenarnya di perangkat vendor. Benchmark 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 bahwa akurasi driver tidak lebih buruk daripada penerapan referensi CPU.

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

Benchmark NNAPI dapat ditemukan di dua project di AOSP:

Model dan set data

Benchmark NNAPI menggunakan model dan set data berikut.

  • MobileNetV1 float dan u8 yang dikuantisasi dalam berbagai ukuran, dijalankan terhadap subkumpulan kecil (1.500 gambar) Open Images Dataset 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 terhadap sebagian kecil set data LibriSpeech.

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

Pengujian stres

Android Machine Learning Test Suite mencakup serangkaian pengujian error untuk memvalidasi ketahanan driver dalam kondisi penggunaan yang berat atau dalam kasus sulit perilaku klien.

Semua pengujian error menyediakan fitur berikut:

  • Deteksi hang: Jika klien NNAPI mengalami hang selama pengujian, pengujian akan gagal dengan alasan kegagalan HANG dan rangkaian pengujian akan beralih ke pengujian berikutnya.
  • Deteksi error klien NNAPI: Pengujian bertahan dari error klien dan pengujian gagal dengan alasan kegagalan CRASH.
  • Deteksi error driver: Pengujian dapat mendeteksi error 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 mengatasi kegagalan semacam ini, sebaiknya jalankan perintah tail di log sistem untuk error atau error terkait driver.
  • Penargetan semua akselerator yang tersedia: Pengujian dijalankan pada semua driver yang tersedia.

Semua uji tabrakan 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 menjalankan 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. Ekspor variabel lingkungan ANDROID_SERIAL perangkat target jika lebih dari satu perangkat terhubung.

  2. cd ke dalam 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 di versi HAL Neural Networks dan Android.

Android 11

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

  • Dukungan untuk kuantisasi 8-bit bertanda di NNAPI. Menambahkan jenis operand 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 kuantisasi, driver harus menghasilkan hasil yang sama hingga offset 128. Ada lima pengecualian untuk persyaratan ini: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2, dan QUANTIZED_16BIT_LSTM. Operasi QUANTIZED_16BIT_LSTM tidak mendukung operand bertanda dan empat operasi lainnya mendukung kuantisasi bertanda, tetapi tidak mewajibkan hasil untuk 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 mengeksekusinya secara kondisional (IF) atau berulang (WHILE). Untuk informasi selengkapnya, lihat Alur kontrol.
  • Kualitas layanan (QoS) yang lebih baik 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, yang menyembunyikan penyalinan dan transformasi data yang tidak perlu di antara eksekusi berurutan pada driver yang sama. Untuk 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 ke 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. 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 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 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 yang dilonggarkan ke framework.

Android 8.1

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