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

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

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

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

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

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

สำหรับคำขอที่ตัวถูกดำเนินการเอาต์พุตอย่างน้อย 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/