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

इस पेज पर, न्यूरल नेटवर्क एपीआई (NNAPI) ड्राइवर को लागू करने के तरीके के बारे में खास जानकारी दी गई है. ज़्यादा जानकारी के लिए, hardware/interfaces/neuralnetworks में मौजूद HAL डेफ़िनिशन फ़ाइलों में दिया गया दस्तावेज़ देखें. ड्राइवर के लिए लागू करने का एक उदाहरण frameworks/ml/nn/driver/sample में दिया गया है.

Neural Networks API के बारे में ज़्यादा जानकारी के लिए, Neural Networks API देखें.

न्यूरल नेटवर्क एचएएल

न्यूरल नेटवर्क (एनएन) एचएएल, अलग-अलग डिवाइसों के ऐब्स्ट्रैक्शन को तय करता है. जैसे, ग्राफ़िक्स प्रोसेसिंग यूनिट (जीपीयू) और डिजिटल सिग्नल प्रोसेसर (डीएसपी), जो किसी प्रॉडक्ट (जैसे, फ़ोन या टैबलेट) में मौजूद होते हैं. इन डिवाइसों के ड्राइवर, NN HAL के मुताबिक होने चाहिए. इंटरफ़ेस, HAL की परिभाषा वाली फ़ाइलों में दिया गया है. ये फ़ाइलें hardware/interfaces/neuralnetworks में मौजूद हैं.

फ़्रेमवर्क और ड्राइवर के बीच इंटरफ़ेस का सामान्य फ़्लो, इमेज 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 क्वांटाइज़्ड मॉडल इस्तेमाल करने का सुझाव दिया जाता है. ज़्यादा जानकारी के लिए, Android Machine Learning Test Suite देखें.

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

शुरू करने की प्रोसेस के दौरान, फ़्रेमवर्क IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, और IDevice::getNumberOfCacheFilesNeeded का इस्तेमाल करके, ज़्यादा जानकारी के लिए क्वेरी कर सकता है.

प्रॉडक्ट रीबूट होने के बीच, फ़्रेमवर्क को उम्मीद होती है कि इस सेक्शन में बताई गई सभी क्वेरी, किसी ड्राइवर के लिए हमेशा एक जैसी वैल्यू रिपोर्ट करें. ऐसा न करने पर, उस ड्राइवर का इस्तेमाल करने वाले ऐप्लिकेशन की परफ़ॉर्मेंस कम हो सकती है या वह गलत तरीके से काम कर सकता है.

कंपाइलेशन

जब फ़्रेमवर्क को किसी ऐप्लिकेशन से अनुरोध मिलता है, तो वह यह तय करता है कि किन डिवाइसों का इस्तेमाल करना है. Android 10 में, ऐप्लिकेशन उन डिवाइसों का पता लगा सकते हैं और उन्हें चुन सकते हैं जिन्हें फ़्रेमवर्क चुनता है. ज़्यादा जानकारी के लिए, डिवाइस ढूंढना और असाइन करना लेख पढ़ें.

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

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

कंपाइलेशन के दौरान, मॉडल के इनपुट, आउटपुट, और इंटरनल ऑपरेंड के डाइमेंशन या रैंक के बारे में जानकारी नहीं हो सकती है. इनके बारे में OperandLifeTime में बताया गया है. ज़्यादा जानकारी के लिए, आउटपुट का आकार देखें.

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

सफल होने पर, ड्राइवर @1.3::IPreparedModel हैंडल दिखाता है. अगर ड्राइवर, मॉडल के सबसेट को तैयार करते समय गड़बड़ी का कोड दिखाता है, तो फ़्रेमवर्क पूरे मॉडल को सीपीयू पर चलाता है.

ऐप्लिकेशन शुरू होने पर कंपाइल करने में लगने वाले समय को कम करने के लिए, ड्राइवर कंपाइल किए गए आर्टफ़ैक्ट को कैश मेमोरी में सेव कर सकता है. ज़्यादा जानकारी के लिए, Compilation Caching देखें.

प्लान लागू करना

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

सिंक्रोनस एक्ज़ीक्यूशन कॉल, एसिंक्रोनस कॉल की तुलना में बेहतर परफ़ॉर्म करते हैं. साथ ही, थ्रेडिंग ओवरहेड को कम करते हैं. ऐसा इसलिए, क्योंकि एक्ज़ीक्यूशन पूरा होने के बाद ही कंट्रोल को ऐप्लिकेशन प्रोसेस पर वापस भेज दिया जाता है. इसका मतलब है कि ड्राइवर को ऐप्लिकेशन प्रोसेस को यह सूचना देने के लिए किसी अलग सिस्टम की ज़रूरत नहीं होती कि कोई टास्क पूरा हो गया है.

एसिंक्रोनस execute_1_3 तरीके में, एक्ज़ीक्यूशन शुरू होने के बाद कंट्रोल, ऐप्लिकेशन प्रोसेस पर वापस आ जाता है. साथ ही, ड्राइवर को फ़्रेमवर्क को यह सूचना देनी होती है कि एक्ज़ीक्यूशन कब पूरा हुआ. इसके लिए, @1.3::IExecutionCallback का इस्तेमाल करना होता है.

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

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

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

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

एक ही @1.3::IPreparedModel पर, एक साथ कई अनुरोध किए जा सकते हैं. ड्राइवर, अनुरोधों को एक साथ या क्रम से पूरा कर सकता है.

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

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

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

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

आउटपुट का आकार

ऐसे अनुरोधों के लिए जिनमें एक या उससे ज़्यादा आउटपुट ऑपरेंड में सभी डाइमेंशन तय नहीं किए गए हैं, ड्राइवर को एक्ज़ीक्यूशन के बाद आउटपुट शेप की एक सूची देनी होगी. इसमें हर आउटपुट ऑपरेंड के लिए डाइमेंशन की जानकारी शामिल होगी. डाइमेंशन के बारे में ज़्यादा जानकारी के लिए, 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 में कंट्रोल फ़्लो के दो ऑपरेशन शामिल हैं: IF और WHILE. ये ऑपरेशन, अन्य मॉडल को आर्ग्युमेंट के तौर पर लेते हैं और उन्हें शर्तों के हिसाब से (IF) या बार-बार (WHILE) लागू करते हैं. इसे लागू करने के तरीके के बारे में ज़्यादा जानने के लिए, कंट्रोल फ़्लो देखें.

सेवा की क्वालिटी

Android 11 में, NNAPI में सेवा की बेहतर क्वालिटी (क्यूओएस) शामिल है. इससे कोई ऐप्लिकेशन, अपने मॉडल की प्राथमिकताएं, मॉडल को तैयार होने में लगने वाला ज़्यादा से ज़्यादा समय, और एक्ज़ीक्यूशन पूरा होने में लगने वाला ज़्यादा से ज़्यादा समय बता सकता है. ज़्यादा जानकारी के लिए, सेवा की क्वालिटी देखें.

क्लीनअप करें

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

सीपीयू का इस्तेमाल

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

यह फ़्रेमवर्क, वेंडर की ओर से तय की गई कार्रवाइयों को छोड़कर, NNAPI की सभी कार्रवाइयों के लिए सीपीयू लागू करने की सुविधा देता है. ज़्यादा जानकारी के लिए, वेंडर एक्सटेंशन देखें.

Android 10 में पेश किए गए ऑपरेशन (एपीआई लेवल 29) के लिए, सिर्फ़ सीपीयू के रेफ़रंस को लागू किया गया है. इससे यह पुष्टि की जा सकती है कि सीटीएस और वीटीएस टेस्ट सही हैं. मोबाइल मशीन लर्निंग फ़्रेमवर्क में शामिल ऑप्टिमाइज़ किए गए इंप्लीमेंटेशन को, NNAPI सीपीयू इंप्लीमेंटेशन के मुकाबले ज़्यादा प्राथमिकता दी जाती है.

उपयोगिता फ़ंक्शन

NNAPI के कोडबेस में यूटिलिटी फ़ंक्शन शामिल होते हैं. इनका इस्तेमाल ड्राइवर की सेवाएं कर सकती हैं.

frameworks/ml/nn/common/include/Utils.h फ़ाइल में कई तरह के यूटिलिटी फ़ंक्शन होते हैं. जैसे, लॉगिंग के लिए इस्तेमाल किए जाने वाले फ़ंक्शन और अलग-अलग NN HAL वर्शन के बीच बदलने के लिए इस्तेमाल किए जाने वाले फ़ंक्शन.

  • VLogging: VLOG, Android के LOG के चारों ओर रैपर मैक्रो है. यह सिर्फ़ तब मैसेज लॉग करता है, जब debug.nn.vlog प्रॉपर्टी में सही टैग सेट किया गया हो. initVLogMask() को VLOG को कॉल करने से पहले कॉल किया जाना चाहिए. 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*: अगर NN HAL ऑब्जेक्ट, HAL वर्शन की खास जानकारी के मुताबिक मान्य है, तो true दिखाता है. OEM टाइप और एक्सटेंशन टाइप की पुष्टि नहीं की जाती. उदाहरण के लिए, अगर मॉडल में कोई ऐसा ऑपरेशन शामिल है जो किसी ऐसे ऑपरेंड इंडेक्स को रेफ़रंस करता है जो मौजूद नहीं है या कोई ऐसा ऑपरेशन शामिल है जो उस HAL वर्शन पर काम नहीं करता है, तो validateModel, false दिखाता है.

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

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

  • graphDump: यह फ़ंक्शन, मॉडल को Graphviz (.dot) फ़ॉर्मैट में लिखता है. अगर कोई स्ट्रीम दी गई है, तो यह फ़ंक्शन मॉडल को उस स्ट्रीम में लिखता है. अगर कोई स्ट्रीम नहीं दी गई है, तो यह फ़ंक्शन मॉडल को logcat में लिखता है.

Validation

NNAPI को लागू करने की जांच करने के लिए, Android फ़्रेमवर्क में शामिल VTS और CTS टेस्ट का इस्तेमाल करें. वीटीएस, आपके ड्राइवर की जांच सीधे तौर पर करता है. इसके लिए, फ़्रेमवर्क का इस्तेमाल नहीं किया जाता. वहीं, सीटीएस, फ़्रेमवर्क के ज़रिए ड्राइवर की जांच करता है. इनसे हर एपीआई तरीके की जांच की जाती है. साथ ही, यह पुष्टि की जाती है कि ड्राइवर के साथ काम करने वाले सभी ऑपरेशन सही तरीके से काम कर रहे हैं और सटीक नतीजे दे रहे हैं.

NNAPI के लिए, सीटीएस और वीटीएस में सटीक होने की ये ज़रूरी शर्तें हैं:

  • फ़्लोटिंग-पॉइंट: abs(expected - actual) <= atol + rtol  * abs(expected); where:

    • fp32 के लिए, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • fp16 के लिए, atol = rtol = 5.0f * 0.0009765625f

  • क्वांटाइज़ किया गया: एक का अंतर (mobilenet_quantized को छोड़कर, जिसमें तीन का अंतर है)

  • बूलियन: एग्ज़ैक्ट मैच

CTS, NNAPI की जांच करने के लिए, तय किए गए स्यूडोरैंडम ग्राफ़ जनरेट करता है. इनका इस्तेमाल, हर ड्राइवर के एक्ज़ीक्यूशन के नतीजों की जांच करने और उनकी तुलना NNAPI के रेफ़रंस इंप्लीमेंटेशन से करने के लिए किया जाता है. NN HAL 1.2 या इससे ऊपर के वर्शन वाले ड्राइवर के लिए, अगर नतीजे सटीक होने की शर्त पूरी नहीं करते हैं, तो CTS गड़बड़ी की रिपोर्ट करता है. साथ ही, डीबग करने के लिए, /data/local/tmp में गड़बड़ी वाले मॉडल के लिए स्पेसिफ़िकेशन फ़ाइल डंप करता है. सटीक होने की शर्तों के बारे में ज़्यादा जानने के लिए, TestRandomGraph.cpp और TestHarness.h देखें.

फ़ज़ टेस्टिंग

फ़ज़ टेस्टिंग का मकसद, टेस्ट किए जा रहे कोड में क्रैश, असर्शन, मेमोरी उल्लंघन या सामान्य तौर पर अनडिफ़ाइंड व्यवहार का पता लगाना है. ऐसा अनचाहे इनपुट जैसे फ़ैक्टर की वजह से होता है. NNAPI की फ़ज़ टेस्टिंग के लिए, Android libFuzzer पर आधारित टेस्ट का इस्तेमाल करता है. ये टेस्ट, फ़ज़िंग के लिए असरदार होते हैं, क्योंकि ये नए रैंडम इनपुट जनरेट करने के लिए, पिछले टेस्ट केस की लाइन कवरेज का इस्तेमाल करते हैं. उदाहरण के लिए, libFuzzer ऐसे टेस्ट केस को प्राथमिकता देता है जो कोड की नई लाइनों पर चलते हैं. इससे, टेस्ट को समस्या वाले कोड का पता लगाने में बहुत कम समय लगता है.

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

सुरक्षा

ऐप्लिकेशन की प्रोसेस, ड्राइवर की प्रोसेस से सीधे तौर पर कम्यूनिकेट करती है. इसलिए, ड्राइवर को कॉल के लिए मिले तर्कों की पुष्टि करनी होगी. इस पुष्टि की पुष्टि VTS करता है. पुष्टि करने के लिए कोड frameworks/ml/nn/common/include/ValidateHal.h में है.

ड्राइवरों को यह भी पक्का करना चाहिए कि एक ही डिवाइस का इस्तेमाल करते समय, ऐप्लिकेशन दूसरे ऐप्लिकेशन में रुकावट न डालें.

Android मशीन लर्निंग टेस्ट सुइट

Android Machine Learning Test Suite (MLTS), NNAPI का एक बेंचमार्क है. इसे CTS और VTS में शामिल किया गया है, ताकि वेंडर के डिवाइसों पर असली मॉडल की सटीकता की पुष्टि की जा सके. बेंचमार्क, लेटेन्सी और सटीक होने का आकलन करता है. साथ ही, ड्राइवर के नतीजों की तुलना, सीपीयू पर चल रहे TF Lite का इस्तेमाल करके मिले नतीजों से करता है. यह तुलना, एक ही मॉडल और डेटासेट के लिए की जाती है. इससे यह पक्का किया जाता है कि ड्राइवर की परफ़ॉर्मेंस, सीपीयू के रेफ़रंस इंप्लीमेंटेशन से बेहतर हो.

Android प्लैटफ़ॉर्म डेवलपर भी एमएलटीएस का इस्तेमाल करते हैं. इससे वे ड्राइवर की लेटेन्सी और सटीक होने का आकलन करते हैं.

NNAPI बेंचमार्क, AOSP के दो प्रोजेक्ट में मिल सकता है:

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

NNAPI बेंचमार्क, इन मॉडल और डेटासेट का इस्तेमाल करता है.

  • MobileNetV1 फ़्लोट और u8 को अलग-अलग साइज़ में क्वांटाइज़ किया गया है. इन्हें Open Images Dataset v4 के छोटे सबसेट (1, 500 इमेज) के साथ चलाया गया है.
  • MobileNetV2 फ़्लोट और u8 क्वांटाइज़ को अलग-अलग साइज़ में, Open Images Dataset v4 के छोटे सबसेट (1,500 इमेज) के साथ चलाया गया.
  • टेक्स्ट को आवाज़ में बदलने के लिए, लॉन्ग शॉर्ट-टर्म मेमोरी (एलएसटीएम) पर आधारित ऐकोस्टिक मॉडल. इसे सीएमयू आर्कटिक सेट के छोटे सबसेट के हिसाब से बनाया गया है.
  • यह अपने-आप बोली पहचानने की सुविधा के लिए, एलएसटीएम पर आधारित ऐकोस्टिक मॉडल है. इसे LibriSpeech डेटासेट के छोटे सबसेट के हिसाब से चलाया जाता है.

ज़्यादा जानकारी के लिए, platform/test/mlts/models देखें.

स्ट्रेस टेस्टिंग

Android Machine Learning Test Suite में, क्रैश टेस्ट की एक सीरीज़ शामिल होती है. इससे यह पुष्टि की जाती है कि ड्राइवर, ज़्यादा इस्तेमाल की स्थितियों में या क्लाइंट के व्यवहार के कॉर्नर केस में काम कर रहे हैं या नहीं.

सभी क्रैश टेस्ट में ये सुविधाएं मिलती हैं:

  • हैंग होने का पता लगाना: अगर NNAPI क्लाइंट, टेस्ट के दौरान हैंग हो जाता है, तो टेस्ट फ़ेल हो जाता है. इसकी वजह HANG होती है. इसके बाद, टेस्ट सुइट अगले टेस्ट पर चला जाता है.
  • NNAPI क्लाइंट क्रैश का पता लगाना: क्लाइंट क्रैश होने पर भी टेस्ट चलते रहते हैं. हालांकि, टेस्ट के फ़ेल होने पर CRASH की वजह से फ़ेल होने की जानकारी दिखती है.
  • ड्राइवर क्रैश का पता लगाना: टेस्ट से, ड्राइवर क्रैश का पता लगाया जा सकता है. इससे NNAPI कॉल में गड़बड़ी होती है. ध्यान दें कि ड्राइवर प्रोसेस में क्रैश हो सकते हैं. हालांकि, इससे NNAPI फ़ेल नहीं होता और टेस्ट भी फ़ेल नहीं होता. इस तरह की गड़बड़ी को ठीक करने के लिए, हमारा सुझाव है कि ड्राइवर से जुड़ी गड़बड़ियों या क्रैश के लिए, सिस्टम लॉग पर tail कमांड चलाएं.
  • सभी उपलब्ध ऐक्सलरेटर को टारगेट करना: टेस्ट, सभी उपलब्ध ड्राइवर के ख़िलाफ़ चलाए जाते हैं.

सभी क्रैश टेस्ट के ये चार संभावित नतीजे हो सकते हैं:

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

स्ट्रेस टेस्टिंग और क्रैश टेस्ट की पूरी सूची के बारे में ज़्यादा जानने के लिए, platform/test/mlts/benchmark/README.txt पर जाएं.

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

    बेंचमार्क रन के आखिर में, नतीजों को एचटीएमएल पेज के तौर पर दिखाया जाता है. साथ ही, इन्हें xdg-open को भेज दिया जाता है.

ज़्यादा जानकारी के लिए, platform/test/mlts/benchmark/README.txt देखें.

न्यूरल नेटवर्क एचएएल के वर्शन

इस सेक्शन में, Android और Neural Networks HAL के वर्शन में किए गए बदलावों के बारे में बताया गया है.

Android 11

Android 11 में NN HAL 1.3 पेश किया गया है. इसमें ये खास बदलाव शामिल हैं.

  • NNAPI में, हस्ताक्षर किए गए 8-बिट क्वांटाइज़ेशन के लिए सहायता. यह 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) लागू करते हैं. ज़्यादा जानकारी के लिए, कंट्रोल फ़्लो देखें.
  • सेवा की बेहतर क्वालिटी (क्यूओएस), क्योंकि ऐप्लिकेशन अपने मॉडल की प्राथमिकताओं के बारे में बता सकते हैं. साथ ही, मॉडल को तैयार होने में लगने वाले ज़्यादा से ज़्यादा समय और मॉडल को पूरा होने में लगने वाले ज़्यादा से ज़्यादा समय के बारे में भी बता सकते हैं. ज़्यादा जानकारी के लिए, सेवा की क्वालिटी देखें.
  • मेमोरी डोमेन के लिए सहायता, जो ड्राइवर-मैनेज किए गए बफ़र के लिए ऐलोकेटर इंटरफ़ेस उपलब्ध कराते हैं. इससे डिवाइस की नेटिव मेमोरी को एक से ज़्यादा बार इस्तेमाल किया जा सकता है. साथ ही, एक ही ड्राइवर पर लगातार इस्तेमाल करने के दौरान, डेटा को ज़रूरत से ज़्यादा कॉपी और ट्रांसफ़ॉर्म करने से रोका जा सकता है. ज़्यादा जानकारी के लिए, मेमोरी डोमेन देखें.

Android 10

Android 10 में NN HAL 1.2 को पेश किया गया है. इसमें ये अहम बदलाव शामिल हैं.

  • Capabilities स्ट्रक्चर में सभी डेटा टाइप शामिल होते हैं. इनमें स्केलर डेटा टाइप भी शामिल हैं. यह नाम वाले फ़ील्ड के बजाय वेक्टर का इस्तेमाल करके, परफ़ॉर्मेंस को दिखाता है.
  • getVersionString और getType तरीकों से, फ़्रेमवर्क को डिवाइस टाइप (DeviceType) और वर्शन की जानकारी मिलती है. डिवाइस ढूंढना और असाइन करना लेख पढ़ें.
  • डिफ़ॉल्ट रूप से, executeSynchronously तरीके को सिंक्रोनस तरीके से लागू किया जाता है. execute_1_2 तरीका, फ़्रेमवर्क को एसिंक्रोनस तरीके से लागू करने के लिए कहता है. लागू करना देखें.
  • executeSynchronously, execute_1_2, और बस्ट एक्ज़ीक्यूशन के लिए MeasureTiming पैरामीटर से यह तय होता है कि ड्राइवर को एक्ज़ीक्यूशन की अवधि को मेज़र करना है या नहीं. नतीजे, Timing स्ट्रक्चर में रिपोर्ट किए जाते हैं. समय देखें.
  • ऐसे एक्ज़ीक्यूशन के लिए सहायता जहां एक या उससे ज़्यादा आउटपुट ऑपरेंड का डाइमेंशन या रैंक पता नहीं है. आउटपुट का आकार देखें.
  • वेंडर एक्सटेंशन के लिए सहायता. ये वेंडर की ओर से तय की गई कार्रवाइयों और डेटा टाइप के कलेक्शन होते हैं. ड्राइवर, IDevice::getSupportedExtensions तरीके से एक्सटेंशन की रिपोर्ट करता है. वेंडर एक्सटेंशन देखें.
  • बर्स्ट ऑब्जेक्ट में, बर्स्ट के कई एक्ज़ीक्यूशन को कंट्रोल करने की सुविधा होती है. इसके लिए, फ़ास्ट मैसेज कतारों (एफ़एमक्यू) का इस्तेमाल किया जाता है. इससे ऐप्लिकेशन और ड्राइवर प्रोसेस के बीच कम समय में डेटा ट्रांसफ़र होता है. बर्स्ट एक्ज़ीक्यूशन और फ़ास्ट मैसेज कतारें देखें.
  • 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 से अलग रैंक वाले टेंसर के लिए सहायता
  • डाइलेटेड कनवोल्यूशन के लिए सहायता
  • ANEURALNETWORKS_CONCATENATION में, अलग-अलग क्वॉन्टाइज़ेशन वाले इनपुट के लिए सहायता

यहां उन कार्रवाइयों की सूची दी गई है जिनमें Android 10 में बदलाव किया गया है. बदलावों के बारे में पूरी जानकारी के लिए, NNAPI के रेफ़रंस दस्तावेज़ में OperationCode देखें.

  • 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 पैरामीटर शामिल है. ड्राइवर इसका इस्तेमाल, मॉडल को तैयार करने के लिए कर सकता है. इससे उसे यह पता चलता है कि ऐप्लिकेशन, बैटरी को बचाने की कोशिश कर रहा है या वह मॉडल को लगातार कई बार कॉल करेगा.
  • नौ नए ऑपरेशन जोड़े गए हैं: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE.
  • कोई ऐप्लिकेशन यह तय कर सकता है कि 32-बिट फ़्लोट कंप्यूटेशन को 16-बिट फ़्लोट रेंज और/या सटीक जानकारी का इस्तेमाल करके चलाया जा सकता है. इसके लिए, उसे Model.relaxComputationFloat32toFloat16 को true पर सेट करना होगा. Capabilities struct में relaxedFloat32toFloat16Performance फ़ील्ड जोड़ा गया है, ताकि ड्राइवर फ़्रेमवर्क को अपनी बेहतर परफ़ॉर्मेंस के बारे में बता सके.

Android 8.1

न्यूरल नेटवर्क एचएएल (1.0) का शुरुआती वर्शन, Android 8.1 में रिलीज़ किया गया था. ज़्यादा जानकारी के लिए, /neuralnetworks/1.0/ देखें.