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

इस पेज पर, न्यूरल नेटवर्क एपीआई (एनएनएपीआई) ड्राइवर को लागू करने के तरीके के बारे में खास जानकारी दी गई है. ज़्यादा जानकारी के लिए, 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 हैंडल दिखाता है. अगर ड्राइवर, मॉडल के सबसेट को तैयार करते समय गड़बड़ी का कोड दिखाता है, तो फ़्रेमवर्क पूरे मॉडल को सीपीयू पर चलाता है.

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

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

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

साफ़-सफ़ाई सेवा

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

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

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

यह फ़्रेमवर्क, वेंडर की ओर से तय की गई कार्रवाइयों को छोड़कर, 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 में (अगर कोई स्ट्रीम नहीं दी गई है) किया जाता है.

सत्यापन

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

NNAPI के लिए, CTS और VTS में सटीकता से जुड़ी ये ज़रूरी शर्तें हैं:

  • फ़्लोटिंग-पॉइंट: 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 या इससे ज़्यादा वर्शन वाले ड्राइवर के लिए, अगर नतीजे सटीक होने की शर्त पूरी नहीं करते हैं, तो सीटीएस गड़बड़ी की रिपोर्ट करता है. साथ ही, डीबग करने के लिए, /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 मशीन लर्निंग टेस्ट सुइट (एमएलटीएस), 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/ देखें.