ไดรเวอร์ API ของโครงข่ายประสาทเทียม

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Neural Networks API โปรดดู Neural Networks API

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

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

ในฐานะที่เป็นส่วนหนึ่งของกระบวนการเริ่มต้น เฟรมเวิร์กอาจสอบถามข้อมูลเพิ่มเติม โดยใช้ IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensions และ IDevice::getNumberOfCacheFilesNeeded

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

การรวบรวม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: การสนับสนุนสำหรับการเรียกการดำเนินการแบบซิงโครนัสทั่วทั้งเลเยอร์ HAL ไม่ได้ขึ้นอยู่กับการเรียกการดำเนินการแบบซิงโครนัสทั่วทั้งเลเยอร์ NDK

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

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

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

เวลา

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

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

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

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

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

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

การประหารชีวิตแบบมีรั้วกั้น

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

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

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

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

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

รหัสฐาน 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 จากเวอร์ชันหนึ่งเป็นอีกเวอร์ชันหนึ่ง คำเตือนจะถูกบันทึกไว้หากการแปลงส่งผลให้ข้อมูลสูญหาย (นั่นคือ หากประเภทเวอร์ชันใหม่ไม่สามารถแสดงค่าได้อย่างสมบูรณ์)

• ความสามารถ: ฟังก์ชัน 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 ให้กับโค้ด Neural Networks ตัวอย่างเช่น ดูการเรียกใช้แมโคร 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, เอทอล = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
  • สำหรับ fp16, atol = rtol = 5.0f * 0.0009765625f

• Quantized: ปิดทีละรายการ (ยกเว้น mobilenet_quantized ซึ่งปิดทีละสาม)

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

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

การทดสอบฟัซซี่

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

หากต้องการดำเนินการทดสอบแบบ Fuzz เพื่อตรวจสอบการใช้งานไดรเวอร์ของคุณ ให้แก้ไข frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp ในยูทิลิตี้การทดสอบ libneuralnetworks_driver_fuzzer ที่พบใน AOSP เพื่อรวมรหัสไดรเวอร์ของคุณ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบฟัซของ 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 สามารถพบได้ในสองโครงการใน 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 Dataset v4
• โมเดลเสียงที่ใช้หน่วยความจำระยะสั้นระยะยาว (LSTM) สำหรับการอ่านออกเสียงข้อความ เทียบกับชุดย่อยเล็กๆ ของชุด CMU Arctic
• โมเดลเสียงที่ใช้ LSTM สำหรับการรู้จำเสียงอัตโนมัติ ทำงานกับชุดย่อยเล็กๆ ของชุดข้อมูล LibriSpeech

สำหรับข้อมูลเพิ่มเติม โปรดดูที่ platform/test/mlts/models

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

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

การทดสอบการชนทั้งหมดมีคุณสมบัติดังต่อไปนี้:

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

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

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบภาวะวิกฤตและรายการการทดสอบการชนทั้งหมด โปรดดูที่ platform/test/mlts/benchmark/README.txt

ใช้ MLTS

หากต้องการใช้ MLTS:

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

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

แอนดรอยด์ 11

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

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

แอนดรอยด์ 10

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

• โครงสร้าง Capabilities ประกอบด้วยประเภทข้อมูลทั้งหมด รวมถึงประเภทข้อมูลสเกลาร์ และแสดงถึงประสิทธิภาพที่ไม่ผ่อนคลายโดยใช้เวกเตอร์แทนที่จะเป็นฟิลด์ที่มีชื่อ
• เมธอด getVersionString และ getType อนุญาตให้เฟรมเวิร์กดึงข้อมูลประเภทอุปกรณ์ ( DeviceType ) และข้อมูลเวอร์ชัน ดู การค้นหาอุปกรณ์และการกำหนด
• เมธอด executeSynchronously ถูกเรียกตามค่าเริ่มต้นเพื่อดำเนินการดำเนินการพร้อมกัน เมธอด execute_1_2 บอกให้เฟรมเวิร์กดำเนินการดำเนินการแบบอะซิงโครนัส ดู การดำเนินการ
• พารามิเตอร์ MeasureTiming เพื่อ executeSynchronously , execute_1_2 และการดำเนินการต่อเนื่อง ระบุว่าไดรเวอร์จะต้องวัดระยะเวลาการดำเนินการหรือไม่ ผลลัพธ์จะถูกรายงานในโครงสร้าง Timing ดู การกำหนดเวลา
• รองรับการดำเนินการที่ตัวถูกดำเนินการเอาต์พุตตั้งแต่หนึ่งตัวขึ้นไปมีมิติหรืออันดับที่ไม่รู้จัก ดู รูปร่างเอาท์พุต
• การสนับสนุนส่วนขยายของผู้ขาย ซึ่งเป็นคอลเลกชันของการดำเนินการและประเภทข้อมูลที่ผู้ขายกำหนด ไดรเวอร์รายงานส่วนขยายที่รองรับผ่านวิธี 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
• รองรับเทนเซอร์ที่มีอันดับแตกต่างจาก 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

แอนดรอยด์ 9

NN HAL 1.1 เปิดตัวใน Android 9 และมีการเปลี่ยนแปลงที่สำคัญดังต่อไปนี้

• IDevice::prepareModel_1_1 มีพารามิเตอร์ ExecutionPreference คนขับสามารถใช้สิ่งนี้เพื่อปรับการเตรียมการ โดยรู้ว่าแอปต้องการประหยัดแบตเตอรี่หรือจะดำเนินการโมเดลในการโทรต่อเนื่องอย่างรวดเร็ว
• มีการเพิ่มการดำเนินการใหม่เก้ารายการ: 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

Neural Networks HAL (1.0) เริ่มต้นเปิดตัวใน Android 8.1 สำหรับข้อมูลเพิ่มเติม โปรดดูที่ /neuralnetworks/1.0/