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

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

न्यूरल नेटवर्क एपीआई के बारे में ज़्यादा जानकारी के लिए, न्यूरल नेटवर्क एपीआई देखें.

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

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

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

पहली इमेज. न्यूरल नेटवर्क फ़्लो

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

शुरू करने पर, फ़्रेमवर्क 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 मशीन लर्निंग टेस्ट सुइट देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• हैंग का पता लगाना: अगर किसी जांच के दौरान NNAPI क्लाइंट हैंग हो जाता है, तो जांच HANG की वजह से फ़ेल हो जाती है और टेस्ट सुइट अगले टेस्ट पर चला जाता है.
• NNAPI क्लाइंट क्रैश का पता लगाना: टेस्ट, क्लाइंट क्रैश होने से बचे रहते हैं और टेस्ट सफल नहीं होने की वजह CRASH है.
• ड्राइवर क्रैश का पता लगाना: टेस्ट से ड्राइवर क्रैश का पता चल सकता है, जिसकी वजह से 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 देखें.

न्यूरल नेटवर्क के HAL वर्शन

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

• एनसीएचडब्ल्यू मेमोरी लेआउट के लिए सहायता
• सॉफ़्टमैक्स और नॉर्मलाइज़ेशन ऑपरेशन में, रैंक 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

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