পরিষেবার কোয়ালিটি

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-এ কলিং অ্যাপের UID পাওয়ার জন্য বিল্ট-ইন মেকানিজম আছে, যা ::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 VTS টেস্টে (VtsHalNeuralnetworksV1_3Target) পরিষেবার কার্যকারিতার কোয়ালিটি টেস্ট করা হয়। এর মধ্যে যাচাইকরণের জন্য টেস্টের একটি সেট অন্তর্ভুক্ত থাকে (TestGenerated/ValidationTest#Test/) যাতে ড্রাইভার ভুল অগ্রাধিকার বাতিল করে কিনা তা নিশ্চিত করা যায় এবং DeadlineTest (TestGenerated/DeadlineTest#Test/) নামে টেস্টের একটি সেট অন্তর্ভুক্ত থাকে যাতে ড্রাইভার ডেডলাইন সঠিকভাবে ম্যানেজ করে কিনা তা নিশ্চিত করা যায়।