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

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

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

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

โครงข่ายระบบประสาทเทียม (NN) HAL จะกำหนดนามธรรมของอุปกรณ์ต่างๆ เช่น หน่วยประมวลผลกราฟิก (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 จะมีข้อมูลประสิทธิภาพของไดรเวอร์สำหรับจุดลอยตัวและ Tensor แบบควอนไทล์เท่านั้น และไม่รวมประเภทข้อมูลสเกลาร์

เฟรมเวิร์กอาจค้นหาข้อมูลเพิ่มเติมโดยใช้ 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 Executions and Fast Message Queues.

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

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

สำหรับคำขอที่ตัวถูกดำเนินการเอาต์พุตอย่างน้อย 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 มีฟังก์ชันยูทิลิตีสำหรับการตรวจสอบว่าออบเจ็กต์ NN HAL ถูกต้องตามข้อกำหนดของเวอร์ชัน 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(คาดหวัง - จริง) <= atol + rtol * abs(คาดหวัง); ซึ่ง:

  • สำหรับ 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 เพื่อระบุรหัสไดรเวอร์ ดูข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบ NNAPI Fuzz ได้ที่ 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 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 และ 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) เพื่อสื่อสารระหว่างแอปและกระบวนการของไดรเวอร์ ซึ่งช่วยลดเวลาในการตอบสนอง โปรดดู Burst Execution และ Fast Message Queues
• รองรับ AHardwareBuffer เพื่อช่วยให้ไดรเวอร์ ดำเนินการต่างๆ ได้โดยไม่ต้องคัดลอกข้อมูล โปรดดู A hardwareBuffer
• ปรับปรุงการรองรับการแคชอาร์ติแฟกต์สำหรับการคอมไพล์เพื่อลดเวลาที่ใช้ในการคอมไพล์เมื่อแอปเริ่มทำงาน ดูการแคชการคอมไพล์

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/ สำหรับข้อมูลเพิ่มเติม