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

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

Validation

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