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

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

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

Android, सेवाओं को AID (Android यूआईडी) का इस्तेमाल करके, कॉल करने वाले अलग-अलग ऐप्लिकेशन के बीच अंतर करने में मदद करता है. HIDL में ::android::hardware::IPCThreadState::getCallingUid तरीके से, कॉलिंग ऐप्लिकेशन के यूआईडी को पाने के लिए पहले से ही प्रोसेस मौजूद हैं. AID की सूची, 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/) भी शामिल करता है, ताकि यह पक्का किया जा सके कि ड्राइवर ने आखिरी तारीख को सही तरीके से हैंडल किया है.