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

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

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

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

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

फ़्रेमवर्क और ड्राइवर के बीच इंटरफ़ेस के सामान्य फ़्लो को पहली इमेज में दिखाया गया है.

न्यूरल नेटवर्क फ़्लो

पहला डायग्राम. न्यूरल नेटवर्क फ़्लो

प्रोसेस शुरू करना

शुरू करते समय, फ़्रेमवर्क IDevice::getCapabilities_1_3 का इस्तेमाल करके ड्राइवर से क्वेरी करता है और इसकी क्षमताओं के बारे में बताता है. @1.3::Capabilities स्ट्रक्चर में सभी तरह का डेटा शामिल होता है. साथ ही, यह वेक्टर का इस्तेमाल करके ऐसी परफ़ॉर्मेंस को दिखाता है जो सुकून नहीं देता.

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

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

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

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

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

कंपाइलेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अपलोड करने का समय

Android 10 में, अगर ऐप्लिकेशन ने कंपाइलेशन प्रोसेस के दौरान इस्तेमाल करने के लिए एक ही डिवाइस तय किया है, तो वह एक्ज़ीक्यूशन का समय पूछ सकता है. ज़्यादा जानकारी के लिए, MeasureTiming और डिवाइस खोजना और असाइनमेंट देखें. इस मामले में, किसी अनुरोध पर कार्रवाई करते समय, NN HAL 1.2 ड्राइवर को एक्ज़ीक्यूशन का कुल समय मापना चाहिए या UINT64_MAX (यह बताने के लिए कि वह अवधि उपलब्ध नहीं है) रिपोर्ट करनी होगी. प्रोग्राम चलाने की अवधि मापने की वजह से, ड्राइवर को परफ़ॉर्मेंस पर लगने वाले किसी भी जुर्माने को कम करना चाहिए.

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

  • डिवाइस पर एक्ज़ीक्यूट होने में लगने वाला समय: इसमें ड्राइवर का जो समय, होस्ट प्रोसेसर पर चलता है उसका एक्ज़ीक्यूशन समय शामिल नहीं होता.
  • ड्राइवर के चलने का समय: इसमें डिवाइस पर एक्ज़ीक्यूशन का समय शामिल होता है.

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

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

फ़ेंस्ड एक्ज़ीक्यूशन

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

क्लीनअप करें

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

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

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

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

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

यूटिलिटी फ़ंक्शन

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

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

  • वीलॉगिंग: VLOG, Android के LOG के आस-पास मौजूद एक रैपर मैक्रो है जो मैसेज को सिर्फ़ तब लॉग करता है, जब debug.nn.vlog प्रॉपर्टी में सही टैग सेट किया गया हो. VLOG पर कॉल करने से पहले, initVLogMask() को कॉल किया जाना चाहिए. VLOG_IS_ON मैक्रो का इस्तेमाल करके यह पता लगाया जा सकता है कि फ़िलहाल VLOG चालू है या नहीं. इससे, ज़रूरत न होने पर लॉग इन करने वाले मुश्किल कोड को स्किप किया जा सकता है. प्रॉपर्टी की वैल्यू इनमें से कोई एक होनी चाहिए:

    • एक खाली स्ट्रिंग, जिससे पता चलता है कि डेटा को लॉग करने की ज़रूरत नहीं है.
    • 1 या all टोकन, जिससे पता चलता है कि अब आपको सभी डेटा लॉग करने की ज़रूरत है.
    • टैग की सूची, जिसे स्पेस, कॉमा या कोलन से अलग किया जाता है. इससे पता चलता है कि किस तरह की लॉगिंग की जानी है. टैग ये हैं: compilation, cpuexe, driver, execution, manager, और model.

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

  • convertToV1_*: यह फ़ंक्शन, किसी NN HAL ऑब्जेक्ट को एक वर्शन से दूसरे वर्शन में बदलता है. अगर कन्वर्ज़न की वजह से जानकारी का नुकसान होता है, तो चेतावनी लॉग की जाती है. इसका मतलब है कि अगर टाइप का नया वर्शन, वैल्यू को पूरी तरह से नहीं दिखा पाता है, तो चेतावनी लॉग की जाती है.

  • क्षमताएं: nonExtensionOperandPerformance और update फ़ंक्शन, Capabilities::operandPerformance फ़ील्ड बनाने के लिए इस्तेमाल किए जा सकते हैं.

  • इस तरह की प्रॉपर्टी की क्वेरी की जा रही है: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData, nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

frameworks/ml/nn/common/include/ValidateHal.h फ़ाइल में यूटिलिटी फ़ंक्शन मौजूद होते हैं. इनकी मदद से, यह पुष्टि की जाती है कि NN HAL ऑब्जेक्ट, एचएएल वर्शन की दी गई शर्तों के मुताबिक मान्य है.

  • validate*: अगर NN HAL ऑब्जेक्ट, एचएएल वर्शन की दी गई जानकारी के मुताबिक मान्य है, तो यह true दिखाता है. OEM के टाइप और एक्सटेंशन के टाइप की पुष्टि नहीं की गई है. उदाहरण के लिए, अगर मॉडल में कोई ऐसा ऑपरेशन शामिल है जो किसी ऐसे ऑपरेंड इंडेक्स का रेफ़रंस देता है जो मौजूद नहीं है या कोई ऐसी कार्रवाई है जो एचएएल वर्शन पर काम नहीं करती, तो validateModel, false वैल्यू दिखाता है.

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

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

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

पुष्टि करें

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

एनएनएपीआई के लिए सीटीएस और वीटीएस में सटीक होने से जुड़ी ज़रूरी शर्तें यहां दी गई हैं:

  • फ़्लोटिंग-पॉइंट: abs(उम्मीद - असल) <= atol + rtol * abs(अनुमानित); जहां:

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

  • संख्या में: एक के बाद एक (mobilenet_quantized को छोड़कर, जो तीन के आधार पर अलग-अलग है)

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

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

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

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

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

सुरक्षा

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

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

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

Android मशीन लर्निंग टेस्ट सुइट (एमएलटीएस), एक एनएनएपीआई बेंचमार्क है. यह सीटीएस और वीटीएस में शामिल है. इससे वेंडर डिवाइसों पर मौजूद असली मॉडल के सटीक होने की पुष्टि की जाती है. मानदंड, इंतज़ार के समय और सटीक होने का आकलन करता है. साथ ही, एक जैसे मॉडल और डेटासेट के लिए, सीपीयू पर चल रहे TF Lite का इस्तेमाल करके, ड्राइवर के नतीजों की तुलना उसके नतीजों से करता है. इससे यह पक्का होता है कि ड्राइवर की सटीक जानकारी, सीपीयू रेफ़रंस को लागू करने से खराब नहीं है.

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

एओएसपी के दो प्रोजेक्ट में, NNAPI बेंचमार्क को देखा जा सकता है:

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

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

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

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

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

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

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

  • हैंग की पहचान: अगर जांच के दौरान 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 और न्यूरल नेटवर्क के एचएएल वर्शन में हुए बदलावों के बारे में बताया गया है.

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

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.
  • कोई ऐप्लिकेशन यह तय कर सकता है कि Model.relaxComputationFloat32toFloat16 को true पर सेट करके, 32-बिट फ़्लोट रेंज और/या प्रिसिज़न का इस्तेमाल करके 32-बिट फ़्लोट कंप्यूटेशन को चलाया जा सकता है. Capabilities स्ट्रक्चर में एक अतिरिक्त फ़ील्ड relaxedFloat32toFloat16Performance होता है. इससे ड्राइवर, फ़्रेमवर्क को अपनी परफ़ॉर्मेंस की जानकारी दे पाता है.

Android 8.1

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