ไดรเวอร์ 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 ในเวลาคอมไพล์โมเดล ไดรเวอร์แต่ละรายการจะแสดงผลอาร์เรย์บูลีนซึ่งระบุการดำเนินการของโมเดลที่รองรับ โปรแกรมควบคุมอาจระบุว่าไม่รองรับการดำเนินการหนึ่งๆ ด้วยเหตุผลหลายประการ เช่น

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

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

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

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

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

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

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

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

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

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

สําหรับไดรเวอร์ 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 (ไม่บังคับ) ซึ่งจะส่งสัญญาณเมื่อการดําเนินการเสร็จสมบูรณ์ วิธีนี้ช่วยลดค่าใช้จ่ายเพิ่มเติมสำหรับรูปแบบลำดับขนาดเล็กและ Use Case สตรีมมิง นอกจากนี้ การดำเนินการแบบแบ่งเขตยังช่วยให้สามารถทำงานร่วมกันกับคอมโพเนนต์อื่นๆ ที่ส่งสัญญาณหรือรอsync_fenceได้อย่างมีประสิทธิภาพมากขึ้น ดูข้อมูลเพิ่มเติมเกี่ยวกับ sync_fence ได้ที่เฟรมเวิร์กการซิงค์

ในการเรียกใช้ที่มีการกำหนดเขต เฟรมเวิร์กจะเรียกใช้เมธอด IPreparedModel::executeFenced เพื่อเปิดการเรียกใช้แบบอะซิงโครนัสที่มีการกำหนดเขตในโมเดลที่เตรียมไว้ด้วยเวกเตอร์ของเขตการซิงค์ที่จะรอ หากงานแบบแอซิงโครนัสเสร็จสิ้นก่อนที่การเรียกจะแสดงผล ระบบจะแสดงผลแฮนเดิลว่างสำหรับ 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 ถูกต้อง เราขอแนะนำให้ใช้การติดตั้งใช้งานที่เพิ่มประสิทธิภาพซึ่งรวมอยู่ในเฟรมเวิร์กแมชชีนเลิร์นนิงบนอุปกรณ์เคลื่อนที่แทนการติดตั้งใช้งาน NNAPI CPU

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

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

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

• VLogging: 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

• การแปลงเป็นจำนวนเต็ม: ผิดไป 1 (ยกเว้น mobilenet_quantized ที่ผิดไป 3)

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

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

การทดสอบ Fuzz

วัตถุประสงค์ของ Fuzz Testing คือเพื่อค้นหาข้อขัดข้อง การยืนยัน การละเมิดหน่วยความจำ หรือลักษณะการทำงานทั่วไปที่ไม่ระบุในโค้ดที่ทดสอบเนื่องจากปัจจัยต่างๆ เช่น อินพุตที่ไม่คาดคิด สําหรับการทดสอบ Fuzz ของ NNAPI Android จะใช้การทดสอบที่อิงตาม libFuzzer ซึ่งมีประสิทธิภาพในการทดสอบแบบ Fuzz เนื่องจากใช้การครอบคลุมบรรทัดของกรณีทดสอบก่อนหน้าเพื่อสร้างอินพุตแบบสุ่มใหม่ เช่น 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 Dataset v4
• MobileNetV2 ที่มีการปัดเศษเป็น float และ 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 และ Neural Networks 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 รายการรองรับการปัดเศษที่มีเครื่องหมาย แต่ไม่จำเป็นต้องให้ผลลัพธ์เหมือนกัน
• รองรับการดำเนินการแบบกั้นขอบเขตเมื่อเฟรมเวิร์กเรียกใช้เมธอด IPreparedModel::executeFenced เพื่อเปิดใช้งานการดำเนินการแบบกั้นขอบเขตและแบบอะซิงโครนัสในโมเดลที่เตรียมไว้ด้วยเวกเตอร์ของรั้วการซิงค์ที่จะรอ ดูข้อมูลเพิ่มเติมได้ที่การดำเนินการที่มีการกำหนดเขตข้อมูล
• การรองรับการควบคุมโฟลว์ เพิ่มการดำเนินการ 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 เพื่ออนุญาตให้ไดรเวอร์ดำเนินการได้โดยไม่ต้องคัดลอกข้อมูล ดูหัวข้อAHardwareBuffer
• การรองรับการแคชอาร์ติแฟกต์การคอมไพล์ที่ดีขึ้นเพื่อลดเวลาที่ใช้ในการคอมไพล์เมื่อแอปเริ่มต้น ดูการแคชการคอมไพล์

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
• แอปสามารถระบุให้สามารถเรียกใช้การคํานวณเลขทศนิยม 32 บิตโดยใช้ช่วงและ/หรือความแม่นยําของเลขทศนิยม 16 บิตได้โดยการตั้งค่า Model.relaxComputationFloat32toFloat16 เป็น true โครงสร้าง Capabilities มีช่องเพิ่มเติม relaxedFloat32toFloat16Performance เพื่อให้ไดรเวอร์รายงานประสิทธิภาพแบบผ่อนคลายไปยังเฟรมเวิร์กได้

Android 8.1

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