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

अब काम नहीं करता: Android 15 से, NNAPI (NDK API) का इस्तेमाल नहीं किया जा सकता. नेरल नेटवर्क एचएएल इंटरफ़ेस का इस्तेमाल करना जारी रहेगा.

ज़्यादा जानकारी के लिए, NNAPI माइग्रेशन गाइड देखें.

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

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

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

ध्यान दें: इस पेज पर, AOSP में मौजूद Neural Networks HAL के वर्शन 1.3 के बारे में बताया गया है. अगर किसी दूसरे वर्शन पर ड्राइवर लागू किया जा रहा है, तो Neural Networks HAL के उस वर्शन को देखें.

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

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

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

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

ध्यान दें: HAL लेयर में सिंक्रोनस तरीके से प्रोग्राम चलाने के लिए, NDK लेयर में सिंक्रोनस तरीके से प्रोग्राम चलाने की ज़रूरत नहीं होती.

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

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

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

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

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

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 फ़ाइल में, उपयोगिता फ़ंक्शन होते हैं. इनकी मदद से, यह पुष्टि की जाती है कि एचएएल वर्शन के स्पेसिफ़िकेशन के मुताबिक, एनएन एचएएल ऑब्जेक्ट मान्य है या नहीं.

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

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

• फ़्लोटिंग-पॉइंट: 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 को छोड़कर, जो तीन से ज़्यादा है)

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

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

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

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

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

सुरक्षा

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

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

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

Android मशीन लर्निंग टेस्ट सुइट (एमएलटीएस), एक NNAPI बेंचमार्क है. इसे वेंडर डिवाइसों पर असली मॉडल की सटीकता की पुष्टि करने के लिए, सीटीएस और वीटीएस में शामिल किया गया है. जांच के लिए, इंतज़ार का समय और सटीक होने का आकलन किया जाता है. साथ ही, एक ही मॉडल और डेटासेट के लिए, सीपीयू पर चल रहे 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 आर्कटिक सेट के छोटे सबसेट के साथ काम करता है.
• अपने-आप बोली पहचानने की सुविधा के लिए, LSTM पर आधारित ऑडियो मॉडल. इसे LibriSpeech डेटासेट के छोटे सबसेट के साथ चलाया गया.

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

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

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

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

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

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

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

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

एमएलटीएस का इस्तेमाल करना

एमएलटीएस का इस्तेमाल करने के लिए:

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

Android 8.1

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