न्यूरल नेटवर्क एपीआई ड्राइवर

यह पृष्ठ न्यूरल नेटवर्क्स एपीआई (एनएनपीआई) ड्राइवर को कार्यान्वित करने के तरीके का एक सिंहावलोकन प्रदान करता है। अधिक जानकारी के लिए, hardware/interfaces/neuralnetworks में एचएएल परिभाषा फ़ाइलों में पाए गए दस्तावेज़ देखें। एक नमूना ड्राइवर कार्यान्वयन frameworks/ml/nn/driver/sample में है।

न्यूरल नेटवर्क्स एपीआई पर अधिक जानकारी के लिए, न्यूरल नेटवर्क्स एपीआई देखें।

तंत्रिका नेटवर्क एचएएल

न्यूरल नेटवर्क्स (एनएन) एचएएल विभिन्न उपकरणों , जैसे ग्राफिक्स प्रोसेसिंग यूनिट (जीपीयू) और डिजिटल सिग्नल प्रोसेसर (डीएसपी) के एक सार को परिभाषित करता है, जो एक उत्पाद (उदाहरण के लिए, एक फोन या टैबलेट) में होते हैं। इन उपकरणों के ड्राइवरों को एनएन एचएएल के अनुरूप होना चाहिए। इंटरफ़ेस hardware/interfaces/neuralnetworks में एचएएल परिभाषा फ़ाइलों में निर्दिष्ट है।

फ्रेमवर्क और ड्राइवर के बीच इंटरफ़ेस का सामान्य प्रवाह चित्र 1 में दर्शाया गया है।

चित्र 1. तंत्रिका नेटवर्क प्रवाह

प्रारंभ

आरंभीकरण के समय, फ्रेमवर्क IDevice::getCapabilities_1_3 का उपयोग करके ड्राइवर से उसकी क्षमताओं के बारे में पूछताछ करता है। @1.3::Capabilities संरचना में सभी डेटा प्रकार शामिल हैं और एक वेक्टर का उपयोग करके गैर-आरामदायक प्रदर्शन का प्रतिनिधित्व करता है।

यह निर्धारित करने के लिए कि उपलब्ध उपकरणों के लिए गणना कैसे आवंटित की जाए, फ्रेमवर्क यह समझने के लिए क्षमताओं का उपयोग करता है कि प्रत्येक ड्राइवर कितनी जल्दी और कितनी ऊर्जा कुशलता से निष्पादन कर सकता है। यह जानकारी प्रदान करने के लिए, ड्राइवर को संदर्भ कार्यभार के निष्पादन के आधार पर मानकीकृत प्रदर्शन संख्याएँ प्रदान करनी होंगी।

IDevice::getCapabilities_1_3 के जवाब में ड्राइवर द्वारा लौटाए गए मानों को निर्धारित करने के लिए, संबंधित डेटा प्रकारों के प्रदर्शन को मापने के लिए NNAPI बेंचमार्क ऐप का उपयोग करें। 32-बिट फ़्लोटिंग पॉइंट मानों के प्रदर्शन को मापने के लिए MobileNet v1 और v2, asr_float , और tts_float मॉडल की अनुशंसा की जाती है और 8-बिट परिमाणित मानों के लिए MobileNet v1 और v2 परिमाणित मॉडल की अनुशंसा की जाती है। अधिक जानकारी के लिए, एंड्रॉइड मशीन लर्निंग टेस्ट सूट देखें।

एंड्रॉइड 9 और उससे पहले के संस्करणों में, Capabilities संरचना में केवल फ्लोटिंग पॉइंट और क्वांटाइज्ड टेंसर के लिए ड्राइवर प्रदर्शन जानकारी शामिल होती है और इसमें स्केलर डेटा प्रकार शामिल नहीं होते हैं।

आरंभीकरण प्रक्रिया के भाग के रूप में, फ्रेमवर्क IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensions , और IDevice::getNumberOfCacheFilesNeeded का उपयोग करके अधिक जानकारी क्वेरी कर सकता है।

उत्पाद रिबूट के बीच, फ्रेमवर्क इस अनुभाग में वर्णित सभी प्रश्नों से अपेक्षा करता है कि वे किसी दिए गए ड्राइवर के लिए हमेशा समान मान रिपोर्ट करें। अन्यथा, उस ड्राइवर का उपयोग करने वाला ऐप कम प्रदर्शन या गलत व्यवहार प्रदर्शित कर सकता है।

संकलन

फ़्रेमवर्क यह निर्धारित करता है कि किसी ऐप से अनुरोध प्राप्त होने पर उसे किन उपकरणों का उपयोग करना है। एंड्रॉइड 10 में, ऐप्स उन डिवाइसों को खोज और निर्दिष्ट कर सकते हैं जिन्हें फ्रेमवर्क चुनता है। अधिक जानकारी के लिए, डिवाइस डिस्कवरी और असाइनमेंट देखें।

मॉडल संकलन समय पर, फ्रेमवर्क IDevice::getSupportedOperations_1_3 पर कॉल करके प्रत्येक उम्मीदवार ड्राइवर को मॉडल भेजता है। प्रत्येक ड्राइवर बूलियन की एक सरणी लौटाता है जो दर्शाता है कि मॉडल के कौन से संचालन समर्थित हैं। एक ड्राइवर यह निर्धारित कर सकता है कि वह कई कारणों से किसी दिए गए ऑपरेशन का समर्थन नहीं कर सकता है। उदाहरण के लिए:

• ड्राइवर डेटा प्रकार का समर्थन नहीं करता.
• ड्राइवर केवल विशिष्ट इनपुट मापदंडों के साथ संचालन का समर्थन करता है। उदाहरण के लिए, एक ड्राइवर 3x3 और 5x5 का समर्थन कर सकता है, लेकिन 7x7 कनवल्शन ऑपरेशन का नहीं।
• ड्राइवर के पास मेमोरी बाधाएँ हैं जो उसे बड़े ग्राफ़ या इनपुट को संभालने से रोकती हैं।

संकलन के दौरान, मॉडल के इनपुट, आउटपुट और आंतरिक ऑपरेंड, जैसा कि OperandLifeTime में वर्णित है, में अज्ञात आयाम या रैंक हो सकते हैं। अधिक जानकारी के लिए, आउटपुट आकार देखें।

फ्रेमवर्क प्रत्येक चयनित ड्राइवर को IDevice::prepareModel_1_3 पर कॉल करके मॉडल के सबसेट को निष्पादित करने के लिए तैयार करने का निर्देश देता है। फिर प्रत्येक ड्राइवर अपना सबसेट संकलित करता है। उदाहरण के लिए, एक ड्राइवर कोड उत्पन्न कर सकता है या वज़न की पुन: व्यवस्थित प्रतिलिपि बना सकता है। चूंकि मॉडल के संकलन और अनुरोधों के निष्पादन के बीच काफी समय लग सकता है, इसलिए संकलन के दौरान डिवाइस मेमोरी के बड़े हिस्से जैसे संसाधनों को आवंटित नहीं किया जाना चाहिए।

सफलता पर, ड्राइवर एक @1.3::IPreparedModel हैंडल लौटाता है। यदि मॉडल का सबसेट तैयार करते समय ड्राइवर विफलता कोड लौटाता है, तो फ्रेमवर्क पूरे मॉडल को सीपीयू पर चलाता है।

किसी ऐप के प्रारंभ होने पर संकलन में लगने वाले समय को कम करने के लिए, ड्राइवर संकलन कलाकृतियों को कैश कर सकता है। अधिक जानकारी के लिए, संकलन कैशिंग देखें।

कार्यान्वयन

जब कोई ऐप किसी अनुरोध को निष्पादित करने के लिए फ्रेमवर्क से पूछता है, तो फ्रेमवर्क तैयार मॉडल पर सिंक्रोनस निष्पादन करने के लिए डिफ़ॉल्ट रूप से IPreparedModel::executeSynchronously_1_3 HAL विधि को कॉल करता है। एक अनुरोध को एसिंक्रोनस रूप से execute_1_3 विधि, executeFenced विधि ( फ़ेंस्ड निष्पादन देखें) का उपयोग करके निष्पादित किया जा सकता है, या बर्स्ट निष्पादन का उपयोग करके निष्पादित किया जा सकता है।

सिंक्रोनस निष्पादन कॉल प्रदर्शन में सुधार करती है और एसिंक्रोनस कॉल की तुलना में थ्रेडिंग ओवरहेड को कम करती है क्योंकि निष्पादन पूरा होने के बाद ही नियंत्रण ऐप प्रक्रिया में वापस आ जाता है। इसका मतलब यह है कि ड्राइवर को ऐप प्रक्रिया को सूचित करने के लिए एक अलग तंत्र की आवश्यकता नहीं है कि निष्पादन पूरा हो गया है।

एसिंक्रोनस execute_1_3 विधि के साथ, निष्पादन शुरू होने के बाद ऐप प्रक्रिया पर नियंत्रण वापस आ जाता है, और ड्राइवर को @1.3::IExecutionCallback उपयोग करके निष्पादन पूरा होने पर फ्रेमवर्क को सूचित करना होगा।

निष्पादन विधि को पारित Request पैरामीटर निष्पादन के लिए उपयोग किए गए इनपुट और आउटपुट ऑपरेंड को सूचीबद्ध करता है। ऑपरेंड डेटा को संग्रहीत करने वाली मेमोरी को पंक्ति-प्रमुख क्रम का उपयोग करना चाहिए, जिसमें पहला आयाम सबसे धीमी गति से पुनरावृत्त होता है और किसी भी पंक्ति के अंत में कोई पैडिंग नहीं होती है। ऑपरेंड के प्रकारों के बारे में अधिक जानकारी के लिए, ऑपरेंड देखें।

एनएन एचएएल 1.2 या उच्चतर ड्राइवरों के लिए, जब अनुरोध पूरा हो जाता है, तो त्रुटि स्थिति, आउटपुट आकार और समय की जानकारी फ्रेमवर्क में वापस आ जाती है। निष्पादन के दौरान, मॉडल के आउटपुट या आंतरिक ऑपरेंड में एक या अधिक अज्ञात आयाम या अज्ञात रैंक हो सकते हैं। जब कम से कम एक आउटपुट ऑपरेंड में अज्ञात आयाम या रैंक होता है, तो ड्राइवर को गतिशील आकार की आउटपुट जानकारी वापस करनी होगी।

एनएन एचएएल 1.1 या उससे कम वाले ड्राइवरों के लिए, अनुरोध पूरा होने पर केवल त्रुटि स्थिति लौटाई जाती है। निष्पादन को सफलतापूर्वक पूरा करने के लिए इनपुट और आउटपुट ऑपरेंड के आयाम पूरी तरह से निर्दिष्ट होने चाहिए। आंतरिक ऑपरेंड में एक या अधिक अज्ञात आयाम हो सकते हैं, लेकिन उनके पास निर्दिष्ट रैंक होना चाहिए।

कई ड्राइवरों तक फैले उपयोगकर्ता अनुरोधों के लिए, फ्रेमवर्क इंटरमीडिएट मेमोरी को आरक्षित करने और प्रत्येक ड्राइवर को कॉल को अनुक्रमित करने के लिए जिम्मेदार है।

एक ही @1.3::IPreparedModel पर समानांतर में एकाधिक अनुरोध शुरू किए जा सकते हैं। ड्राइवर अनुरोधों को समानांतर में निष्पादित कर सकता है या निष्पादन को क्रमबद्ध कर सकता है।

फ़्रेमवर्क ड्राइवर को एक से अधिक तैयार मॉडल रखने के लिए कह सकता है। उदाहरण के लिए, मॉडल m1 तैयार करें, m2 तैयार करें, m1 पर अनुरोध r1 निष्पादित करें, m2 पर r2 निष्पादित करें, m1 पर r3 निष्पादित करें, m2 पर r4 निष्पादित करें, रिलीज़ करें ( क्लीनअप में वर्णित) m1 , और m2 रिलीज़ करें।

पहले धीमी गति से निष्पादन से बचने के लिए जिसके परिणामस्वरूप खराब उपयोगकर्ता अनुभव हो सकता है (उदाहरण के लिए, पहला फ्रेम हकलाना), ड्राइवर को संकलन चरण में अधिकांश आरंभीकरण करना चाहिए। पहले निष्पादन पर आरंभीकरण उन कार्यों तक सीमित होना चाहिए जो जल्दी निष्पादित होने पर सिस्टम स्वास्थ्य को नकारात्मक रूप से प्रभावित करते हैं, जैसे बड़े अस्थायी बफ़र्स को आरक्षित करना या किसी डिवाइस की घड़ी दर को बढ़ाना। जो ड्राइवर केवल सीमित संख्या में समवर्ती मॉडल तैयार कर सकते हैं, उन्हें पहले निष्पादन में अपना आरंभीकरण करना पड़ सकता है।

एंड्रॉइड 10 या उच्चतर में, ऐसे मामलों में जहां एक ही तैयार मॉडल के साथ कई निष्पादन त्वरित उत्तराधिकार में निष्पादित होते हैं, क्लाइंट ऐप और ड्राइवर प्रक्रियाओं के बीच संचार करने के लिए निष्पादन बर्स्ट ऑब्जेक्ट का उपयोग करना चुन सकता है। अधिक जानकारी के लिए, बर्स्ट एक्ज़ीक्यूशन और तेज़ संदेश कतारें देखें।

त्वरित उत्तराधिकार में एकाधिक निष्पादन के लिए प्रदर्शन में सुधार करने के लिए, ड्राइवर अस्थायी बफ़र्स को पकड़ सकता है या घड़ी की दरों को बढ़ा सकता है। यदि निश्चित अवधि के बाद कोई नया अनुरोध नहीं बनाया जाता है, तो संसाधनों को जारी करने के लिए वॉचडॉग थ्रेड बनाने की अनुशंसा की जाती है।

आउटपुट आकार

उन अनुरोधों के लिए जहां एक या अधिक आउटपुट ऑपरेंड में सभी आयाम निर्दिष्ट नहीं हैं, ड्राइवर को निष्पादन के बाद प्रत्येक आउटपुट ऑपरेंड के लिए आयाम जानकारी युक्त आउटपुट आकृतियों की एक सूची प्रदान करनी होगी। आयामों पर अधिक जानकारी के लिए, OutputShape देखें।

यदि अंडरसाइज्ड आउटपुट बफर के कारण निष्पादन विफल हो जाता है, तो ड्राइवर को यह इंगित करना होगा कि आउटपुट आकार की सूची में किस आउटपुट ऑपरेंड में अपर्याप्त बफर आकार है, और अज्ञात आयामों के लिए शून्य का उपयोग करके जितना संभव हो उतना आयामी जानकारी रिपोर्ट करनी चाहिए।

समय

एंड्रॉइड 10 में, एक ऐप निष्पादन समय मांग सकता है यदि ऐप ने संकलन प्रक्रिया के दौरान उपयोग करने के लिए एक एकल डिवाइस निर्दिष्ट किया है। विवरण के लिए, MeasureTiming और डिवाइस डिस्कवरी और असाइनमेंट देखें। इस मामले में, एनएन एचएएल 1.2 ड्राइवर को अनुरोध निष्पादित करते समय निष्पादन अवधि को मापना होगा या UINT64_MAX (यह इंगित करने के लिए कि अवधि अनुपलब्ध है) रिपोर्ट करनी होगी। ड्राइवर को निष्पादन अवधि को मापने के परिणामस्वरूप होने वाले किसी भी प्रदर्शन दंड को कम करना चाहिए।

ड्राइवर Timing संरचना में माइक्रोसेकंड में निम्नलिखित अवधि की रिपोर्ट करता है:

• डिवाइस पर निष्पादन समय: ड्राइवर में निष्पादन समय शामिल नहीं है, जो होस्ट प्रोसेसर पर चलता है।
• ड्राइवर में निष्पादन समय: डिवाइस पर निष्पादन समय शामिल है।

इन अवधियों में वह समय अवश्य शामिल होना चाहिए जब निष्पादन निलंबित कर दिया गया हो, उदाहरण के लिए, जब निष्पादन को अन्य कार्यों से पहले ही रोक दिया गया हो या जब वह किसी संसाधन के उपलब्ध होने की प्रतीक्षा कर रहा हो।

जब ड्राइवर को निष्पादन अवधि मापने के लिए नहीं कहा गया है, या जब कोई निष्पादन त्रुटि होती है, तो ड्राइवर को अवधि को UINT64_MAX के रूप में रिपोर्ट करना होगा। यहां तक ​​कि जब ड्राइवर को निष्पादन अवधि मापने के लिए कहा गया है, तो वह डिवाइस पर समय, ड्राइवर में समय, या दोनों के लिए UINT64_MAX रिपोर्ट कर सकता है। जब ड्राइवर दोनों अवधियों को UINT64_MAX के अलावा किसी अन्य मान के रूप में रिपोर्ट करता है, तो ड्राइवर में निष्पादन समय डिवाइस पर समय के बराबर या उससे अधिक होना चाहिए।

बाड़ेबंदी में निष्पादन

एंड्रॉइड 11 में, एनएनएपीआई निष्पादन को sync_fence हैंडल की सूची की प्रतीक्षा करने की अनुमति देता है और वैकल्पिक रूप से एक sync_fence ऑब्जेक्ट लौटाता है, जो निष्पादन पूरा होने पर संकेत दिया जाता है। यह छोटे अनुक्रम मॉडल और स्ट्रीमिंग उपयोग के मामलों के लिए ओवरहेड को कम करता है। बाड़बंदी निष्पादन अन्य घटकों के साथ अधिक कुशल अंतरसंचालनीयता की भी अनुमति देता है जो sync_fence को संकेत दे सकता है या प्रतीक्षा कर सकता है। sync_fence पर अधिक जानकारी के लिए, सिंक्रोनाइज़ेशन फ्रेमवर्क देखें।

एक बाड़ वाले निष्पादन में, फ्रेमवर्क इंतजार करने के लिए सिंक बाड़ के वेक्टर के साथ तैयार मॉडल पर एक बाड़ लगाए गए, अतुल्यकालिक निष्पादन को लॉन्च करने के लिए IPreparedModel::executeFenced विधि को कॉल करता है। यदि कॉल रिटर्न से पहले एसिंक्रोनस कार्य समाप्त हो जाता है, तो sync_fence के लिए एक खाली हैंडल वापस किया जा सकता है। फ़्रेमवर्क को त्रुटि स्थिति और अवधि की जानकारी क्वेरी करने की अनुमति देने के लिए एक IFencedExecutionCallback ऑब्जेक्ट भी वापस किया जाना चाहिए।

निष्पादन पूरा होने के बाद, निष्पादन की अवधि को मापने वाले निम्नलिखित दो समय मान IFencedExecutionCallback::getExecutionInfo के माध्यम से पूछे जा सकते हैं।

• timingLaunched : जब executeFenced कॉल किया जाता है तब से लेकर जब executeFenced लौटाए गए syncFence संकेत देता है, तब तक की अवधि।
• timingFenced : वह अवधि जब सभी सिंक फ़ेंस जिनके लिए निष्पादन प्रतीक्षा करता है, को संकेत दिया जाता है जब executeFenced लौटाए गए syncFence को संकेत देता है।

बहाव को काबू करें

एंड्रॉइड 11 या उच्चतर चलाने वाले उपकरणों के लिए, एनएनएपीआई में दो नियंत्रण प्रवाह संचालन, IF और WHILE शामिल हैं, जो अन्य मॉडलों को तर्क के रूप में लेते हैं और उन्हें सशर्त ( IF ) या बार-बार ( WHILE ) निष्पादित करते हैं। इसे लागू करने के तरीके के बारे में अधिक जानकारी के लिए नियंत्रण प्रवाह देखें।

सेवा की गुणवत्ता

एंड्रॉइड 11 में, एनएनएपीआई में एक ऐप को अपने मॉडलों की सापेक्ष प्राथमिकताओं, एक मॉडल तैयार करने के लिए अपेक्षित अधिकतम समय और निष्पादन के लिए अपेक्षित अधिकतम समय को इंगित करने की अनुमति देकर सेवा की बेहतर गुणवत्ता (क्यूओएस) शामिल है। पूरा होना। अधिक जानकारी के लिए, सेवा की गुणवत्ता देखें।

साफ - सफाई

जब कोई ऐप तैयार मॉडल का उपयोग करके समाप्त हो जाता है, तो फ्रेमवर्क @1.3::IPreparedModel ऑब्जेक्ट के लिए अपना संदर्भ जारी करता है। जब IPreparedModel ऑब्जेक्ट का संदर्भ नहीं रह जाता है, तो इसे बनाने वाली ड्राइवर सेवा में यह स्वचालित रूप से नष्ट हो जाता है। इस समय ड्राइवर के विध्वंसक कार्यान्वयन में मॉडल-विशिष्ट संसाधनों को पुनः प्राप्त किया जा सकता है। यदि ड्राइवर सेवा चाहती है कि IPreparedModel ऑब्जेक्ट तब स्वचालित रूप से नष्ट हो जाए जब क्लाइंट को इसकी आवश्यकता न हो, तो IPreparedeModel ऑब्जेक्ट को IPreparedModelCallback::notify_1_3 के माध्यम से वापस करने के बाद उसे IPreparedModel ऑब्जेक्ट का कोई संदर्भ नहीं रखना चाहिए।

सि पि यु का उपयोग

ड्राइवरों से अपेक्षा की जाती है कि वे गणनाएँ सेट करने के लिए सीपीयू का उपयोग करें। ड्राइवरों को ग्राफ़ गणना करने के लिए सीपीयू का उपयोग नहीं करना चाहिए क्योंकि यह कार्य को सही ढंग से आवंटित करने के लिए फ्रेमवर्क की क्षमता में हस्तक्षेप करता है। ड्राइवर को उन हिस्सों की रिपोर्ट करनी चाहिए जिन्हें वह संभाल नहीं सकता है और फ्रेमवर्क को बाकी हिस्सों को संभालने देना चाहिए।

फ़्रेमवर्क विक्रेता-परिभाषित संचालन को छोड़कर सभी एनएनएपीआई संचालन के लिए सीपीयू कार्यान्वयन प्रदान करता है। अधिक जानकारी के लिए, विक्रेता एक्सटेंशन देखें।

एंड्रॉइड 10 (एपीआई लेवल 29) में पेश किए गए ऑपरेशन में केवल यह सत्यापित करने के लिए एक संदर्भ सीपीयू कार्यान्वयन है कि सीटीएस और वीटीएस परीक्षण सही हैं। मोबाइल मशीन लर्निंग फ्रेमवर्क में शामिल अनुकूलित कार्यान्वयन को एनएनएपीआई सीपीयू कार्यान्वयन पर प्राथमिकता दी जाती है।

उपयोगिता कार्य

एनएनएपीआई कोडबेस में उपयोगिता फ़ंक्शन शामिल हैं जिनका उपयोग ड्राइवर सेवाओं द्वारा किया जा सकता है।

frameworks/ml/nn/common/include/Utils.h फ़ाइल में मिश्रित उपयोगिता फ़ंक्शन शामिल हैं, जैसे लॉगिंग के लिए और विभिन्न एनएन एचएएल संस्करणों के बीच कनवर्ट करने के लिए उपयोग किए जाते हैं।

• वीलॉगिंग: VLOG एंड्रॉइड के LOG के चारों ओर एक रैपर मैक्रो है जो केवल तभी संदेश लॉग करता है जब उपयुक्त टैग debug.nn.vlog प्रॉपर्टी में सेट किया गया हो। VLOG पर किसी भी कॉल से पहले initVLogMask() कॉल किया जाना चाहिए। VLOG_IS_ON मैक्रो का उपयोग यह जांचने के लिए किया जा सकता है कि VLOG वर्तमान में सक्षम है या नहीं, यदि आवश्यक न हो तो जटिल लॉगिंग कोड को छोड़ दिया जा सकता है। संपत्ति का मूल्य निम्नलिखित में से एक होना चाहिए:

  • एक खाली स्ट्रिंग, जो दर्शाती है कि कोई लॉगिंग नहीं की जानी है।
  • टोकन 1 या all , यह दर्शाता है कि सभी लॉगिंग की जानी है।
  • टैग की एक सूची, जो रिक्त स्थान, अल्पविराम या कोलन द्वारा सीमांकित होती है, जो दर्शाती है कि कौन सी लॉगिंग की जानी है। टैग compilation , cpuexe , driver , execution , manager और model ।

• compliantWithV1_* : यदि एक NN HAL ऑब्जेक्ट को जानकारी खोए बिना एक ही प्रकार के भिन्न HAL संस्करण में परिवर्तित किया जा सकता है, तो यह true लौटाता है। उदाहरण के लिए, यदि मॉडल में NN HAL 1.1 या NN HAL 1.2 में पेश किए गए ऑपरेशन प्रकार शामिल हैं, तो V1_2::Model पर compliantWithV1_0 को कॉल करना false रिटर्न देता है।

• 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 लौटाता है। OEM प्रकार और एक्सटेंशन प्रकार मान्य नहीं हैं. उदाहरण के लिए, यदि मॉडल में एक ऑपरेशन है जो एक ऐसे ऑपरेंड इंडेक्स को संदर्भित करता है जो मौजूद नहीं है, या एक ऑपरेशन जो उस एचएएल संस्करण में समर्थित नहीं है, तो validateModel false रिटर्न देता है।

frameworks/ml/nn/common/include/Tracing.h फ़ाइल में न्यूरल नेटवर्क कोड में सिस्ट्रेसिंग जानकारी जोड़ने को सरल बनाने के लिए मैक्रोज़ शामिल हैं। उदाहरण के लिए, नमूना ड्राइवर में NNTRACE_* मैक्रो इनवोकेशन देखें।

frameworks/ml/nn/common/include/GraphDump.h फ़ाइल में डिबगिंग उद्देश्यों के लिए Model की सामग्री को ग्राफिकल रूप में डंप करने के लिए एक उपयोगिता फ़ंक्शन शामिल है।

• graphDump : निर्दिष्ट स्ट्रीम (यदि प्रदान किया गया है) या लॉगकैट (यदि कोई स्ट्रीम प्रदान नहीं किया गया है) में ग्राफ़विज़ ( .dot ) प्रारूप में मॉडल का प्रतिनिधित्व लिखता है।

मान्यकरण

एनएनएपीआई के अपने कार्यान्वयन का परीक्षण करने के लिए, एंड्रॉइड फ्रेमवर्क में शामिल वीटीएस और सीटीएस परीक्षणों का उपयोग करें। वीटीएस आपके ड्राइवरों को सीधे (फ्रेमवर्क का उपयोग किए बिना) अभ्यास कराता है, जबकि सीटीएस उन्हें ढांचे के माध्यम से अप्रत्यक्ष रूप से अभ्यास कराता है। ये प्रत्येक एपीआई विधि का परीक्षण करते हैं और सत्यापित करते हैं कि ड्राइवरों द्वारा समर्थित सभी ऑपरेशन सही ढंग से काम करते हैं और सटीक आवश्यकताओं को पूरा करने वाले परिणाम प्रदान करते हैं।

एनएनएपीआई के लिए सीटीएस और वीटीएस में सटीक आवश्यकताएं इस प्रकार हैं:

• फ़्लोटिंग-पॉइंट: एब्स (अपेक्षित - वास्तविक) <= एटोल + आरटीओ * एब्स (अपेक्षित); कहाँ:

  • एफपी32 के लिए, एटोल = 1e-5f, आरटीओल = 5.0f * 1.1920928955078125e-7
  • एफपी16 के लिए, एटोल = आरटीओएल = 5.0एफ * 0.0009765625एफ

• क्वांटाइज़्ड: ऑफ-बाय-वन ( mobilenet_quantized को छोड़कर, जो ऑफ-बाय-थ्री है)

• बूलियन: सटीक मिलान

सीटीएस एनएनएपीआई का परीक्षण करने का एक तरीका एनएनएपीआई संदर्भ कार्यान्वयन के साथ प्रत्येक ड्राइवर से निष्पादन परिणामों का परीक्षण और तुलना करने के लिए उपयोग किए जाने वाले निश्चित छद्म यादृच्छिक ग्राफ़ उत्पन्न करना है। एनएन एचएएल 1.2 या उच्चतर वाले ड्राइवरों के लिए, यदि परिणाम सटीक मानदंडों को पूरा नहीं करते हैं, तो सीटीएस एक त्रुटि की रिपोर्ट करता है और डिबगिंग के लिए /data/local/tmp के तहत विफल मॉडल के लिए एक विनिर्देश फ़ाइल को डंप करता है। सटीक मानदंड के बारे में अधिक जानकारी के लिए, TestRandomGraph.cpp और TestHarness.h देखें।

फ़ज़ परीक्षण

फ़ज़ परीक्षण का उद्देश्य अप्रत्याशित इनपुट जैसे कारकों के कारण परीक्षण के तहत कोड में क्रैश, दावे, स्मृति उल्लंघन या सामान्य अपरिभाषित व्यवहार का पता लगाना है। एनएनएपीआई फ़ज़ परीक्षण के लिए, एंड्रॉइड libFuzzer पर आधारित परीक्षणों का उपयोग करता है, जो फ़ज़िंग में कुशल हैं क्योंकि वे नए यादृच्छिक इनपुट उत्पन्न करने के लिए पिछले परीक्षण मामलों की लाइन कवरेज का उपयोग करते हैं। उदाहरण के लिए, libFuzzer उन परीक्षण मामलों का समर्थन करता है जो कोड की नई लाइनों पर चलते हैं। इससे समस्याग्रस्त कोड ढूंढने में लगने वाले समय की मात्रा बहुत कम हो जाती है।

अपने ड्राइवर कार्यान्वयन को मान्य करने के लिए फ़ज़ परीक्षण करने के लिए, अपने ड्राइवर कोड को शामिल करने के लिए AOSP में पाए गए libneuralnetworks_driver_fuzzer परीक्षण उपयोगिता में frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp संशोधित करें। एनएनएपीआई फ़ज़ परीक्षण के बारे में अधिक जानकारी के लिए, frameworks/ml/nn/runtime/test/android_fuzzing/README.md देखें।

सुरक्षा

क्योंकि ऐप प्रक्रियाएं ड्राइवर की प्रक्रिया के साथ सीधे संचार करती हैं, ड्राइवरों को उन्हें प्राप्त कॉल के तर्कों को मान्य करना होगा। यह सत्यापन वीटीएस द्वारा सत्यापित है। सत्यापन कोड frameworks/ml/nn/common/include/ValidateHal.h में है।

ड्राइवरों को यह भी सुनिश्चित करना चाहिए कि एक ही डिवाइस का उपयोग करते समय ऐप्स अन्य ऐप्स के साथ हस्तक्षेप न कर सकें।

एंड्रॉइड मशीन लर्निंग टेस्ट सूट

एंड्रॉइड मशीन लर्निंग टेस्ट सूट (एमएलटीएस) विक्रेता उपकरणों पर वास्तविक मॉडल की सटीकता को मान्य करने के लिए सीटीएस और वीटीएस में शामिल एक एनएनएपीआई बेंचमार्क है। बेंचमार्क विलंबता और सटीकता का मूल्यांकन करता है, और समान मॉडल और डेटासेट के लिए सीपीयू पर चलने वाले टीएफ लाइट का उपयोग करके ड्राइवरों के परिणामों की तुलना करता है। यह सुनिश्चित करता है कि ड्राइवर की सटीकता सीपीयू संदर्भ कार्यान्वयन से बदतर नहीं है।

एंड्रॉइड प्लेटफ़ॉर्म डेवलपर्स ड्राइवरों की विलंबता और सटीकता का मूल्यांकन करने के लिए एमएलटीएस का भी उपयोग करते हैं।

एनएनएपीआई बेंचमार्क एओएसपी में दो परियोजनाओं में पाया जा सकता है:

• platform/test/mlts/benchmark (बेंचमार्क ऐप)
• platform/test/mlts/models (मॉडल और डेटासेट)

मॉडल और डेटासेट

एनएनएपीआई बेंचमार्क निम्नलिखित मॉडल और डेटासेट का उपयोग करता है।

• MobileNetV1 फ़्लोट और u8 को विभिन्न आकारों में परिमाणित किया गया है, जो ओपन इमेज डेटासेट v4 के एक छोटे उपसमूह (1500 छवियों) के विरुद्ध चलता है।
• MobileNetV2 फ़्लोट और u8 को विभिन्न आकारों में परिमाणित किया गया है, जो ओपन इमेज डेटासेट v4 के एक छोटे उपसमूह (1500 छवियों) के विरुद्ध चलता है।
• टेक्स्ट-टू-स्पीच के लिए दीर्घकालिक अल्पकालिक मेमोरी (एलएसटीएम) आधारित ध्वनिक मॉडल, सीएमयू आर्कटिक सेट के एक छोटे उपसमूह के खिलाफ चलता है।
• स्वचालित वाक् पहचान के लिए LSTM आधारित ध्वनिक मॉडल, LibriSpeech डेटासेट के एक छोटे उपसमूह के विरुद्ध चलता है।

अधिक जानकारी के लिए, platform/test/mlts/models देखें।

तनाव परीक्षण

एंड्रॉइड मशीन लर्निंग टेस्ट सूट में भारी उपयोग की स्थितियों या ग्राहकों के व्यवहार के कोने के मामलों में ड्राइवरों की लचीलापन को मान्य करने के लिए क्रैश परीक्षणों की एक श्रृंखला शामिल है।

सभी क्रैश परीक्षण निम्नलिखित सुविधाएँ प्रदान करते हैं:

• हैंग का पता लगाना: यदि परीक्षण के दौरान एनएनएपीआई क्लाइंट हैंग हो जाता है, तो विफलता के कारण HANG के कारण परीक्षण विफल हो जाता है और परीक्षण सूट अगले परीक्षण में चला जाता है।
• एनएनएपीआई क्लाइंट क्रैश डिटेक्शन: परीक्षण क्लाइंट क्रैश से बचे रहते हैं और परीक्षण विफलता कारण CRASH के साथ विफल हो जाते हैं।
• ड्राइवर दुर्घटना का पता लगाना: परीक्षण ड्राइवर दुर्घटना का पता लगा सकते हैं जो एनएनएपीआई कॉल पर विफलता का कारण बनता है। ध्यान दें कि ड्राइवर प्रक्रियाओं में क्रैश हो सकते हैं जो एनएनएपीआई विफलता का कारण नहीं बनते हैं और परीक्षण विफल होने का कारण नहीं बनते हैं। इस प्रकार की विफलता को कवर करने के लिए, ड्राइवर-संबंधी त्रुटियों या क्रैश के लिए सिस्टम लॉग पर tail कमांड चलाने की अनुशंसा की जाती है।
• सभी उपलब्ध त्वरक को लक्षित करना: सभी उपलब्ध ड्राइवरों के विरुद्ध परीक्षण चलाए जाते हैं।

सभी क्रैश परीक्षणों के निम्नलिखित चार संभावित परिणाम होते हैं:

• SUCCESS : निष्पादन बिना किसी त्रुटि के पूरा हुआ।
• FAILURE : निष्पादन विफल रहा. आमतौर पर किसी मॉडल का परीक्षण करते समय विफलता के कारण होता है, जो दर्शाता है कि ड्राइवर मॉडल को संकलित या निष्पादित करने में विफल रहा है।
• HANG : परीक्षण प्रक्रिया अनुत्तरदायी हो गई.
• CRASH : परीक्षण प्रक्रिया क्रैश हो गई.

तनाव परीक्षण के बारे में अधिक जानकारी और क्रैश परीक्षणों की पूरी सूची के लिए, platform/test/mlts/benchmark/README.txt देखें।

एमएलटीएस का प्रयोग करें

एमएलटीएस का उपयोग करने के लिए:

1. एक लक्ष्य डिवाइस को अपने वर्कस्टेशन से कनेक्ट करें और सुनिश्चित करें कि यह एडीबी के माध्यम से पहुंच योग्य है। यदि एक से अधिक डिवाइस कनेक्ट हैं तो लक्ष्य डिवाइस ANDROID_SERIAL पर्यावरण चर निर्यात करें।

2. एंड्रॉइड शीर्ष-स्तरीय स्रोत निर्देशिका में cd ।

   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 देखें।

तंत्रिका नेटवर्क एचएएल संस्करण

यह अनुभाग एंड्रॉइड और न्यूरल नेटवर्क एचएएल संस्करणों में पेश किए गए परिवर्तनों का वर्णन करता है।

एंड्रॉइड 11

एंड्रॉइड 11 ने एनएन एचएएल 1.3 पेश किया है, जिसमें निम्नलिखित उल्लेखनीय परिवर्तन शामिल हैं।

• एनएनएपीआई में हस्ताक्षरित 8-बिट परिमाणीकरण के लिए समर्थन। TENSOR_QUANT8_ASYMM_SIGNED ऑपरेंड प्रकार जोड़ता है। एनएन एचएएल 1.3 वाले ड्राइवर जो अहस्ताक्षरित परिमाणीकरण के साथ संचालन का समर्थन करते हैं, उन्हें उन परिचालनों के हस्ताक्षरित वेरिएंट का भी समर्थन करना चाहिए। अधिकांश परिमाणित संचालन के हस्ताक्षरित और अहस्ताक्षरित संस्करण चलाते समय, ड्राइवरों को 128 के ऑफसेट तक समान परिणाम देना होगा। इस आवश्यकता के पांच अपवाद हैं: CAST , HASHTABLE_LOOKUP , LSH_PROJECTION , PAD_V2 , और QUANTIZED_16BIT_LSTM । QUANTIZED_16BIT_LSTM ऑपरेशन हस्ताक्षरित ऑपरेंड का समर्थन नहीं करता है और अन्य चार ऑपरेशन हस्ताक्षरित परिमाणीकरण का समर्थन करते हैं लेकिन परिणाम समान होने की आवश्यकता नहीं है।
• फ़ेंसिड निष्पादन के लिए समर्थन जहां फ़्रेमवर्क IPreparedModel::executeFenced विधि को कॉल करता है ताकि प्रतीक्षा करने के लिए सिंक फ़ेंस के वेक्टर के साथ तैयार मॉडल पर फ़ेंसिड, एसिंक्रोनस निष्पादन लॉन्च किया जा सके। अधिक जानकारी के लिए, बाड़बंदी निष्पादन देखें।
• नियंत्रण प्रवाह के लिए समर्थन. IF और WHILE ऑपरेशन जोड़ता है, जो अन्य मॉडलों को तर्क के रूप में लेता है और उन्हें सशर्त ( IF ) या बार-बार ( WHILE ) निष्पादित करता है। अधिक जानकारी के लिए नियंत्रण प्रवाह देखें।
• सेवा की बेहतर गुणवत्ता (क्यूओएस) क्योंकि ऐप्स अपने मॉडलों की सापेक्ष प्राथमिकताओं, किसी मॉडल को तैयार करने के लिए अपेक्षित अधिकतम समय और किसी निष्पादन को पूरा करने के लिए अपेक्षित अधिकतम समय का संकेत दे सकते हैं। अधिक जानकारी के लिए, सेवा की गुणवत्ता देखें।
• मेमोरी डोमेन के लिए समर्थन जो ड्राइवर-प्रबंधित बफ़र्स के लिए एलोकेटर इंटरफ़ेस प्रदान करता है। यह निष्पादन के दौरान डिवाइस की मूल यादों को पारित करने, अनावश्यक डेटा प्रतिलिपि को दबाने और एक ही ड्राइवर पर लगातार निष्पादन के बीच परिवर्तन की अनुमति देता है। अधिक जानकारी के लिए, मेमोरी डोमेन देखें।

एंड्रॉइड 10

एंड्रॉइड 10 ने एनएन एचएएल 1.2 पेश किया है, जिसमें निम्नलिखित उल्लेखनीय परिवर्तन शामिल हैं।

• Capabilities संरचना में स्केलर डेटा प्रकारों सहित सभी डेटा प्रकार शामिल हैं, और नामित फ़ील्ड के बजाय एक वेक्टर का उपयोग करके गैर-रिलैक्स्ड प्रदर्शन का प्रतिनिधित्व करता है।
• getVersionString और getType विधियाँ फ्रेमवर्क को डिवाइस प्रकार ( DeviceType ) और संस्करण जानकारी पुनर्प्राप्त करने की अनुमति देती हैं। डिवाइस डिस्कवरी और असाइनमेंट देखें।
• किसी निष्पादन को समकालिक रूप से निष्पादित करने के लिए executeSynchronously विधि को डिफ़ॉल्ट रूप से कॉल किया जाता है। execute_1_2 विधि फ्रेमवर्क को एसिंक्रोनस रूप से निष्पादन करने के लिए कहती है। निष्पादन देखें.
• executeSynchronously , execute_1_2 और बर्स्ट एक्जीक्यूशन के लिए MeasureTiming पैरामीटर निर्दिष्ट करता है कि ड्राइवर को निष्पादन अवधि को मापना है या नहीं। परिणाम Timing संरचना में बताए गए हैं। समय देखें.
• निष्पादन के लिए समर्थन जहां एक या अधिक आउटपुट ऑपरेंड में अज्ञात आयाम या रैंक होता है। आउटपुट आकार देखें.
• विक्रेता एक्सटेंशन के लिए समर्थन, जो विक्रेता-परिभाषित संचालन और डेटा प्रकारों का संग्रह है। ड्राइवर IDevice::getSupportedExtensions विधि के माध्यम से समर्थित एक्सटेंशन की रिपोर्ट करता है। विक्रेता एक्सटेंशन देखें.
• ऐप और ड्राइवर प्रक्रियाओं के बीच संचार करने के लिए तेज़ संदेश कतारों (एफएमक्यू) का उपयोग करके बर्स्ट निष्पादन के एक सेट को नियंत्रित करने के लिए बर्स्ट ऑब्जेक्ट की क्षमता, विलंबता को कम करती है। बर्स्ट निष्पादन और तेज़ संदेश कतारें देखें।
• ड्राइवर को डेटा कॉपी किए बिना निष्पादन करने की अनुमति देने के लिए AHardwareBuffer के लिए समर्थन। AHardwareBuffer देखें।
• किसी ऐप के प्रारंभ होने पर संकलन में लगने वाले समय को कम करने के लिए संकलन कलाकृतियों की कैशिंग के लिए बेहतर समर्थन। संकलन कैशिंग देखें.

एंड्रॉइड 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

एंड्रॉइड 10 कई मौजूदा ऑपरेशनों के लिए अपडेट पेश करता है। अद्यतन मुख्यतः निम्नलिखित से संबंधित हैं:

• एनसीएचडब्ल्यू मेमोरी लेआउट के लिए समर्थन
• सॉफ्टमैक्स और सामान्यीकरण संचालन में 4 से भिन्न रैंक वाले टेंसर के लिए समर्थन
• विस्तारित कनवल्शन के लिए समर्थन
• ANEURALNETWORKS_CONCATENATION में मिश्रित परिमाणीकरण के साथ इनपुट के लिए समर्थन

नीचे दी गई सूची उन ऑपरेशनों को दिखाती है जो एंड्रॉइड 10 में संशोधित किए गए हैं। परिवर्तनों के पूर्ण विवरण के लिए, एनएनएपीआई संदर्भ दस्तावेज़ में ऑपरेशनकोड देखें।

• 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

एनएन एचएएल 1.1 को एंड्रॉइड 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 16परफॉर्मेंस है ताकि ड्राइवर फ्रेमवर्क को अपने रिलैक्स्ड प्रदर्शन की रिपोर्ट कर सके।

एंड्रॉइड 8.1

प्रारंभिक न्यूरल नेटवर्क एचएएल (1.0) एंड्रॉइड 8.1 में जारी किया गया था। अधिक जानकारी के लिए /neuralnetworks/1.0/ देखें।