ไดรเวอร์ API เครือข่ายระบบประสาท

เลิกใช้งานแล้ว: ตั้งแต่ Android 15 เป็นต้นไป ระบบจะเลิกใช้งาน NNAPI (NDK API) ระบบจะยังคงรองรับอินเทอร์เฟซ HAL ของ Neural Networks ต่อไป

ดูข้อมูลเพิ่มเติมได้ใน คู่มือการย้ายข้อมูล NNAPI

หน้านี้จะแสดงภาพรวมเกี่ยวกับวิธีใช้ไดรเวอร์ Neural Networks API (NNAPI) สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารที่อยู่ในไฟล์คำจำกัดความ HAL ใน hardware/interfaces/neuralnetworks ตัวอย่างการใช้งานไดรเวอร์อยู่ใน frameworks/ml/nn/driver/sample

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Neural Networks API ได้ที่ Neural Networks API

HAL โครงข่ายระบบประสาทเทียม

หมายเหตุ: หน้านี้กล่าวถึง HAL โครงข่ายระบบประสาทเทียมเวอร์ชัน 1.3 ใน AOSP หากคุณใช้ไดรเวอร์ในเวอร์ชันอื่น โปรดดู HAL เครือข่ายระบบประสาทเทียมเวอร์ชันที่เกี่ยวข้อง

HAL ของเครือข่ายประสาท (NN) จะกำหนดการแยกแยะอุปกรณ์ต่างๆ เช่น หน่วยประมวลผลกราฟิก (GPU) และหน่วยประมวลผลสัญญาณดิจิทัล (DSP) ที่มีอยู่ในผลิตภัณฑ์ (เช่น โทรศัพท์หรือแท็บเล็ต) ไดรเวอร์ของอุปกรณ์เหล่านี้ ต้องเป็นไปตาม NN HAL อินเทอร์เฟซจะระบุไว้ในไฟล์คำจำกัดความ HAL ใน hardware/interfaces/neuralnetworks

ดูขั้นตอนทั่วไปของอินเทอร์เฟซระหว่างเฟรมเวิร์กและไดรเวอร์ได้ในรูปที่ 1

รูปที่ 1 การไหลของโครงข่ายระบบประสาทเทียม

การเริ่มต้น

ในการเริ่มต้นใช้งาน เฟรมเวิร์กจะค้นหาความสามารถของไดรเวอร์โดยใช้ IDevice::getCapabilities_1_3 โครงสร้าง @1.3::Capabilities มีข้อมูลทุกประเภทและแสดงถึงประสิทธิภาพแบบไม่ผ่อนคลายโดยใช้เวกเตอร์

เฟรมเวิร์กนี้ใช้ความสามารถต่างๆ เพื่อทำความเข้าใจว่าคนขับแต่ละคนสามารถปฏิบัติการได้เร็วและประหยัดพลังงานอย่างไร เพื่อกำหนดวิธีจัดสรรการคำนวณให้กับอุปกรณ์ที่ใช้ได้ ไดรเวอร์ต้องระบุตัวเลขประสิทธิภาพมาตรฐานโดยอิงตามการดำเนินการของภาระงานอ้างอิงเพื่อระบุข้อมูลนี้

หากต้องการระบุค่าที่ไดรเวอร์แสดงผลเพื่อตอบสนองต่อ IDevice::getCapabilities_1_3 ให้ใช้แอปการเปรียบเทียบ NNAPI เพื่อวัดประสิทธิภาพสำหรับประเภทข้อมูลที่เกี่ยวข้อง เราขอแนะนําให้ใช้โมเดล MobileNet v1 และ v2, asr_float และ tts_float เพื่อวัดประสิทธิภาพสําหรับค่าทศนิยม 32 บิต และแนะนําให้ใช้โมเดลที่แปลงค่าเป็นจำนวนเต็มของ MobileNet v1 และ v2 สําหรับค่าที่แปลงค่าเป็นจำนวนเต็ม 8 บิต ดูข้อมูลเพิ่มเติมได้ที่ชุดทดสอบแมชชีนเลิร์นนิงของ Android

ใน Android 9 และต่ำกว่า โครงสร้าง Capabilities จะมีข้อมูลประสิทธิภาพของไดรเวอร์สำหรับเทนเซอร์แบบทศนิยมและแบบเชิงปริมาณเท่านั้น และไม่รวมประเภทข้อมูลสเกลาร์

ในกระบวนการเริ่มต้น เฟรมเวิร์กอาจค้นหาข้อมูลเพิ่มเติมโดยใช้ IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions และ IDevice::getNumberOfCacheFilesNeeded

ระหว่างการรีบูตผลิตภัณฑ์ เฟรมเวิร์กจะคาดหวังว่าการค้นหาทั้งหมดที่อธิบายในส่วนนี้จะรายงานค่าเดียวกันสำหรับไดรเวอร์หนึ่งๆ เสมอ ไม่เช่นนั้น แอปที่ใช้ไดรเวอร์ดังกล่าวอาจมีประสิทธิภาพลดลงหรือทำงานไม่ถูกต้อง

การรวบรวม

เฟรมเวิร์กจะกำหนดว่าจะใช้อุปกรณ์ใดเมื่อได้รับคำขอจากแอป ใน Android 10 แอปจะค้นพบและระบุอุปกรณ์ที่เฟรมเวิร์กจะเลือกได้ ดูข้อมูลเพิ่มเติมได้ที่การตรวจหาและการมอบหมายอุปกรณ์

ในเวลาคอมไพล์โมเดล เฟรมเวิร์กจะส่งโมเดลไปยังไดรเวอร์ของผู้ลงสมัครแต่ละคนโดยเรียกใช้ IDevice::getSupportedOperations_1_3 ไดรเวอร์แต่ละตัวแสดงผลอาร์เรย์ของบูลีนที่ระบุการดำเนินการของโมเดลที่รองรับ โปรแกรมควบคุมอาจระบุว่าไม่รองรับการดำเนินการหนึ่งๆ ด้วยเหตุผลหลายประการ เช่น

• ไดรเวอร์ไม่รองรับประเภทข้อมูลนี้
• ไดรเวอร์รองรับการดำเนินการที่มีพารามิเตอร์อินพุตที่ระบุเท่านั้น ตัวอย่างเช่น ไดรเวอร์อาจรองรับการดำเนินการแบบ Convolution 7x3 และ 5x5 แต่ไม่รองรับการดำเนินการแบบ Convolution 7x7
• ไดรเวอร์มีข้อจำกัดด้านหน่วยความจำที่ทำให้ไม่สามารถจัดการกราฟหรืออินพุตขนาดใหญ่

ในระหว่างการคอมไพล์ อินพุต เอาต์พุต และตัวถูกดำเนินการภายในของโมเดล ตามที่อธิบายไว้ใน OperandLifeTime อาจมีมิติข้อมูลหรืออันดับที่ไม่รู้จัก ดูข้อมูลเพิ่มเติมได้ที่รูปร่างเอาต์พุต

เฟรมเวิร์กจะสั่งให้ไดรเวอร์ที่เลือกแต่ละรายเตรียมตัวเพื่อดำเนินการกับโมเดลชุดย่อยด้วยการเรียกใช้ IDevice::prepareModel_1_3 จากนั้นไดรเวอร์แต่ละตัวจะรวบรวมชุดย่อยของตัวเอง เช่น ไดรเวอร์อาจสร้างโค้ดหรือทำสำเนาน้ำหนักที่เรียงลำดับใหม่ เนื่องจากอาจใช้เวลานานระหว่างการคอมไพล์โมเดลกับการดำเนินการตามคําขอ คุณจึงไม่ควรกําหนดทรัพยากร เช่น หน่วยความจําของอุปกรณ์จํานวนมากระหว่างการคอมไพล์

หากดำเนินการสำเร็จ ไดรฟ์จะแสดง@1.3::IPreparedModel แฮนเดิล หากไดรเวอร์แสดงรหัสข้อผิดพลาดเมื่อเตรียมชุดย่อยของโมเดล เฟรมเวิร์กจะเรียกใช้ทั้งโมเดลใน CPU

หากต้องการลดเวลาที่ใช้ในการคอมไพล์เมื่อแอปเริ่มทำงาน ไดร์เวอร์สามารถแคชอาร์ติแฟกต์การคอมไพล์ได้ สำหรับข้อมูลเพิ่มเติม โปรดดูการแคชการคอมไพล์

การลงมือปฏิบัติ

เมื่อแอปขอให้เฟรมเวิร์กดำเนินการตามคำขอ เฟรมเวิร์กจะเรียกใช้วิธี IPreparedModel::executeSynchronously_1_3 ของ HAL โดยค่าเริ่มต้นเพื่อดำเนินการแบบซิงค์ในโมเดลที่เตรียมไว้ นอกจากนี้ ยังดำเนินการตามคำขอแบบไม่พร้อมกันโดยใช้เมธอด execute_1_3 หรือเมธอด executeFenced (ดูการดำเนินการแบบ Fenced) หรือดำเนินการโดยใช้การดำเนินการแบบต่อเนื่อง

การเรียกใช้การดำเนินการแบบซิงค์จะปรับปรุงประสิทธิภาพและลดค่าใช้จ่ายเพิ่มเติมในการแยกชุดข้อความเมื่อเทียบกับการเรียกใช้แบบไม่พร้อมกัน เนื่องจากระบบจะส่งการควบคุมกลับไปยังกระบวนการของแอปหลังจากที่ดำเนินการเสร็จสมบูรณ์แล้วเท่านั้น ซึ่งหมายความว่าไดรเวอร์ไม่จำเป็นต้องใช้กลไกแยกต่างหากเพื่อแจ้งกระบวนการของแอปว่าการดำเนินการเสร็จสมบูรณ์แล้ว

เมื่อใช้เมธอด execute_1_3 แบบแอซิงโครนัส ระบบจะส่งการควบคุมกลับไปยังกระบวนการของแอปหลังจากที่เริ่มการดําเนินการแล้ว และไดรเวอร์ต้องแจ้งให้เฟรมเวิร์กทราบเมื่อการดําเนินการเสร็จสมบูรณ์ โดยใช้ @1.3::IExecutionCallback

พารามิเตอร์ Request ที่ส่งไปยังเมธอดการดำเนินการจะแสดงตัวถูกดำเนินการของอินพุตและเอาต์พุตที่ใช้สำหรับการดำเนินการ หน่วยความจำที่จัดเก็บข้อมูลออบเจ็กต์ต้องใช้ลําดับแถวตามลําดับ โดยให้มิติข้อมูลแรกทำซ้ำช้าที่สุดและไม่มีแถวที่เพิ่มไว้ท้ายแถว สำหรับข้อมูลเพิ่มเติมเกี่ยวกับประเภทของตัวถูกดำเนินการ โปรดดูตัวดำเนินการ

สําหรับไดรเวอร์ NN HAL 1.2 ขึ้นไป เมื่อคําขอเสร็จสมบูรณ์ ระบบจะแสดงสถานะข้อผิดพลาด รูปร่างเอาต์พุต และข้อมูลการกําหนดเวลาไปยังเฟรมเวิร์ก ในระหว่างการดำเนินการ เอาต์พุตหรือตัวถูกดำเนินการภายในของโมเดลอาจมีมิติข้อมูลหรืออันดับที่ไม่รู้จักอย่างน้อย 1 รายการ เมื่อโอเปอเรเตอร์เอาต์พุตอย่างน้อย 1 รายการมีมิติข้อมูลหรือลําดับที่ไม่รู้จัก ไดร์เวอร์ต้องแสดงข้อมูลเอาต์พุตที่มีขนาดแบบไดนามิก

สำหรับไดรเวอร์ที่มี NN HAL 1.1 หรือต่ำกว่า ระบบจะแสดงเฉพาะสถานะข้อผิดพลาดเมื่อคำขอเสร็จสมบูรณ์เท่านั้น ต้องระบุมิติข้อมูลของโอเปอเรนด์อินพุตและเอาต์พุตอย่างครบถ้วนเพื่อให้การดำเนินการเสร็จสมบูรณ์ ตัวถูกดำเนินการภายในอาจมีมิติข้อมูลที่ไม่รู้จักอย่างน้อย 1 รายการ แต่จะต้องระบุอันดับ

สำหรับคำขอของผู้ใช้ที่ครอบคลุมไดรเวอร์หลายตัว เฟรมเวิร์กจะทำหน้าที่จองหน่วยความจำระดับกลางและจัดลำดับการเรียกไปยังไดรเวอร์แต่ละตัว

คุณเริ่มคำขอหลายรายการพร้อมกันใน@1.3::IPreparedModel เดียวกันได้ ไดรเวอร์สามารถดำเนินการกับคำขอพร้อมกันหรือเรียงลำดับการดำเนินการได้

เฟรมเวิร์กนี้สามารถขอให้ผู้ขับขี่เก็บโมเดลที่เตรียมไว้ได้มากกว่า 1 รายการ เช่น เตรียมโมเดล m1, เตรียม m2, ดำเนินการตามคำขอ r1 ใน m1, ดำเนินการ r2 ใน m2, ดำเนินการ r3 ใน m1, ดำเนินการ r4 ใน m2, เผยแพร่ (อธิบายไว้ในการล้างข้อมูล) m1 และเผยแพร่ m2

เพื่อหลีกเลี่ยงการดำเนินการครั้งแรกที่ช้าซึ่งอาจส่งผลให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ไม่ดี (เช่น เฟรมแรกกระตุก) ไดรเวอร์ควรทำการเริ่มต้นส่วนใหญ่ในขั้นตอนการคอมไพล์ การจัดเตรียมในการใช้งานครั้งแรกควรจำกัดไว้ที่การดำเนินการที่ส่งผลเสียต่อประสิทธิภาพของระบบเมื่อดำเนินการตั้งแต่เนิ่นๆ เช่น การจองบัฟเฟอร์ชั่วคราวขนาดใหญ่หรือการเพิ่มอัตรานาฬิกาของอุปกรณ์ ไดร์เวอร์ที่เตรียมโมเดลพร้อมกันได้เพียงจํานวนจำกัดอาจต้องทําการเริ่มต้นใช้งานเมื่อเรียกใช้ครั้งแรก

ใน Android 10 ขึ้นไป ในกรณีที่มีการเรียกใช้หลายรายการด้วยโมเดลที่เตรียมไว้เดียวกันอย่างต่อเนื่อง ไคลเอ็นต์อาจเลือกใช้ออบเจ็กต์การเรียกใช้แบบ Burst เพื่อสื่อสารระหว่างแอปกับกระบวนการของไดรเวอร์ ดูข้อมูลเพิ่มเติมได้ที่การดำเนินการแบบระเบิดและคิวข้อความที่รวดเร็ว

ผู้ขับขี่สามารถคงบัฟเฟอร์ชั่วคราวหรือเพิ่มอัตรานาฬิกาในการทำงานเพื่อปรับปรุงประสิทธิภาพของการดำเนินการหลายรายการแบบต่อเนื่องกันอย่างรวดเร็ว เราขอแนะนำให้สร้างเธรดเฝ้าติดตามเพื่อปล่อยทรัพยากรหากไม่มีการสร้างคำขอใหม่หลังจากผ่านไปตามระยะเวลาที่กำหนด

หมายเหตุ: การรองรับการเรียกใช้การดำเนินการแบบพร้อมกันทั่วทั้งเลเยอร์ HAL จะไม่ขึ้นอยู่กับการเรียกการดำเนินการแบบพร้อมกันผ่านเลเยอร์ NDK

รูปร่างเอาต์พุต

สำหรับคำขอที่ตัวถูกดำเนินการเอาต์พุตอย่างน้อย 1 รายการไม่ได้ระบุมิติข้อมูลทั้งหมด ไดรเวอร์ต้องระบุรายการรูปร่างเอาต์พุตที่มีข้อมูลมิติข้อมูลของตัวถูกดำเนินการของเอาต์พุตแต่ละรายการหลังการดำเนินการ ดูข้อมูลเพิ่มเติมเกี่ยวกับมิติข้อมูลได้ที่ OutputShape

หากการดำเนินการไม่สำเร็จเนื่องจากบัฟเฟอร์เอาต์พุตขนาดเล็กเกินไป ไดรเวอร์ต้องระบุว่าตัวถูกดำเนินการของเอาต์พุตใดมีขนาดบัฟเฟอร์ไม่เพียงพอในรายการรูปร่างเอาต์พุต และควรรายงานข้อมูลมิติข้อมูลให้ได้มากที่สุด โดยใช้ 0 สำหรับมิติข้อมูลที่ไม่ทราบ

ช่วงเวลา

ใน Android 10 แอปจะขอเวลาดำเนินการ ในกรณีที่แอปได้ระบุให้อุปกรณ์เครื่องเดียวใช้ในระหว่างกระบวนการคอมไพล์ โปรดดูรายละเอียดที่หัวข้อ MeasureTiming และการค้นพบและการกำหนดอุปกรณ์ ในกรณีนี้ โปรแกรมควบคุม NN HAL 1.2 ต้องวัดระยะเวลาการดำเนินการหรือรายงาน UINT64_MAX (เพื่อบ่งบอกว่าไม่มีระยะเวลา) เมื่อดำเนินการตามคำขอ ไดรเวอร์ควรลดผลกระทบด้านประสิทธิภาพใดๆ ซึ่งเกิดจากการวัดระยะเวลาการดำเนินการ

ไดรเวอร์จะรายงานระยะเวลาต่อไปนี้เป็นไมโครวินาทีในโครงสร้าง Timing

• เวลาดำเนินการในอุปกรณ์: ไม่รวมเวลาดำเนินการในไดร์เวอร์ซึ่งทำงานบนโปรเซสเซอร์ของโฮสต์
• เวลาดำเนินการในไดรเวอร์: รวมเวลาดำเนินการในอุปกรณ์

ระยะเวลาเหล่านี้ต้องรวมเวลาที่การดำเนินการถูกระงับ เช่น เมื่อการดำเนินการถูกขัดจังหวะโดยงานอื่นหรือเมื่อรอให้ทรัพยากรพร้อมใช้งาน

หมายเหตุ: แม้ว่าคนขับจะรายงานระยะเวลาเป็นไมโครวินาที แต่เฟรมเวิร์กจะรายงานระยะเวลาเป็นนาโนวินาที (ตามการปรับขนาดระยะเวลาที่ผู้ขับรายงาน)

เมื่อระบบไม่ได้ขอให้นักขับวัดระยะเวลาการดำเนินการ หรือเมื่อเกิดข้อผิดพลาดในการดำเนินการ นักขับต้องรายงานระยะเวลาเป็น UINT64_MAX แม้ว่าระบบจะขอให้คนขับวัดระยะเวลาการดำเนินการ แต่ก็ยังสามารถรายงาน UINT64_MAX สำหรับเวลาในอุปกรณ์ เวลาในไดรเวอร์ หรือทั้ง 2 อย่างได้ เมื่อผู้ขับขี่รายงานระยะเวลาทั้ง 2 รายการเป็นค่าอื่นที่ไม่ใช่ UINT64_MAX เวลาดำเนินการในไดรเวอร์ต้องเท่ากับหรือเกินเวลาในอุปกรณ์

การดำเนินการที่มีการกำหนดขอบเขต

ใน Android 11 นั้น NNAPI อนุญาตให้การดําเนินการรอรายการแฮนเดิล sync_fence และแสดงผลออบเจ็กต์ sync_fence (ไม่บังคับ) ซึ่งจะส่งสัญญาณเมื่อการดําเนินการเสร็จสมบูรณ์ ซึ่งช่วยลดค่าใช้จ่ายสำหรับโมเดลลำดับขนาดเล็กและกรณีการใช้งานสตรีมมิง การดำเนินการแบบ Fenced ยังทำให้สามารถทำงานร่วมกับคอมโพเนนต์อื่นๆ ที่ส่งสัญญาณหรือรอ sync_fence ได้อย่างมีประสิทธิภาพยิ่งขึ้น ดูข้อมูลเพิ่มเติมเกี่ยวกับ sync_fence ได้ที่เฟรมเวิร์กการซิงค์

ในการดําเนินการแบบ Fenced เฟรมเวิร์กจะเรียกใช้เมธอด IPreparedModel::executeFenced เพื่อเริ่มใช้งานการดําเนินการที่ Fenced แบบไม่พร้อมกันในโมเดลที่เตรียมไว้ซึ่งมีเวกเตอร์ของ Sync Fences ให้รอ หากงานแบบแอซิงโครนัสเสร็จสิ้นก่อนที่การเรียกจะแสดงผล ระบบจะแสดงผลแฮนเดิลว่างสำหรับ sync_fence นอกจากนี้ คุณยังต้องแสดงผลออบเจ็กต์ IFencedExecutionCallback เพื่อให้เฟรมเวิร์กสามารถค้นหาข้อมูลสถานะข้อผิดพลาดและระยะเวลา

หลังจากการดำเนินการเสร็จสมบูรณ์ คุณจะค้นหาค่าช่วงเวลา 2 ค่าต่อไปนี้ที่วัดระยะเวลาของการดำเนินการได้ผ่านทาง IFencedExecutionCallback::getExecutionInfo

• timingLaunched: ระยะเวลานับจากที่มีการเรียก executeFenced จนถึงเวลาที่ executeFenced ส่งสัญญาณ syncFence ที่ส่งคืน
• timingFenced: ระยะเวลานับจากที่มีการส่งสัญญาณให้รั้วการซิงค์ทั้งหมดที่การดำเนินการรออยู่ เมื่อ executeFenced ส่งสัญญาณ syncFence ที่แสดงผล

ควบคุมโฟลว์

สำหรับอุปกรณ์ที่ใช้ Android 11 ขึ้นไป NNAPI จะมีการดำเนินการควบคุมการไหลเวียน 2 รายการ ได้แก่ IF และ WHILE ซึ่งจะใช้โมเดลอื่นๆ เป็นอาร์กิวเมนต์และดำเนินการแบบมีเงื่อนไข (IF) หรือแบบซ้ำ (WHILE) ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ได้ที่การควบคุมการไหลเวียน

คุณภาพของบริการ

ใน Android 11 นั้น NNAPI มีการปรับปรุงคุณภาพของบริการ (QoS) โดยอนุญาตให้แอประบุลำดับความสำคัญของโมเดล ระยะเวลาสูงสุดที่คาดว่าจะใช้ในการเตรียมโมเดล และระยะเวลาสูงสุดที่คาดว่าจะใช้ในการดำเนินการให้เสร็จสมบูรณ์ ดูข้อมูลเพิ่มเติมได้ที่คุณภาพของการบริการ

ทำความสะอาดข้อมูล

เมื่อแอปใช้โมเดลที่เตรียมเสร็จแล้ว เฟรมเวิร์กจะเผยแพร่การอ้างอิงไปยังออบเจ็กต์ @1.3::IPreparedModel เมื่อไม่มีการอ้างอิงออบเจ็กต์ IPreparedModel แล้ว ระบบจะทำลายออบเจ็กต์ดังกล่าวโดยอัตโนมัติในบริการไดรเวอร์ที่สร้างออบเจ็กต์ดังกล่าว คุณอ้างสิทธิ์ทรัพยากรเฉพาะรุ่นคืนได้ในตอนนี้ในการนำตัวทำลายลงของไดรเวอร์ หากบริการไดรเวอร์ต้องการให้มีการทำลายออบเจ็กต์ IPreparedModel โดยอัตโนมัติเมื่อไคลเอ็นต์ไม่จำเป็นต้องใช้อีกต่อไป บริการต้องไม่เก็บการอ้างอิงใดๆ ไปยังออบเจ็กต์ IPreparedModel หลังจากที่ออบเจ็กต์ IPreparedeModel ส่งกลับผ่าน IPreparedModelCallback::notify_1_3 แล้ว

การใช้ CPU

ไดรเวอร์ควรใช้ CPU เพื่อตั้งค่าการคํานวณ ไดรเวอร์ไม่ควรใช้ CPU ในการคำนวณกราฟเนื่องจากจะรบกวนความสามารถของเฟรมเวิร์กในการจัดสรรงานอย่างถูกต้อง ไดรเวอร์ควรรายงานส่วนที่ตนเองจัดการให้กับเฟรมเวิร์กไม่ได้และปล่อยให้เฟรมเวิร์กจัดการส่วนที่เหลือเอง

เฟรมเวิร์กนี้จะติดตั้งใช้งาน CPU สำหรับการดำเนินการ NNAPI ทั้งหมด ยกเว้นการดำเนินการที่ผู้ให้บริการกำหนด ดูข้อมูลเพิ่มเติมได้ที่ส่วนขยายของผู้ให้บริการ

การดำเนินการที่เปิดตัวใน Android 10 (API ระดับ 29) จะมีการใช้งาน CPU อ้างอิงเท่านั้นเพื่อยืนยันว่าการทดสอบ CTS และ VTS ถูกต้อง การใช้งานที่เพิ่มประสิทธิภาพซึ่งรวมอยู่ในเฟรมเวิร์กแมชชีนเลิร์นนิงสำหรับอุปกรณ์เคลื่อนที่นั้นเป็นมากกว่าการใช้งาน CPU ของ NNAPI

ฟังก์ชันยูทิลิตี

ฐานของโค้ด NNAPI มีฟังก์ชันยูทิลิตีที่บริการไดรเวอร์ใช้ได้

ไฟล์ frameworks/ml/nn/common/include/Utils.h มีฟังก์ชันยูทิลิตีต่างๆ เช่น ฟังก์ชันที่ใช้สำหรับบันทึกและแปลงระหว่างเวอร์ชัน NN HAL ที่แตกต่างกัน

• การบันทึกวิดีโอ: VLOG เป็นมาโคร Wrapper รอบๆ LOG ของ Android ซึ่งจะบันทึกข้อความเฉพาะในกรณีที่มีการตั้งค่าแท็กที่เหมาะสมในพร็อพเพอร์ตี้ debug.nn.vlog คุณต้องเรียกใช้ initVLogMask() ก่อนเรียกไปยัง VLOG มาโคร VLOG_IS_ON สามารถใช้เพื่อตรวจสอบว่าขณะนี้ VLOG เปิดใช้งานอยู่หรือไม่ ซึ่งจะช่วยให้ข้ามโค้ดการบันทึกที่ซับซ้อนได้หากไม่จําเป็น ค่าของพร็อพเพอร์ตี้ต้องเป็นค่าใดค่าหนึ่งต่อไปนี้

  • สตริงว่างซึ่งบ่งชี้ว่าไม่ต้องบันทึก
  • โทเค็น 1 หรือ all ซึ่งระบุว่าต้องบันทึกข้อมูลทั้งหมด
  • รายการแท็กที่คั่นด้วยเว้นวรรค เครื่องหมายคอมมา หรือโคลอน ซึ่งระบุการบันทึกที่ต้องทำ แท็กดังกล่าว ได้แก่ compilation, cpuexe, driver, execution, manager และ model

• compliantWithV1_*: แสดงผล true หากสามารถแปลงออบเจ็กต์ NN HAL เป็นประเภทเดียวกันของ HAL เวอร์ชันอื่นโดยไม่สูญเสียข้อมูล เช่น การเรียก compliantWithV1_0 ใน V1_2::Model จะแสดงผลเป็น false หากโมเดลมีประเภทการดำเนินการที่เปิดตัวใน NN HAL 1.1 หรือ NN HAL 1.2

• convertToV1_*: แปลงออบเจ็กต์ NN HAL จากเวอร์ชันหนึ่งเป็นเวอร์ชันอื่น ระบบจะบันทึกคําเตือนหาก Conversion ทําให้ข้อมูลสูญหาย (กล่าวคือ หากประเภทเวอร์ชันใหม่ไม่สามารถแสดงค่าได้อย่างเต็มที่)

• ความสามารถ: สามารถใช้ฟังก์ชัน nonExtensionOperandPerformance และ updateเพื่อช่วยสร้างฟิลด์ Capabilities::operandPerformance ได้

• การค้นหาพร็อพเพอร์ตี้ประเภท isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData, nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions

ไฟล์ frameworks/ml/nn/common/include/ValidateHal.h ประกอบด้วยฟังก์ชันยูทิลิตีสำหรับตรวจสอบว่าออบเจ็กต์ HAL ของ NN ถูกต้องตามข้อกำหนดของเวอร์ชัน HAL

• validate*: แสดงผล true หากออบเจ็กต์ NN HAL ถูกต้องตามข้อกำหนดของเวอร์ชัน HAL ไม่มีการตรวจสอบประเภท OEM และประเภทส่วนขยาย เช่น validateModel จะแสดงผลเป็น false หากโมเดลมีการดำเนินการที่อ้างอิงดัชนีออปเรอเรนด์ที่ไม่มีอยู่ หรือการดำเนินการที่ HAL เวอร์ชันนั้นไม่รองรับ

ไฟล์ frameworks/ml/nn/common/include/Tracing.h นี้มีมาโครเพื่อลดความซับซ้อนในการเพิ่มข้อมูล systracing ลงในโค้ดเครือข่ายประสาท ตัวอย่างเช่น ดูการเรียกมาโคร NNTRACE_* ในไดรเวอร์ตัวอย่าง

ไฟล์ frameworks/ml/nn/common/include/GraphDump.h มีฟังก์ชันยูทิลิตีสำหรับแสดงเนื้อหาของ Model ในรูปแบบกราฟิกเพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่อง

• graphDump: เขียนการนำเสนอโมเดลในรูปแบบ Graphviz (.dot) ไปยังสตรีมที่ระบุ (หากมี) หรือไปยัง Logcat (หากไม่ได้ระบุสตรีมไว้)

การตรวจสอบความถูกต้อง

หากต้องการทดสอบการใช้งาน NNAPI ให้ใช้การทดสอบ VTS และ CTS ที่รวมอยู่ในเฟรมเวิร์ก Android VTS จะทดสอบไดรเวอร์โดยตรง (โดยไม่ใช้เฟรมเวิร์ก) ส่วน CTS จะทดสอบไดรเวอร์โดยอ้อมผ่านเฟรมเวิร์ก ซึ่งจะทดสอบเมธอด API แต่ละรายการและยืนยันว่าการดำเนินการทั้งหมดที่ไดรเวอร์รองรับทำงานได้อย่างถูกต้องและให้ผลลัพธ์ที่เป็นไปตามข้อกำหนดด้านความแม่นยำ

ข้อกำหนดความแม่นยำใน CTS และ VTS สำหรับ NNAPI มีดังนี้

• จุดลอยตัว: abs(expected - actual) <= atol + rtol  * abs(expected); โดยที่

  • สำหรับ fp32 ค่า atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
  • สำหรับ fp16, atol = rtol = 5.0f * 0.0009765625f

• วัดปริมาณ: ปิดทีละรายการ (ยกเว้น mobilenet_quantized ที่ออกทีละ 3)

• บูลีน: การทำงานแบบตรงทั้งหมด

วิธีหนึ่งที่ CTS ทดสอบ NNAPI คือการสร้างกราฟแบบสุ่มจำลองแบบคงที่เพื่อใช้ในการทดสอบและเปรียบเทียบผลลัพธ์การดำเนินการจากไดรเวอร์แต่ละรายการกับการใช้งาน NNAPI อ้างอิง สำหรับไดรเวอร์ที่มี NN HAL 1.2 ขึ้นไป หากผลลัพธ์ไม่เป็นไปตามเกณฑ์ความแม่นยำ CTS จะรายงานข้อผิดพลาดและส่งไฟล์ข้อมูลจำเพาะสำหรับโมเดลที่ล้มเหลวภายใต้ /data/local/tmp เพื่อแก้ไขข้อบกพร่อง ดูรายละเอียดเพิ่มเติมเกี่ยวกับเกณฑ์ความแม่นยำได้ที่ TestRandomGraph.cpp และ TestHarness.h

การทดสอบ Fuzz

วัตถุประสงค์ของการทดสอบ Fuzz คือการค้นหาข้อขัดข้อง การยืนยัน การละเมิดการใช้หน่วยความจำ หรือลักษณะการทำงานทั่วไปที่ไม่ได้กำหนดในโค้ดที่อยู่ระหว่างการทดสอบเนื่องจากปัจจัยต่างๆ เช่น อินพุตที่ไม่คาดคิด สำหรับการทดสอบความคล่องแคล่วของ NNAPI นั้น Android ใช้การทดสอบที่อิงตาม libFuzzer ซึ่งมีประสิทธิภาพในการกระจายข้อมูลเนื่องจากใช้การครอบคลุมบรรทัดของกรอบการทดสอบก่อนหน้าเพื่อสร้างอินพุตแบบสุ่มใหม่ เช่น libFuzzer ชอบใช้กรณีทดสอบที่ทำงานในบรรทัดโค้ดใหม่ วิธีนี้ช่วยลดเวลาในการทดสอบเพื่อค้นหาโค้ดที่เป็นปัญหาได้อย่างมาก

หากต้องการทำการทดสอบแบบ Fuzz เพื่อตรวจสอบการติดตั้งใช้งานไดรเวอร์ ให้แก้ไข frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp ในยูทิลิตีทดสอบ libneuralnetworks_driver_fuzzer ที่พบใน AOSP เพื่อรวมโค้ดไดรเวอร์ ดูข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบ Fuzz ของ NNAPI ได้ที่ frameworks/ml/nn/runtime/test/android_fuzzing/README.md

ความปลอดภัย

เนื่องจากกระบวนการของแอปสื่อสารกับกระบวนการของไดรเวอร์โดยตรง โปรแกรมขับจึงต้องตรวจสอบอาร์กิวเมนต์ของการเรียกที่ได้รับ ซึ่งการตรวจสอบนี้จะได้รับการยืนยันโดย VTS รหัสการตรวจสอบอยู่ใน frameworks/ml/nn/common/include/ValidateHal.h

นอกจากนี้ ไดรเวอร์ควรตรวจสอบด้วยว่าแอปจะไม่รบกวนแอปอื่นๆ เมื่อใช้อุปกรณ์เดียวกัน

ชุดทดสอบแมชชีนเลิร์นนิงของ Android

ชุดทดสอบแมชชีนเลิร์นนิง Android (MLTS) เป็นการทดสอบประสิทธิภาพ NNAPI ที่รวมอยู่ใน CTS และ VTS เพื่อตรวจสอบความแม่นยำของโมเดลจริงในอุปกรณ์ของผู้ให้บริการ การเปรียบเทียบนี้จะประเมินเวลาในการตอบสนองและความแม่นยำ รวมถึงเปรียบเทียบผลลัพธ์ของไดรเวอร์กับผลลัพธ์โดยใช้ TF Lite ที่ทำงานอยู่บน CPU สำหรับรุ่นและชุดข้อมูลเดียวกัน วิธีนี้ช่วยให้มั่นใจว่าความแม่นยำของไดรเวอร์จะไม่แย่กว่าการใช้งานข้อมูลอ้างอิง CPU

นอกจากนี้ นักพัฒนาแพลตฟอร์ม Android ยังใช้ MLTS เพื่อประเมินเวลาในการตอบสนองและความแม่นยำของไดรเวอร์ด้วย

การทดสอบ NNAPI จะอยู่ในโปรเจ็กต์ 2 รายการใน AOSP ดังนี้

• platform/test/mlts/benchmark (แอปการเปรียบเทียบประสิทธิภาพ)
• platform/test/mlts/models (โมเดลและชุดข้อมูล)

โมเดลและชุดข้อมูล

การเปรียบเทียบ NNAPI ใช้โมเดลและชุดข้อมูลต่อไปนี้

• MobileNetV1 Float และ u8 ที่แปลงค่าเป็นปริมาณต่างกันในขนาดที่ต่างกัน จะทำงานกับชุดข้อมูลย่อยขนาดเล็ก (1, 500 ภาพ) ของ Open Images v4
• MobileNetV2 ที่มีการแปลงค่าเป็นจำนวนทศนิยมและ u8 ในขนาดต่างๆ ทำงานกับชุดย่อยขนาดเล็ก (1,500 ภาพ) ของชุดข้อมูล Open Images v4
• โมเดลเสียงสำหรับการอ่านออกเสียงข้อความที่ใช้หน่วยความจำระยะสั้น (LSTM) ซึ่งทำงานโดยเทียบกับชุดย่อยของ CMU Arctic
• โมเดลเสียงที่อิงตาม LSTM สำหรับการรู้จำคำพูดอัตโนมัติ ซึ่งทำงานกับชุดข้อมูล LibriSpeech ชุดย่อยขนาดเล็ก

ดูข้อมูลเพิ่มเติมได้ที่ platform/test/mlts/models

การทดสอบความเครียด

ชุดทดสอบแมชชีนเลิร์นนิงของ Android ประกอบด้วยชุดการทดสอบการชนเพื่อตรวจสอบความยืดหยุ่นของผู้ขับขี่เมื่อเจอสภาวะการใช้งานหนักหรือตามสถานการณ์พฤติกรรมของลูกค้า

การทดสอบการชนทั้งหมดมีฟีเจอร์ต่อไปนี้

• การตรวจหาการค้าง: หากไคลเอ็นต์ NNAPI ค้างระหว่างการทดสอบ การทดสอบจะล้มเหลวโดยมีสาเหตุที่ล้มเหลว HANG และชุดทดสอบจะย้ายไปยังการทดสอบถัดไป
• การตรวจจับข้อขัดข้องของไคลเอ็นต์ NNAPI: การทดสอบที่รอดพ้นจากข้อขัดข้องของไคลเอ็นต์และการทดสอบที่ล้มเหลวโดยมีเหตุผลที่ล้มเหลว CRASH
• การตรวจหาข้อขัดข้องของโปรแกรมควบคุม: การทดสอบสามารถตรวจหาข้อขัดข้องของโปรแกรมควบคุมซึ่งทําให้การเรียก NNAPI ล้มเหลว โปรดทราบว่าอาจมีข้อขัดข้องในกระบวนการของไดรเวอร์ซึ่งไม่ทำให้ NNAPI ล้มเหลวและไม่ทำให้การทดสอบล้มเหลว เพื่อรองรับความล้มเหลวประเภทนี้ ขอแนะนำให้เรียกใช้คำสั่ง tail ในบันทึกของระบบเพื่อหาข้อผิดพลาดหรือข้อขัดข้องที่เกี่ยวข้องกับไดรเวอร์
• การกำหนดเป้าหมาย Accelerator ทั้งหมดที่ใช้ได้: ระบบจะทำการทดสอบกับไดรเวอร์ทั้งหมดที่ใช้ได้

การทดสอบข้อขัดข้องทั้งหมดมีผลลัพธ์ที่เป็นไปได้ 4 อย่างดังต่อไปนี้

• SUCCESS: ดำเนินการเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด
• FAILURE: ดำเนินการไม่สำเร็จ โดยปกติแล้วจะเกิดจากความล้มเหลวเมื่อทดสอบโมเดล ซึ่งแสดงให้เห็นว่าไดรเวอร์คอมไพล์หรือดำเนินการกับโมเดลไม่สำเร็จ
• HANG: กระบวนการทดสอบไม่ตอบสนอง
• CRASH: ขั้นตอนการทดสอบขัดข้อง

ดูข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบความเครียดและรายการการทดสอบข้อขัดข้องทั้งหมดได้ที่ platform/test/mlts/benchmark/README.txt

ใช้ MLTS

วิธีใช้ MLTS

1. เชื่อมต่ออุปกรณ์เป้าหมายกับเวิร์กสเตชันและตรวจสอบว่าเข้าถึงผ่าน adb ได้ ส่งออกตัวแปรสภาพแวดล้อม ANDROID_SERIAL ของอุปกรณ์เป้าหมายหากมีการเชื่อมต่ออุปกรณ์มากกว่า 1 เครื่อง

2. cd ลงในไดเรกทอรีแหล่งที่มาระดับบนสุดของ Android

   source build/envsetup.sh
   lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
   ./test/mlts/benchmark/build_and_run_benchmark.sh
   

   เมื่อสิ้นสุดการเรียกใช้เปรียบเทียบ ผลลัพธ์จะแสดงเป็นหน้า HTML และส่งไปยัง xdg-open

ดูข้อมูลเพิ่มเติมได้ที่ platform/test/mlts/benchmark/README.txt

เวอร์ชัน HAL ของโครงข่ายระบบประสาทเทียม

ส่วนนี้จะอธิบายการเปลี่ยนแปลงที่เกิดขึ้นกับเวอร์ชัน Android และ HAL ของโครงข่ายระบบประสาทเทียม

Android 11

Android 11 เปิดตัว NN HAL 1.3 ซึ่งมีการเปลี่ยนแปลงที่น่าสนใจดังต่อไปนี้

• รองรับการวัดขนาด 8 บิตที่มีการรับรองใน NNAPI เพิ่มประเภทการดำเนินการ TENSOR_QUANT8_ASYMM_SIGNED ไดร์เวอร์ที่มี NN HAL 1.3 ที่รองรับการดำเนินการที่มีการปัดเศษแบบไม่ลงนามต้องรองรับตัวแปรแบบลงนามของการดำเนินการเหล่านั้นด้วย เมื่อเรียกใช้การดำเนินการแบบปัดเศษส่วนใหญ่ในเวอร์ชันที่มีและไม่มีเครื่องหมาย โปรแกรมควบคุมต้องให้ผลลัพธ์เดียวกันโดยมีระยะห่าง 128 ข้อกำหนดนี้มีข้อยกเว้น 5 ข้อ ได้แก่ CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2 และ QUANTIZED_16BIT_LSTM การดำเนินการ QUANTIZED_16BIT_LSTM ไม่รองรับตัวถูกดำเนินการที่ลงชื่อ และการดำเนินการอื่นๆ อีก 4 รายการรองรับการวัดปริมาณที่ลงนามแล้ว แต่ไม่จำเป็นต้องให้ผลลัพธ์เหมือนกัน
• รองรับการดำเนินการแบบ Fenced ซึ่งเฟรมเวิร์กเรียกใช้เมธอด IPreparedModel::executeFenced เพื่อเปิดตัวการดำเนินการแบบ Fenced แบบไม่พร้อมกันในโมเดลที่เตรียมไว้ซึ่งมีเวกเตอร์ของ Sync Fences รออยู่ ดูข้อมูลเพิ่มเติมได้ที่การดำเนินการแบบ Fenced
• รองรับขั้นตอนการควบคุม เพิ่มการดำเนินการ IF และ WHILE ซึ่งจะนำโมเดลอื่นๆ เป็นอาร์กิวเมนต์และเรียกใช้อย่างมีเงื่อนไข (IF) หรือซ้ำ (WHILE) ดูข้อมูลเพิ่มเติมได้ที่โฟลว์การควบคุม
• คุณภาพของบริการ (QoS) ที่ดีขึ้นเนื่องจากแอปสามารถระบุลำดับความสำคัญของโมเดล ระยะเวลาสูงสุดที่คาดว่าจะใช้ในการเตรียมโมเดล และระยะเวลาสูงสุดที่คาดว่าจะใช้ในการดำเนินการให้เสร็จสมบูรณ์ ดูข้อมูลเพิ่มเติมได้ที่คุณภาพของการบริการ
• การรองรับโดเมนหน่วยความจำที่มีอินเทอร์เฟซที่จัดสรรสำหรับบัฟเฟอร์ที่จัดการโดยไดรเวอร์ ซึ่งช่วยให้สามารถส่งหน่วยความจำของอุปกรณ์เดิมได้ระหว่างการเรียกใช้ ช่วยลดการคัดลอกและการเปลี่ยนรูปแบบข้อมูลที่ไม่จำเป็นระหว่างการเรียกใช้ต่อเนื่องในไดรเวอร์เดียวกัน ดูข้อมูลเพิ่มเติมได้ที่โดเมนหน่วยความจำ

Android 10

Android 10 เปิดตัว NN HAL 1.2 ซึ่งมีการเปลี่ยนแปลงที่น่าสนใจดังต่อไปนี้

• โครงสร้าง Capabilities ประกอบด้วยข้อมูลทุกประเภทรวมถึงประเภทข้อมูลสเกลาร์ และแสดงถึงประสิทธิภาพแบบไม่ผ่อนปรนโดยใช้เวกเตอร์แทนฟิลด์ที่มีชื่อ
• เมธอด getVersionString และ getType จะทำให้เฟรมเวิร์กดึงข้อมูลประเภทอุปกรณ์ (DeviceType) และข้อมูลเวอร์ชันได้ โปรดดูการค้นหาและการกำหนดอุปกรณ์
• ระบบจะเรียกเมธอด executeSynchronously โดยค่าเริ่มต้นเพื่อดำเนินการเรียกใช้แบบพร้อมกัน เมธอด execute_1_2 จะบอกให้เฟรมเวิร์กดำเนินการแบบไม่พร้อมกัน ดูการดำเนินการ
• พารามิเตอร์ MeasureTiming สำหรับ executeSynchronously, execute_1_2 และการเรียกใช้แบบระเบิดจะระบุว่าโปรแกรมควบคุมจะวัดระยะเวลาการเรียกใช้หรือไม่ ระบบจะรายงานผลลัพธ์ในโครงสร้าง Timing ดูการกำหนดเวลา
• รองรับการดำเนินการที่ตัวถูกดำเนินการเอาต์พุตอย่างน้อย 1 รายการมีมิติข้อมูลหรืออันดับที่ไม่รู้จัก ดูรูปร่างเอาต์พุต
• การรองรับส่วนขยายของผู้ให้บริการ ซึ่งเป็นคอลเล็กชันการดำเนินการและประเภทข้อมูลที่ผู้ให้บริการกำหนด รายงานไดรเวอร์รองรับส่วนขยายผ่านเมธอด IDevice::getSupportedExtensions ดูส่วนขยายของผู้ให้บริการ
• ความสามารถของออบเจ็กต์การระเบิดในการควบคุมชุดการดําเนินการแบบระเบิดโดยใช้คิวข้อความที่รวดเร็ว (FMQ) เพื่อสื่อสารระหว่างแอปกับกระบวนการของไดรเวอร์ ซึ่งจะช่วยลดเวลาในการตอบสนอง ดูการดำเนินการแบบระเบิดและคิวข้อความที่รวดเร็ว
• รองรับ AHardwareBuffer เพื่อช่วยให้ไดรเวอร์ ดำเนินการต่างๆ ได้โดยไม่ต้องคัดลอกข้อมูล โปรดดู Aฮาร์ดแวร์Buffer
• การรองรับการแคชอาร์ติแฟกต์การคอมไพล์ที่ดีขึ้นเพื่อลดเวลาที่ใช้ในการคอมไพล์เมื่อแอปเริ่มทำงาน ดูการแคชการคอมไพล์

Android 10 ขอแนะนำประเภทตัวถูกดำเนินการและโอเปอเรเตอร์ต่อไปนี้

• ประเภทตัวดำเนินการ

  • 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

• การดำเนินการ

  • 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 มีการอัปเดตการดำเนินการที่มีอยู่หลายรายการ การอัปเดตจะเกี่ยวข้องกับเรื่องต่อไปนี้เป็นหลัก

• การรองรับเลย์เอาต์หน่วยความจำ NCHW
• รองรับ Tensor ที่มีอันดับต่ำกว่า 4 ในการดำเนินการ Softmax และการปรับให้สอดคล้องตามมาตรฐาน
• รองรับอาการปวดเมื่อยล้า
• การรองรับอินพุตที่มีการเข้ารหัสแบบผสมใน ANEURALNETWORKS_CONCATENATION

รายการด้านล่างแสดงการดำเนินการที่มีการแก้ไขใน Android 10 ดูรายละเอียดทั้งหมดของการเปลี่ยนแปลงได้ที่ OperationCode ในเอกสารอ้างอิง 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 เปิดตัวใน Android 9 และมีการเปลี่ยนแปลงที่สำคัญดังต่อไปนี้

• IDevice::prepareModel_1_1 มีพารามิเตอร์ ExecutionPreference โปรแกรมขับสามารถปรับการเตรียมความพร้อมโดยใช้ข้อมูลนี้ โดยทราบว่าแอปต้องการประหยัดแบตเตอรี่หรือจะเรียกใช้โมเดลติดต่อกันหลายครั้ง
• มีการเพิ่มการดำเนินการใหม่ 9 รายการ ได้แก่ BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE
• แอประบุได้ว่าสามารถเรียกใช้การคำนวณ Float 32 บิตโดยใช้ช่วงลอยตัว 16 บิตและ/หรือความแม่นยำได้โดยตั้งค่า Model.relaxComputationFloat32toFloat16 เป็น true โครงสร้าง Capabilities มีช่องเพิ่มเติม relaxedFloat32toFloat16Performance เพื่อให้ไดรเวอร์รายงานประสิทธิภาพแบบผ่อนคลายไปยังเฟรมเวิร์กได้

Android 8.1

HAL โครงข่ายระบบประสาทเทียม (1.0) เวอร์ชันแรกเปิดตัวใน Android 8.1 ดูข้อมูลเพิ่มเติมได้ที่ /neuralnetworks/1.0/