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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

प्राथमिकता

Android 11 या इसके बाद के वर्शन के लिए, NN HAL 1.3 में मॉडल प्राथमिकता के साथ तैयार किए जाते हैं. यह प्राथमिकता, उसी ऐप्लिकेशन के मालिकाना हक वाले दूसरे तैयार मॉडल के हिसाब से तय की जाती है. ज़्यादा प्राथमिकता वाले एक्सीक्यूशन, कम प्राथमिकता वाले एक्सीक्यूशन की तुलना में ज़्यादा कंप्यूट संसाधनों का इस्तेमाल कर सकते हैं. साथ ही, कम प्राथमिकता वाले एक्सीक्यूशन को रोक सकते हैं या उन्हें कम प्राथमिकता दे सकते हैं.

NN HAL 1.3 कॉल में, Priority को साफ़ तौर पर आर्ग्युमेंट के तौर पर शामिल किया गया है, जिसका नाम IDevice::prepareModel_1_3 है. ध्यान दें कि IDevice::prepareModelFromCache_1_3 कैश मेमोरी के आर्ग्युमेंट में Priority को अपने-आप शामिल किया जाता है.

प्राथमिकताओं को पूरा करने के लिए कई रणनीतियां अपनाई जा सकती हैं. ये रणनीतियां, ड्राइवर और ऐक्सेलरेटर की क्षमताओं पर निर्भर करती हैं. यहां कुछ रणनीतियां दी गई हैं:

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

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

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

Android, कॉल करने के लिए इस्तेमाल किए जाने वाले अलग-अलग ऐप्लिकेशन के बीच अंतर करने की सुविधा देता है. इसके लिए, यह AID (Android UID) का इस्तेमाल करता है. HIDL में, ::android::hardware::IPCThreadState::getCallingUid मेथड का इस्तेमाल करके, कॉल करने वाले ऐप्लिकेशन का यूआईडी पाने के लिए, पहले से मौजूद तरीके हैं. एआईडी की सूची, libcutils/include/cutils/android_filesystem_config.h में देखी जा सकती है.

आखिरी तारीखें

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

NN HAL 1.3 के ऐसे कॉल जिनमें OptionalTimePoint की समयसीमाएं, आर्ग्युमेंट के तौर पर शामिल होती हैं:

• IDevice::prepareModel_1_3
• IDevice::prepareModelFromCache_1_3
• IPreparedModel::execute_1_3
• IPreparedModel::executeSynchronously_1_3
• IPreparedModel::executeFenced

ऊपर बताए गए हर तरीके के लिए, समयसीमा की सुविधा को लागू करने का रेफ़रंस देखने के लिए, frameworks/ml/nn/driver/sample/SampleDriver.cpp पर NNAPI सैंपल ड्राइवर देखें.

गड़बड़ी के कोड

Android 11 में, NN HAL 1.3 में गड़बड़ी के कोड की चार वैल्यू शामिल की गई हैं, ताकि गड़बड़ी की रिपोर्टिंग को बेहतर बनाया जा सके. इससे ड्राइवर अपनी स्थिति के बारे में बेहतर तरीके से बता पाएंगे और ऐप्लिकेशन आसानी से ठीक हो पाएंगे. ये ErrorStatus में गड़बड़ी कोड की वैल्यू हैं.

• MISSED_DEADLINE_TRANSIENT
• MISSED_DEADLINE_PERSISTENT
• RESOURCE_EXHAUSTED_TRANSIENT
• RESOURCE_EXHAUSTED_PERSISTENT

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

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

पुष्टि करें

सेवा की क्वालिटी की जांच, NNAPI VTS टेस्ट (VtsHalNeuralnetworksV1_3Target) में की जाती है. इसमें पुष्टि करने के लिए टेस्ट का एक सेट (TestGenerated/ValidationTest#Test/) शामिल होता है, ताकि यह पक्का किया जा सके कि ड्राइवर अमान्य प्राथमिकताओं को अस्वीकार करता है. साथ ही, इसमें DeadlineTest (TestGenerated/DeadlineTest#Test/) नाम का एक टेस्ट सेट भी शामिल होता है, ताकि यह पक्का किया जा सके कि ड्राइवर समयसीमा को सही तरीके से मैनेज करता है.