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

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

प्राथमिकता

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 यूआईडी) का इस्तेमाल करके, कॉल करने वाले अलग-अलग ऐप्लिकेशन के बीच अंतर करने में मदद करता है. HIDL में, कॉल करने वाले ऐप्लिकेशन का UID पाने के लिए, ::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 वीटीएस टेस्ट (VtsHalNeuralnetworksV1_3Target) में सेवा की काम करने की क्षमता की जांच की जाती है. इसमें पुष्टि करने के लिए जांच (TestGenerated/ValidationTest#Test/) का एक सेट शामिल है, ताकि यह पक्का किया जा सके कि ड्राइवर अमान्य प्राथमिकताओं को अस्वीकार करता है. साथ ही, जांच का एक सेट DeadlineTest (TestGenerated/DeadlineTest#Test/) भी शामिल करता है, ताकि यह पक्का किया जा सके कि ड्राइवर ने आखिरी तारीख को सही तरीके से हैंडल किया है.