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

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