Neural Networks API ড্রাইভার

এই পৃষ্ঠায় নিউরাল নেটওয়ার্ক API (NNAPI) ড্রাইভার কীভাবে প্রয়োগ করতে হয় তার ওভারভিউ দেওয়া আছে। আরও বিবরণের জন্য, HAL ডেফিনিশন ফাইলের মধ্যে hardware/interfaces/neuralnetworks দেখুন। একটি স্যাম্পেল ড্রাইভার প্রয়োগ frameworks/ml/nn/driver/sample-এ আছে।

Neural Networks API সম্পর্কে আরও জানতে, Neural Networks API দেখুন।

Neural Networks HAL

নিউরল নেটওয়ার্ক (NN) HAL, বিভিন্ন ডিভাইসের অ্যাবস্ট্রাকশনকে সংজ্ঞায়িত করে, যেমন গ্রাফিক্স প্রসেসিং ইউনিট (GPU) ও ডিজিটাল সিগন্যাল প্রসেসর (DSP), যেগুলি কোনও প্রোডাক্টে (যেমন, ফোন বা ট্যাবলেট) থাকে। এইসব ডিভাইসের ড্রাইভারকে অবশ্যই NN HAL-এর সাথে মানানসই হতে হবে। HAL definition ফাইলে hardware/interfaces/neuralnetworks ইন্টারফেস উল্লেখ করা আছে।

ফ্রেমওয়ার্ক ও ড্রাইভারের মধ্যে ইন্টারফেসের সাধারণ ফ্লো চিত্র ১-এ দেখানো হয়েছে।

ছবি ১. নিউরাল নেটওয়ার্ক ফ্লো

ইনিশিয়ালাইজেশন

শুরু করার সময়, ফ্রেমওয়ার্ক IDevice::getCapabilities_1_3 ব্যবহার করে ড্রাইভারের ক্ষমতা সম্পর্কে কোয়েরি করে। @1.3::Capabilities স্ট্রাকচারে সব ধরনের ডেটা অন্তর্ভুক্ত থাকে এবং এটি ভেক্টরের মাধ্যমে নন-রিলাক্সড পারফর্ম্যান্স দেখায়।

উপলভ্য ডিভাইসে কীভাবে কম্পিউটেশন বরাদ্দ করা হবে তা নির্ধারণ করতে, ফ্রেমওয়ার্কটি প্রতিটি ড্রাইভার কত দ্রুত এবং কত বিদ্যুৎ সাশ্রয়ীভাবে একটি এক্সিকিউশন করতে পারে তা বোঝার জন্য ক্ষমতা ব্যবহার করে। এই তথ্য প্রদান করতে, রেফারেন্স ওয়ার্কলোডের এক্সিকিউশনের উপর ভিত্তি করে ড্রাইভারকে স্ট্যান্ডার্ড পারফর্ম্যান্স নম্বর প্রদান করতে হবে।

ড্রাইভার IDevice::getCapabilities_1_3-এর উত্তরে যে ভ্যালু রিটার্ন করে তা নির্ধারণ করতে, সংশ্লিষ্ট ডেটা ধরনের পারফর্ম্যান্স পরিমাপ করতে NNAPI বেঞ্চমার্ক অ্যাপ ব্যবহার করুন। ৩২-বিট ফ্লোটিং পয়েন্ট ভ্যালুর জন্য পারফর্ম্যান্স পরিমাপ করতে MobileNet v1 ও v2, asr_float এবং tts_float মডেল সাজেস্ট করা হয় এবং ৮-বিট কোয়ান্টাইজড ভ্যালুর জন্য MobileNet v1 ও v2 কোয়ান্টাইজড মডেল সাজেস্ট করা হয়। আরও তথ্যের জন্য, Android মেশিন লার্নিং টেস্ট স্যুট দেখুন।

Android 9 ও তার আগের ভার্সনে, Capabilities স্ট্রাকচারে শুধুমাত্র ফ্লোটিং পয়েন্ট ও কোয়ান্টাইজড টেনসর সংক্রান্ত ড্রাইভার পারফর্ম্যান্সের তথ্য থাকে এবং এতে স্ক্যালার ডেটা টাইপ থাকে না।

শুরু করার প্রসেসের অংশ হিসেবে, ফ্রেমওয়ার্ক আরও তথ্য কোয়েরি করতে পারে, IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions, এবং IDevice::getNumberOfCacheFilesNeeded ব্যবহার করে।

প্রোডাক্ট রিবুট করার সময়, ফ্রেমওয়ার্ক আশা করে যে এই বিভাগে বর্ণিত সব কোয়েরি যেন কোনও নির্দিষ্ট ড্রাইভারের জন্য সবসময় একই ভ্যালু রিপোর্ট করে। অন্যথায়, সেই ড্রাইভার ব্যবহার করা অ্যাপ কম পারফর্ম করতে পারে বা ভুল আচরণ করতে পারে।

সংকলন

কোনও অ্যাপ থেকে অনুরোধ পেলে, ফ্রেমওয়ার্ক কোন ডিভাইস ব্যবহার করতে হবে তা নির্ধারণ করে। Android 10-এ, ফ্রেমওয়ার্ক যে ডিভাইস বেছে নেয়, অ্যাপ তা খুঁজে বের করতে ও নির্দিষ্ট করতে পারে। আরও তথ্যের জন্য, ডিভাইস ডিসকভারি ও অ্যাসাইনমেন্ট দেখুন।

মডেল কম্পাইল করার সময়, ফ্রেমওয়ার্ক IDevice::getSupportedOperations_1_3 কল করে প্রতিটি সম্ভাব্য ড্রাইভারকে মডেল পাঠায়। প্রতিটি ড্রাইভার বুলিয়ান অ্যারে রিটার্ন করে যা মডেলের কোন কোন অপারেশন কাজ করে তা নির্দেশ করে। ড্রাইভার নির্ধারণ করতে পারে যে এটি বিভিন্ন কারণে প্রদত্ত অপারেশনের ক্ষেত্রে কাজ করে না। যেমন:

• ড্রাইভারটি ডেটার ধরন সাপোর্ট করে না।
• ড্রাইভার শুধুমাত্র নির্দিষ্ট ইনপুট প্যারামিটার সহ অপারেশন সমর্থন করে। যেমন, কোনও ড্রাইভার ৩x৩ ও ৫x৫ কাজ করতে পারে, কিন্তু ৭x৭ কনভলিউশন অপারেশন কাজ নাও করতে পারে।
• ড্রাইভারের মেমরি সংক্রান্ত সীমাবদ্ধতা রয়েছে, যার ফলে এটি বড় গ্রাফ বা ইনপুট ম্যানেজ করতে পারে না।

কম্পাইলেশনের সময়, মডেলের ইনপুট, আউটপুট ও ইন্টার্নাল অপারেন্ড, OperandLifeTime-এ বর্ণিত, অজানা ডাইমেনশন বা র‍্যাঙ্ক থাকতে পারে। আরও তথ্যের জন্য, আউটপুট শেপ দেখুন।

ফ্রেমওয়ার্ক, বেছে নেওয়া প্রতিটি ড্রাইভারকে IDevice::prepareModel_1_3 কল করে মডেলের একটি সাবসেট এক্সিকিউট করার জন্য প্রস্তুত হতে নির্দেশ দেয়। তারপরে প্রতিটি ড্রাইভার তার সাবসেট কম্পাইল করে। যেমন, কোনও ড্রাইভার কোড জেনারেট করতে পারে বা ওয়েটের একটি নতুন করে সাজানো কপি তৈরি করতে পারে। মডেল কম্পাইল করা এবং অনুরোধ এক্সিকিউট করার মধ্যে অনেক বেশি সময় লাগতে পারে, তাই কম্পাইলেশনের সময় ডিভাইস মেমরির বড় অংশের মতো রিসোর্স অ্যাসাইন করা উচিত নয়।

সফল হলে, ড্রাইভার একটি @1.3::IPreparedModel হ্যান্ডেল রিটার্ন করে। ড্রাইভার যদি মডেলের সাবসেট তৈরি করার সময় একটি ব্যর্থতা কোড রিটার্ন করে, তাহলে ফ্রেমওয়ার্কটি CPU-তে সম্পূর্ণ মডেলটি চালায়।

কোনও অ্যাপ চালু হলে, কম্পাইলেশনের জন্য ব্যবহৃত সময় কমাতে, ড্রাইভার কম্পাইলেশন আর্টিফ্যাক্ট ক্যাশে করতে পারে। আরও তথ্যের জন্য, কম্পাইলেশন ক্যাশিং দেখুন।

এক্সিকিউশন

কোনও অ্যাপ ফ্রেমওয়ার্ককে কোনও অনুরোধ এক্সিকিউট করতে বললে, ফ্রেমওয়ার্ক প্রস্তুত করা মডেলের উপর সিঙ্ক্রোনাস এক্সিকিউশন পারফর্ম করতে ডিফল্ট হিসেবে IPreparedModel::executeSynchronously_1_3 HAL মেথড কল করে। এছাড়াও, কোনও অনুরোধ execute_1_3 পদ্ধতি, executeFenced পদ্ধতি (ফেন্সড এক্সিকিউশন দেখুন) ব্যবহার করে অ্যাসিঙ্ক্রোনাসভাবে এক্সিকিউট করা যেতে পারে অথবা বার্স্ট এক্সিকিউশন ব্যবহার করে এক্সিকিউট করা যেতে পারে।

সিঙ্ক্রোনাস এক্সিকিউশন কল পারফর্ম্যান্স উন্নত করে এবং অ্যাসিঙ্ক্রোনাস কলের তুলনায় থ্রেডিং ওভারহেড কমায় কারণ এক্সিকিউশন সম্পূর্ণ হওয়ার পরেই কন্ট্রোল অ্যাপ প্রসেসে ফেরত দেওয়া হয়। এর অর্থ হল, ড্রাইভারের কোনও আলাদা মেকানিজমের প্রয়োজন নেই যা অ্যাপ প্রসেসকে জানাবে যে এক্সিকিউশন সম্পূর্ণ হয়েছে।

অ্যাসিঙ্ক্রোনাস execute_1_3 পদ্ধতিতে, এক্সিকিউশন শুরু হওয়ার পরে কন্ট্রোল অ্যাপ প্রসেসে ফিরে আসে এবং এক্সিকিউশন সম্পূর্ণ হলে ড্রাইভারকে ফ্রেমওয়ার্ককে জানাতে হবে, এর জন্য @1.3::IExecutionCallback ব্যবহার করতে হবে।

execute পদ্ধতিতে পাস করা Request প্যারামিটার, এক্সিকিউশনের জন্য ব্যবহৃত ইনপুট ও আউটপুট অপারেন্ডের তালিকা তৈরি করে। যে মেমোরিতে অপার‍্যান্ড ডেটা স্টোর করা হয়, সেটিকে অবশ্যই রো-মেজর অর্ডারে ব্যবহার করতে হবে, যেখানে প্রথম ডাইমেনশন সবচেয়ে ধীরে ধীরে ইটারেট হয় এবং কোনও সারির শেষে কোনও প্যাডিং থাকে না। অপারেন্ডের ধরন সম্পর্কে আরও তথ্য পেতে, অপারেন্ড দেখুন।

NN HAL 1.2 বা এর পরের যেকোনও ভার্সনের ড্রাইভারের জন্য, কোনও অনুরোধ সম্পূর্ণ হলে, ফ্রেমওয়ার্কে সমস্যার স্ট্যাটাস, আউটপুট শেপ এবং টাইমিং সংক্রান্ত তথ্য ফেরত পাঠানো হয়। এক্সিকিউশনের সময়, মডেলের আউটপুট বা ইন্টার্নাল অপারেন্ডের এক বা একাধিক অজানা ডাইমেনশন বা অজানা র‍্যাঙ্ক থাকতে পারে। অন্তত একটি আউটপুট অপারেন্ডের অজানা ডাইমেনশন বা র‍্যাঙ্ক থাকলে, ড্রাইভারকে অবশ্যই ডাইনামিক সাইজের আউটপুট তথ্য রিটার্ন করতে হবে।

NN HAL 1.1 বা তার নিচের ভার্সনের ড্রাইভারের ক্ষেত্রে, অনুরোধ সম্পূর্ণ হলে শুধুমাত্র সমস্যার স্ট্যাটাস ফেরত পাঠানো হয়। সঠিকভাবে এক্সিকিউট করার জন্য ইনপুট ও আউটপুট অপারেন্ডের ডাইমেনশন সম্পূর্ণভাবে নির্দিষ্ট করতে হবে। ইন্টার্নাল অপারেন্ডের এক বা একাধিক অজানা ডাইমেনশন থাকতে পারে, তবে তাদের নির্দিষ্ট র‍্যাঙ্ক থাকতে হবে।

একাধিক ড্রাইভার জুড়ে থাকা ব্যবহারকারীর অনুরোধের জন্য, ফ্রেমওয়ার্ক মধ্যবর্তী মেমরি রিজার্ভ করা এবং প্রতিটি ড্রাইভারের কল সিকোয়েন্স করার জন্য দায়ী।

একই @1.3::IPreparedModel-এ সমান্তরালভাবে একাধিক অনুরোধ শুরু করা যেতে পারে। ড্রাইভার সমান্তরালভাবে অনুরোধগুলি কার্যকর করতে পারে বা কার্যকর করার প্রক্রিয়াটি সিরিয়ালাইজ করতে পারে।

ফ্রেমওয়ার্ক ড্রাইভারকে একাধিক প্রস্তুত মডেল রাখতে বলতে পারে। যেমন, মডেল m1 প্রস্তুত করো, m2 প্রস্তুত করো, m1-এ r1 অনুরোধ এক্সিকিউট করো, m2-এ r2 এক্সিকিউট করো, m1-এ r3 এক্সিকিউট করো, m2-এ r4 এক্সিকিউট করো, রিলিজ করো (পরিষ্কার করা-তে বর্ণিত) m1 এবং m2 রিলিজ করো।

প্রথমবার এক্সিকিউট করার সময় যাতে স্লো না হয়ে যায় এবং তার ফলে ব্যবহারকারীর অভিজ্ঞতা যাতে খারাপ না হয় (যেমন, প্রথম ফ্রেম স্টাটার), তার জন্য ড্রাইভারকে কম্পাইলেশন ফেজে বেশিরভাগ ইনিশিয়ালাইজেশন করতে হবে। প্রথমবার এক্সিকিউট করার সময় ইনিশিয়ালাইজেশন সেইসব অ্যাকশনে সীমিত থাকা উচিত যা আগে থেকে পারফর্ম করলে সিস্টেমের স্বাস্থ্যের উপর নেতিবাচক প্রভাব ফেলে, যেমন বড় অস্থায়ী বাফার রিজার্ভ করা বা ডিভাইসের ক্লক রেট বাড়ানো। যেসব ড্রাইভার শুধুমাত্র সীমিত সংখ্যক কনকারেন্ট মডেল প্রস্তুত করতে পারে, তাদের প্রথমবার এক্সিকিউট করার সময় ইনিশিয়ালাইজ করতে হতে পারে।

Android 10 বা তার পরের যেকোনও ভার্সনে, একই প্রিপেয়ার করা মডেল দিয়ে একাধিক এক্সিকিউশন দ্রুত পরপর এক্সিকিউট করা হলে, অ্যাপ ও ড্রাইভার প্রসেসের মধ্যে কমিউনিকেট করার জন্য ক্লায়েন্ট এক্সিকিউশন বার্স্ট অবজেক্ট ব্যবহার করার বিকল্প বেছে নিতে পারে। আরও তথ্যের জন্য, বার্স্ট এক্সিকিউশন ও দ্রুত মেসেজ কিউ দেখুন।

দ্রুত একের পর এক একাধিক এক্সিকিউশনের জন্য পারফর্ম্যান্স উন্নত করতে, ড্রাইভার অস্থায়ী বাফার ধরে রাখতে পারে বা ক্লক রেট বাড়াতে পারে। একটি নির্দিষ্ট সময় পরে কোনও নতুন অনুরোধ তৈরি না হলে রিসোর্স রিলিজ করার জন্য একটি ওয়াচডগ থ্রেড তৈরি করার পরামর্শ দেওয়া হয়।

আউটপুটের আকার

যেসব অনুরোধে এক বা একাধিক আউটপুট অপারেন্ডের সব ডাইমেনশন উল্লেখ করা থাকে না, সেগুলির ক্ষেত্রে ড্রাইভারকে অবশ্যই এক্সিকিউশনের পরে প্রতিটি আউটপুট অপারেন্ডের জন্য ডাইমেনশন তথ্য সহ আউটপুট আকারের একটি তালিকা প্রদান করতে হবে। ডাইমেনশন সম্পর্কে আরও জানতে, OutputShape দেখুন।

আউটপুট বাফারের সাইজ ছোট হওয়ার কারণে এক্সিকিউশন ব্যর্থ হলে, ড্রাইভারকে অবশ্যই আউটপুট শেপের তালিকায় কোন আউটপুট অপারেন্ডের বাফার সাইজ অপর্যাপ্ত তা উল্লেখ করতে হবে এবং অজানা ডাইমেনশনের জন্য শূন্য ব্যবহার করে যতটা সম্ভব ডাইমেনশনাল তথ্য রিপোর্ট করতে হবে।

টাইমিং

Android 10-এ, কোনও অ্যাপ এক্সিকিউশন টাইম চাইতে পারে যদি অ্যাপটি কম্পাইলেশন প্রসেসের সময় ব্যবহার করার জন্য একটি নির্দিষ্ট ডিভাইস উল্লেখ করে থাকে। আরও বিবরণের জন্য, MeasureTiming এবং ডিভাইস ডিসকভারি ও অ্যাসাইনমেন্ট দেখুন। এই ক্ষেত্রে, কোনও অনুরোধ কার্যকর করার সময়, NN HAL 1.2 ড্রাইভারকে অবশ্যই কার্যকর করার সময়কাল পরিমাপ করতে হবে অথবা UINT64_MAX (সময়কাল উপলভ্য নেই তা নির্দেশ করতে) রিপোর্ট করতে হবে। ড্রাইভারকে এক্সিকিউশন সময় পরিমাপ করার ফলে হওয়া পারফর্ম্যান্স পেনাল্টি কমাতে হবে।

ড্রাইভার Timing স্ট্রাকচারে মাইক্রোসেকেন্ডে নিম্নলিখিত সময়সীমা রিপোর্ট করে:

• ডিভাইসে এক্সিকিউশন টাইম: ড্রাইভারের এক্সিকিউশন টাইম অন্তর্ভুক্ত করে না, যা হোস্ট প্রসেসরে চলে।
• ড্রাইভারের এক্সিকিউশন টাইম: ডিভাইসে এক্সিকিউশন টাইম অন্তর্ভুক্ত।

এই সময়সীমার মধ্যে অবশ্যই সেই সময় অন্তর্ভুক্ত করতে হবে যখন এক্সিকিউশন সাসপেন্ড করা হয়, যেমন, যখন এক্সিকিউশন অন্য টাস্কের মাধ্যমে প্রি-এম্পট করা হয় অথবা যখন এটি কোনও রিসোর্স উপলভ্য হওয়ার জন্য অপেক্ষা করে।

ড্রাইভারকে যখন এক্সিকিউশন সময়সীমা পরিমাপ করতে বলা হয়নি অথবা যখন এক্সিকিউশন সংক্রান্ত সমস্যা হয়েছে, তখন ড্রাইভারকে অবশ্যই সময়সীমা UINT64_MAX হিসেবে রিপোর্ট করতে হবে। এমনকি ড্রাইভারকে এক্সিকিউশন সময়কাল পরিমাপ করতে বলা হলেও, এটি পরিবর্তে ডিভাইসে সময়, ড্রাইভারের সময় বা উভয়ের জন্য UINT64_MAX রিপোর্ট করতে পারে। ড্রাইভার যদি দুটি সময়সীমাকেই UINT64_MAX ছাড়া অন্য কোনও ভ্যালু হিসেবে রিপোর্ট করে, তাহলে ড্রাইভারের এক্সিকিউশন টাইম অবশ্যই ডিভাইসের টাইমের সমান বা তার বেশি হতে হবে।

ফেন্সড এক্সিকিউশন

Android 11-এ, NNAPI এক্সিকিউশনকে sync_fence হ্যান্ডেলের তালিকার জন্য অপেক্ষা করতে দেয় এবং বিকল্প হিসেবে একটি sync_fence অবজেক্ট ফিরিয়ে দেয়, যা এক্সিকিউশন সম্পূর্ণ হলে সিগন্যাল দেয়। এটি ছোট সিকোয়েন্স মডেল ও স্ট্রিমিং ব্যবহারের ক্ষেত্রে ওভারহেড কমায়। এছাড়াও, ফেন্সড এক্সিকিউশন অন্যান্য কম্পোনেন্টের সাথে আরও দক্ষ ইন্টারঅপারেবিলিটি প্রদান করে যা sync_fence-এর জন্য সিগন্যাল দিতে বা অপেক্ষা করতে পারে। sync_fence সম্পর্কে আরও তথ্যের জন্য, সিঙ্ক্রোনাইজেশন ফ্রেমওয়ার্ক দেখুন।

ফেন্সড এক্সিকিউশনে, ফ্রেমওয়ার্ক IPreparedModel::executeFenced মেথড কল করে, যাতে অপেক্ষা করার জন্য সিঙ্ক ফেন্সের ভেক্টর সহ একটি প্রস্তুত মডেলে ফেন্সড, অ্যাসিঙ্ক্রোনাস এক্সিকিউশন লঞ্চ করা যায়। কল রিটার্ন করার আগে অ্যাসিঙ্ক্রোনাস টাস্ক সম্পূর্ণ হয়ে গেলে, sync_fence-এর জন্য একটি খালি হ্যান্ডেল রিটার্ন করা যেতে পারে। ফ্রেমওয়ার্ককে সমস্যার স্ট্যাটাস ও সময়সীমা সংক্রান্ত তথ্য কোয়েরি করার অনুমতি দিতে, একটি IFencedExecutionCallback অবজেক্টও ফেরত দিতে হবে।

কোনও এক্সিকিউশন সম্পূর্ণ হওয়ার পরে, এক্সিকিউশনের সময়সীমা পরিমাপকারী নিম্নলিখিত দুটি টাইমিং ভ্যালু IFencedExecutionCallback::getExecutionInfo-এর মাধ্যমে কোয়েরি করা যেতে পারে।

• timingLaunched: executeFenced কল করা থেকে executeFenced রিটার্ন করা syncFence-এর সিগন্যাল দেওয়ার সময় পর্যন্ত।
• timingFenced: যে সময় থেকে এক্সিকিউশন অপেক্ষা করে এমন সব সিঙ্ক ফেন্স সিগন্যাল করা হয়, সেই সময় থেকে executeFenced সিগন্যাল রিটার্ন করা syncFence পর্যন্ত সময়সীমা।

কন্ট্রোল ফ্লো

Android 11 বা এর পরের যেকোনও ভার্সনে চলছে এমন ডিভাইসের ক্ষেত্রে, NNAPI -তে দুটি কন্ট্রোল ফ্লো অপারেশন, IF এবং WHILE অন্তর্ভুক্ত থাকে, যা আর্গুমেন্ট হিসেবে অন্যান্য মডেল নেয় এবং কন্ডিশনাল (IF) বা বারবার (WHILE) এক্সিকিউট করে। এটি কীভাবে ইমপ্লিমেন্ট করতে হয় সেই সম্পর্কে আরও জানতে, কন্ট্রোল ফ্লো দেখুন।

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

Android 11-এ, NNAPI-তে উন্নত কোয়ালিটি অফ সার্ভিস (QoS) অন্তর্ভুক্ত রয়েছে। এর মাধ্যমে কোনও অ্যাপ তার মডেলের আপেক্ষিক অগ্রাধিকার, কোনও মডেল প্রস্তুত করার জন্য প্রত্যাশিত সর্বাধিক সময় এবং কোনও এক্সিকিউশন সম্পূর্ণ করার জন্য প্রত্যাশিত সর্বাধিক সময় নির্দেশ করতে পারে। আরও তথ্যের জন্য, দেখুন পরিষেবার কোয়ালিটি।

মুছুন

কোনও অ্যাপ আগে থেকে তৈরি মডেল ব্যবহার করা শেষ করলে, ফ্রেমওয়ার্ক সেটির রেফারেন্স @1.3::IPreparedModel অবজেক্ট থেকে রিলিজ করে দেয়। IPreparedModel অবজেক্টের রেফারেন্স আর না থাকলে, এটি যে ড্রাইভার পরিষেবা তৈরি করেছে সেটি অটোমেটিক ধ্বংস করে দেয়। ড্রাইভারের ইমপ্লিমেন্টেশনে ডিস্ট্রাক্টর থাকাকালীন এই সময়ে মডেল-নির্দিষ্ট রিসোর্স রিক্লেইম করা যেতে পারে। ড্রাইভার পরিষেবা যদি চায় যে ক্লায়েন্টের আর প্রয়োজন না থাকলে IPreparedModel অবজেক্টটি অটোমেটিক ধ্বংস হয়ে যাক, তাহলে IPreparedeModel অবজেক্টটি IPreparedModelCallback::notify_1_3-এর মাধ্যমে ফেরত দেওয়ার পরে IPreparedModel অবজেক্টের কোনও রেফারেন্স রাখা চলবে না।

CPU-এর ব্যবহার

কম্পিউটেশন সেট-আপ করার জন্য ড্রাইভারদের সিপিইউ ব্যবহার করতে হবে। ড্রাইভারদের গ্রাফ কম্পিউটেশনের জন্য CPU ব্যবহার করা উচিত নয়, কারণ এটি ফ্রেমওয়ার্কের কাজ সঠিকভাবে অ্যাসাইন করার ক্ষমতাকে বাধা দেয়। ড্রাইভারকে ফ্রেমওয়ার্কে সেইসব পার্ট সম্পর্কে রিপোর্ট করতে হবে যেগুলি সেটি হ্যান্ডেল করতে পারে না এবং বাকি অংশ ফ্রেমওয়ার্ককে হ্যান্ডেল করতে দিতে হবে।

ফ্রেমওয়ার্ক, ভেন্ডর-নির্দিষ্ট অপারেশন ছাড়া সব NNAPI অপারেশনের জন্য CPU ইমপ্লিমেন্টেশন প্রদান করে। আরও তথ্যের জন্য, ভেন্ডর এক্সটেনশন দেখুন।

Android 10-এ চালু করা অপারেশন (API লেভেল ২৯) শুধুমাত্র CTS এবং VTS টেস্ট সঠিক কিনা তা যাচাই করার জন্য একটি রেফারেন্স CPU বাস্তবায়ন আছে। NNAPI CPU ইমপ্লিমেন্টেশনের পরিবর্তে মোবাইল মেশিন লার্নিং ফ্রেমওয়ার্কে অন্তর্ভুক্ত অপ্টিমাইজ করা ইমপ্লিমেন্টেশন ব্যবহার করা হয়।

ইউটিলিটি ফাংশন

NNAPI কোডবেসে ইউটিলিটি ফাংশন অন্তর্ভুক্ত থাকে যা ড্রাইভার পরিষেবা ব্যবহার করতে পারে।

frameworks/ml/nn/common/include/Utils.h ফাইলে বিভিন্ন ইউটিলিটি ফাংশন থাকে, যেমন লগিং এবং বিভিন্ন NN HAL ভার্সনের মধ্যে কনভার্ট করার জন্য ব্যবহৃত ফাংশন।

• VLogging: VLOG হল Android-এর LOG-এর একটি র‍্যাপার ম্যাক্রো যা শুধুমাত্র debug.nn.vlog প্রপার্টিতে উপযুক্ত ট্যাগ সেট করা থাকলে মেসেজ লগ করে। initVLogMask() VLOG-এ কল করার আগে কল করতে হবে। VLOG_IS_ON ম্যাক্রো ব্যবহার করে VLOG বর্তমানে চালু আছে কিনা তা চেক করা যায়। এর ফলে, প্রয়োজন না থাকলে জটিল লগিং কোড এড়িয়ে যাওয়া যায়। প্রপার্টির ভ্যালু অবশ্যই নিম্নলিখিতগুলির মধ্যে একটি হতে হবে:

  • একটি খালি স্ট্রিং, যা নির্দেশ করে যে কোনও লগিং করা হবে না।
  • 1 বা all টোকেন, যা নির্দেশ করে যে সব লগিং করতে হবে।
  • স্পেস, কমা বা কোলন দিয়ে আলাদা করা ট্যাগের তালিকা, কোন লগিং করতে হবে তা নির্দেশ করে। ট্যাগগুলি হল compilation, cpuexe, driver, execution, manager এবং model.

• compliantWithV1_*: কোনও NN HAL অবজেক্টকে তথ্য না হারিয়ে অন্য HAL ভার্সনের একই ধরনের অবজেক্টে কনভার্ট করা গেলে true রিটার্ন করে। যেমন, V1_2::Model-এ compliantWithV1_0 কল করলে, মডেলটিতে NN HAL 1.1 বা NN HAL 1.2-এ পরিচয় করিয়ে দেওয়া অপারেশন টাইপ থাকলে false রিটার্ন করে।

• convertToV1_*: NN HAL অবজেক্টকে একটি ভার্সন থেকে অন্য ভার্সনে কনভার্ট করে। কনভার্সনের ফলে তথ্য হারিয়ে গেলে (অর্থাৎ, যদি নতুন ভার্সনটি ভ্যালুকে সম্পূর্ণভাবে উপস্থাপন করতে না পারে) একটি সতর্কতা লগ করা হয়।

• ক্ষমতা: nonExtensionOperandPerformance এবং update ফাংশনগুলি Capabilities::operandPerformance ফিল্ড তৈরি করতে ব্যবহার করা যেতে পারে।

• এই ধরনের প্রপার্টি কোয়েরি করা: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData, nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

frameworks/ml/nn/common/include/ValidateHal.h ফাইলে ইউটিলিটি ফাংশন থাকে যা যাচাই করে যে NN HAL অবজেক্টটি তার HAL ভার্সনের স্পেসিফিকেশন অনুযায়ী সঠিক কিনা।

• validate*: NN HAL অবজেক্ট তার HAL ভার্সনের স্পেসিফিকেশন অনুযায়ী সঠিক হলে true রিটার্ন করে। OEM ধরন ও এক্সটেনশনের ধরন যাচাই করা হয় না। যেমন, যদি মডেলের মধ্যে এমন কোনও অপারেশন থাকে যা এমন একটি অপারেন্ড ইন্ডেক্সকে রেফার করে যা নেই অথবা এমন কোনও অপারেশন থাকে যা সেই HAL ভার্সনে কাজ করে না, তাহলে validateModel রিটার্ন false করে।

Neural Networks কোডে systracing সংক্রান্ত তথ্য যোগ করার প্রক্রিয়া সহজ করতে frameworks/ml/nn/common/include/Tracing.h ফাইলে ম্যাক্রো আছে। যেমন, স্যাম্পেল ড্রাইভার-এ NNTRACE_*ম্যাক্রো ইনভোকেশন দেখুন।

The frameworks/ml/nn/common/include/GraphDump.h ফাইলে ডিবাগিংয়ের উদ্দেশ্যে Model-এর কন্টেন্ট গ্রাফিক্যাল ফর্ম্যাটে ডাম্প করার জন্য একটি ইউটিলিটি ফাংশন রয়েছে।

• graphDump: নির্দিষ্ট স্ট্রিম (প্রদান করা হলে) বা logcat-এ (কোনও স্ট্রিম প্রদান করা না হলে) Graphviz (.dot) ফর্ম্যাটে মডেলের একটি উপস্থাপনা লেখে।

যাচাইকরণ

NNAPI-এর আপনার প্রয়োগ পরীক্ষা করতে, Android ফ্রেমওয়ার্কে অন্তর্ভুক্ত VTS ও CTS পরীক্ষা ব্যবহার করুন। VTS আপনার ড্রাইভারদের সরাসরি (ফ্রেমওয়ার্ক ব্যবহার না করে) এক্সারসাইজ করে, অন্যদিকে CTS ফ্রেমওয়ার্কের মাধ্যমে তাদের পরোক্ষভাবে এক্সারসাইজ করে। এগুলি প্রতিটি API পদ্ধতি পরীক্ষা করে এবং যাচাই করে যে ড্রাইভারের মাধ্যমে কাজ করা সমস্ত অপারেশন সঠিকভাবে কাজ করে এবং নির্ভুলতার প্রয়োজনীয়তা পূরণ করে এমন ফলাফল প্রদান করে।

NNAPI-এর জন্য CTS এবং VTS-এ নির্ভুলতার প্রয়োজনীয়তা নিম্নরূপ:

• ফ্লোটিং-পয়েন্ট: abs(expected - actual) <= atol + rtol  * abs(expected); যেখানে:

  • fp32-এর জন্য, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
  • fp16-এর জন্য, atol = rtol = 5.0f * 0.0009765625f

• কোয়ান্টাইজ করা: একটি করে কম (mobilenet_quantized ছাড়া, যেটি তিনটি করে কম)

• বুলিয়ান: সম্পূর্ণ ম্যাচ

NNAPI পরীক্ষা করার একটি উপায় হল, CTS-এর মাধ্যমে নির্দিষ্ট সিউডোর‍্যান্ডম গ্রাফ তৈরি করা যা NNAPI রেফারেন্স ইমপ্লিমেন্টেশনের সাথে প্রতিটি ড্রাইভারের এক্সিকিউশন ফলাফল পরীক্ষা ও তুলনা করতে ব্যবহার করা হয়। NN HAL 1.2 বা এর পরের যেকোনও ভার্সন সহ ড্রাইভারের ক্ষেত্রে, ফলাফল যদি নির্ভুলতার মানদণ্ড পূরণ না করে, তাহলে CTS একটি সমস্যা রিপোর্ট করে এবং /data/local/tmp-এর অধীনে ডিবাগ করার জন্য ব্যর্থ মডেলের একটি স্পেসিফিকেশন ফাইল ডাম্প করে। নির্ভুলতা সংক্রান্ত মানদণ্ড সম্পর্কে আরও জানতে, TestRandomGraph.cpp এবং TestHarness.h দেখুন।

ফাজ টেস্টিং

ফাজ টেস্টিংয়ের উদ্দেশ্য হল ক্র্যাশ, অ্যাসার্শন, মেমরি ভায়োলেশন বা অপ্রত্যাশিত ইনপুটের মতো কারণের জন্য পরীক্ষা করা কোডে সাধারণ অনির্দিষ্ট আচরণ খুঁজে বের করা। NNAPI ফাজ টেস্টিংয়ের জন্য, Android libFuzzer-এর উপর ভিত্তি করে টেস্ট ব্যবহার করে, যা ফাজিংয়ের ক্ষেত্রে দক্ষ কারণ এটি নতুন র‍্যান্ডম ইনপুট জেনারেট করার জন্য আগের টেস্ট কেসের লাইন কভারেজ ব্যবহার করে। যেমন, libFuzzer সেইসব টেস্ট কেস পছন্দ করে যেগুলি নতুন লাইনের কোডে রান করে। এর ফলে, সমস্যাযুক্ত কোড খুঁজে পেতে টেস্টের সময় অনেক কমে যায়।

আপনার ড্রাইভার ইমপ্লিমেন্টেশন যাচাই করার জন্য ফাজ টেস্টিং করতে, frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp আপনার ড্রাইভার কোড অন্তর্ভুক্ত করতে AOSP-তে পাওয়া libneuralnetworks_driver_fuzzer টেস্ট ইউটিলিটিতে পরিবর্তন করুন। NNAPI ফাজ টেস্টিং সম্পর্কে আরও তথ্য পেতে, frameworks/ml/nn/runtime/test/android_fuzzing/README.md দেখুন।

নিরাপত্তা

অ্যাপ প্রসেস সরাসরি ড্রাইভার প্রসেসের সাথে যোগাযোগ করে বলে, ড্রাইভারদের অবশ্যই তাদের পাওয়া কলের আর্গুমেন্ট যাচাই করতে হবে। এই ভ্যালিডেশন VTS যাচাই করেছে। যাচাইকরণ কোডটি frameworks/ml/nn/common/include/ValidateHal.h-এ আছে।

এছাড়াও, ড্রাইভারদের এটি নিশ্চিত করতে হবে যে একই ডিভাইস ব্যবহার করার সময় অ্যাপগুলি যেন অন্য অ্যাপের কাজে বাধা না দেয়।

Android মেশিন লার্নিং টেস্ট স্যুট

Android মেশিন লার্নিং টেস্ট স্যুট (MLTS) হল একটি NNAPI বেঞ্চমার্ক যা CTS এবং VTS-এ অন্তর্ভুক্ত করা হয়েছে যাতে ভেন্ডর ডিভাইসে আসল মডেলের নির্ভুলতা যাচাই করা যায়। এই বেঞ্চমার্ক লেটেন্সি ও নির্ভুলতা মূল্যায়ন করে এবং একই মডেল ও ডেটাসেটের জন্য CPU-তে রান করা TF Lite ব্যবহার করে পাওয়া ফলাফলের সাথে ড্রাইভারের ফলাফল তুলনা করে। এটি নিশ্চিত করে যে ড্রাইভারের নির্ভুলতা CPU রেফারেন্স ইমপ্লিমেন্টেশনের চেয়ে খারাপ নয়।

এছাড়াও, ড্রাইভারের লেটেন্সি ও নির্ভুলতা মূল্যায়ন করতে Android প্ল্যাটফর্ম ডেভেলপাররা MLTS ব্যবহার করেন।

AOSP-এর দুটি প্রোজেক্টে NNAPI বেঞ্চমার্ক পাওয়া যাবে:

• platform/test/mlts/benchmark (বেঞ্চমার্ক অ্যাপ)
• platform/test/mlts/models (মডেল ও ডেটাসেট)

মডেল ও ডেটাসেট

NNAPI বেঞ্চমার্ক নিম্নলিখিত মডেল ও ডেটাসেট ব্যবহার করে।

• MobileNetV1 float এবং u8 কোয়ান্টাইজড, বিভিন্ন সাইজে, Open Images Dataset v4-এর ছোট সাবসেটের (১৫০০ ছবি) বিরুদ্ধে রান করানো হয়েছে।
• MobileNetV2 float এবং u8 কোয়ান্টাইজড, বিভিন্ন সাইজে, Open Images Dataset v4-এর একটি ছোট সাবসেটের (১৫০০ ছবি) বিরুদ্ধে রান করানো হয়েছে।
• টেক্সট-টু-স্পিচের জন্য লং শর্ট-টার্ম মেমরি (LSTM) ভিত্তিক অ্যাকোস্টিক মডেল, CMU Arctic সেটের একটি ছোট সাবসেটের বিরুদ্ধে রান করে।
• অটোমেটিক স্পিচ রিকগনিশনের জন্য LSTM-ভিত্তিক অ্যাকোস্টিক মডেল, যা LibriSpeech ডেটাসেটের একটি ছোট সাবসেটের বিরুদ্ধে রান করে।

আরও তথ্যের জন্য, platform/test/mlts/models দেখুন।

স্ট্রেস টেস্টিং

Android মেশিন লার্নিং টেস্ট সুইটে ক্র্যাশ টেস্টের একটি সিরিজ অন্তর্ভুক্ত থাকে যা ভারী ব্যবহারের পরিস্থিতিতে বা ক্লায়েন্টদের আচরণের কর্নার কেসে ড্রাইভারদের স্থিতিস্থাপকতা যাচাই করে।

সব ক্র্যাশ টেস্টে নিম্নলিখিত ফিচারগুলি প্রদান করা হয়:

• হ্যাং শনাক্তকরণ: টেস্ট চলাকালীন NNAPI ক্লায়েন্ট হ্যাং করলে, HANG কারণের জন্য টেস্ট ব্যর্থ হয় এবং টেস্ট স্যুট পরবর্তী টেস্টে চলে যায়।
• NNAPI ক্লায়েন্ট ক্র্যাশ শনাক্তকরণ: ক্লায়েন্ট ক্র্যাশ হওয়ার পরেও টেস্ট চলতে থাকে এবং CRASH কারণের জন্য টেস্ট ব্যর্থ হয়।
• ড্রাইভার ক্র্যাশ শনাক্তকরণ: পরীক্ষাগুলি ড্রাইভার ক্র্যাশ শনাক্ত করতে পারে যা NNAPI কলে ব্যর্থতার কারণ হয়। মনে রাখবেন, ড্রাইভার প্রসেসে ক্র্যাশ হতে পারে যা NNAPI ব্যর্থতার কারণ হয় না এবং পরীক্ষার ব্যর্থতার কারণ হয় না। এই ধরনের ব্যর্থতা কভার করতে, ড্রাইভার-সম্পর্কিত ত্রুটি বা ক্র্যাশের জন্য সিস্টেম লগে tail কমান্ড চালানোর পরামর্শ দেওয়া হয়।
• উপলভ্য সব অ্যাক্সিলারেটরের টার্গেটিং: উপলভ্য সব ড্রাইভারের বিরুদ্ধে টেস্ট চালানো হয়।

সব ক্র্যাশ টেস্টের নিম্নলিখিত চারটি সম্ভাব্য ফলাফল আছে:

• SUCCESS: কোনও সমস্যা ছাড়াই এক্সিকিউশন সম্পূর্ণ হয়েছে।
• FAILURE: এক্সিকিউট করা যায়নি। সাধারণত, কোনও মডেল পরীক্ষা করার সময় কোনও সমস্যা হলে এটি হয়। এর অর্থ হল, ড্রাইভার মডেলটি কম্পাইল বা এক্সিকিউট করতে পারেনি।
• HANG: টেস্ট প্রসেস আর কাজ করছে না।
• CRASH: টেস্ট প্রসেস ক্র্যাশ করেছে।

স্ট্রেস টেস্টিং ও ক্র্যাশ টেস্টের সম্পূর্ণ তালিকা সম্পর্কে আরও জানতে, platform/test/mlts/benchmark/README.txt দেখুন।

MLTS ব্যবহার করা

MLTS ব্যবহার করতে:

1. আপনার ওয়ার্কস্টেশনে একটি টার্গেট ডিভাইস কানেক্ট করুন এবং নিশ্চিত করুন যে এটি adb-এর মাধ্যমে অ্যাক্সেস করা যাচ্ছে। একাধিক ডিভাইস কানেক্ট করা থাকলে, টার্গেট ডিভাইস ANDROID_SERIAL এনভায়রনমেন্ট ভেরিয়েবল এক্সপোর্ট করুন।

2. Android টপ-লেভেল সোর্স ডিরেক্টরিতে cd।

   source build/envsetup.sh
   lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
   ./test/mlts/benchmark/build_and_run_benchmark.sh
   

   বেঞ্চমার্ক রান শেষ হলে, ফলাফল HTML পৃষ্ঠা হিসেবে দেখানো হয় এবং xdg-open-এ পাঠানো হয়।

আরও তথ্যের জন্য, platform/test/mlts/benchmark/README.txt দেখুন।

Neural Networks HAL ভার্সন

এই বিভাগে Android এবং Neural Networks HAL ভার্সনে করা পরিবর্তনগুলি বর্ণনা করা হয়েছে।

Android 11

Android 11 NN HAL 1.3 নিয়ে এসেছে, যার মধ্যে নিচে উল্লেখ করা উল্লেখযোগ্য পরিবর্তনগুলি অন্তর্ভুক্ত।

• NNAPI-তে সাইন করা ৮-বিট কোয়ান্টাইজেশনের জন্য সহায়তা। TENSOR_QUANT8_ASYMM_SIGNED অপারেন্ডের ধরন যোগ করে। NN HAL 1.3 সহ ড্রাইভারদের অবশ্যই আনসাইনড কোয়ান্টাইজেশন সহ অপারেশন কাজ করতে হবে এবং সেইসব অপারেশনের সাইনড ভেরিয়েন্টও কাজ করতে হবে। বেশিরভাগ কোয়ান্টাইজড অপারেশনের সাইন করা ও সাইন না করা ভার্সন রান করার সময়, ড্রাইভারদের অবশ্যই ১২৮-এর অফসেট পর্যন্ত একই ফলাফল তৈরি করতে হবে। এই প্রয়োজনীয়তা পূরণের ক্ষেত্রে পাঁচটি ব্যতিক্রম আছে: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2 এবং QUANTIZED_16BIT_LSTM। QUANTIZED_16BIT_LSTM অপারেশনে সাইন করা অপার‍্যান্ড কাজ করে না এবং অন্য চারটি অপারেশনে সাইন করা কোয়ান্টাইজেশন কাজ করে, তবে ফলাফল একই হতে হবে না।
• ফেন্সড এক্সিকিউশনের জন্য সহায়তা যেখানে ফ্রেমওয়ার্ক IPreparedModel::executeFenced পদ্ধতিকে কল করে যাতে অপেক্ষা করার জন্য সিঙ্ক ফেন্সের ভেক্টর সহ প্রস্তুত মডেলে ফেন্সড, অ্যাসিঙ্ক্রোনাস এক্সিকিউশন লঞ্চ করা যায়। আরও তথ্যের জন্য, ফেন্সড এক্সিকিউশন দেখুন।
• কন্ট্রোল ফ্লোয়ের জন্য সহায়তা। IF এবং WHILE অপারেশন যোগ করে, যা অন্যান্য মডেলকে আর্গুমেন্ট হিসেবে গ্রহণ করে এবং শর্তসাপেক্ষে (IF) বা বারবার (WHILE) সেগুলি এক্সিকিউট করে। আরও তথ্যের জন্য, কন্ট্রোল ফ্লো দেখুন।
• পরিষেবার উন্নত কোয়ালিটি (QoS) কারণ অ্যাপ তার মডেলের আপেক্ষিক অগ্রাধিকার, কোনও মডেল প্রস্তুত করার জন্য প্রত্যাশিত সর্বাধিক সময় এবং কোনও এক্সিকিউশন সম্পূর্ণ করার জন্য প্রত্যাশিত সর্বাধিক সময় নির্দেশ করতে পারে। আরও তথ্যের জন্য, পরিষেবার কোয়ালিটি দেখুন।
• ড্রাইভার-ম্যানেজ করা বাফারের জন্য অ্যালোকেটর ইন্টারফেস প্রদান করে এমন মেমরি ডোমেনের জন্য সহায়তা। এটি একই ড্রাইভারের মধ্যে পরপর এক্সিকিউশন জুড়ে ডিভাইস নেটিভ মেমরি পাস করার অনুমতি দেয়, অপ্রয়োজনীয় ডেটা কপি করা এবং ট্রান্সফর্মেশন দমন করে। আরও তথ্যের জন্য, মেমরি ডোমেন দেখুন।

Android 10

Android 10 NN HAL 1.2 নিয়ে এসেছে, যার মধ্যে নিম্নলিখিত উল্লেখযোগ্য পরিবর্তনগুলি অন্তর্ভুক্ত।

• Capabilities struct-এ স্কেলার ডেটা টাইপ সহ সব ডেটা টাইপ অন্তর্ভুক্ত থাকে এবং এটি নামযুক্ত ফিল্ডের পরিবর্তে ভেক্টর ব্যবহার করে নন-রিলাক্সড পারফর্ম্যান্সকে উপস্থাপন করে।
• getVersionString এবং getType পদ্ধতি ফ্রেমওয়ার্ককে ডিভাইসের ধরন (DeviceType) ও ভার্সন সংক্রান্ত তথ্য পেতে দেয়। ডিভাইস ডিসকভারি ও অ্যাসাইনমেন্ট দেখুন।
• সিঙ্ক্রোনাস এক্সিকিউশন পারফর্ম করার জন্য ডিফল্ট হিসেবে executeSynchronously পদ্ধতি কল করা হয়। execute_1_2 পদ্ধতি ফ্রেমওয়ার্ককে অ্যাসিঙ্ক্রোনাস এক্সিকিউশন পারফর্ম করতে বলে। এক্সিকিউশন দেখুন।
• MeasureTiming প্যারামিটার থেকে executeSynchronously, execute_1_2, এবং বার্স্ট এক্সিকিউশন থেকে বোঝা যায় যে ড্রাইভারকে এক্সিকিউশনের সময়সীমা পরিমাপ করতে হবে কিনা। ফলাফল Timing স্ট্রাকচারে রিপোর্ট করা হয়। সময় দেখুন।
• এক বা একাধিক আউটপুট অপারেন্ডের অজানা ডাইমেনশন বা র‍্যাঙ্ক থাকলে, সেগুলি কার্যকর করার জন্য সহায়তা। আউটপুট শেপ দেখুন।
• ভেন্ডর এক্সটেনশনের জন্য সহায়তা, যা ভেন্ডর-সংজ্ঞায়িত অপারেশন ও ডেটার ধরন সংগ্রহ করে। IDevice::getSupportedExtensions পদ্ধতির মাধ্যমে ড্রাইভার, কাজ করে এমন এক্সটেনশন সম্পর্কে রিপোর্ট করেন। ভেন্ডর এক্সটেনশন দেখুন।
• অ্যাপ ও ড্রাইভার প্রসেসের মধ্যে যোগাযোগ করার জন্য ফাস্ট মেসেজ কিউ (FMQ) ব্যবহার করে, বার্স্ট অবজেক্টের মাধ্যমে বার্স্ট এক্সিকিউশনের সেট কন্ট্রোল করার ক্ষমতা, যা লেটেন্সি কমায়। বার্স্ট এক্সিকিউশন ও দ্রুত মেসেজ কিউ দেখুন।
• AHardwareBuffer-এর জন্য সহায়তা যাতে ডেটা কপি না করেই ড্রাইভার এক্সিকিউশন সম্পূর্ণ করতে পারে। AHardwareBuffer দেখুন।
• অ্যাপ চালু হলে কম্পাইলেশনের জন্য ব্যবহৃত সময় কমাতে কম্পাইলেশন আর্টিফ্যাক্ট ক্যাশিংয়ের জন্য উন্নত সহায়তা প্রদান করা হয়েছে। কম্পাইলেশন ক্যাশিং দেখুন।

Android 10-এ নিম্নলিখিত অপারেন্ডের ধরন ও অপারেশন চালু করা হয়েছে।

• অপারেন্ডের ধরন

  • ANEURALNETWORKS_BOOL
  • ANEURALNETWORKS_FLOAT16
  • ANEURALNETWORKS_TENSOR_BOOL8
  • ANEURALNETWORKS_TENSOR_FLOAT16
  • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
  • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
  • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
  • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL

• অপারেশন

  • ANEURALNETWORKS_ABS
  • ANEURALNETWORKS_ARGMAX
  • ANEURALNETWORKS_ARGMIN
  • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
  • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
  • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
  • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
  • ANEURALNETWORKS_CAST
  • ANEURALNETWORKS_CHANNEL_SHUFFLE
  • ANEURALNETWORKS_DETECTION_POSTPROCESSING
  • ANEURALNETWORKS_EQUAL
  • ANEURALNETWORKS_EXP
  • ANEURALNETWORKS_EXPAND_DIMS
  • ANEURALNETWORKS_GATHER
  • ANEURALNETWORKS_GENERATE_PROPOSALS
  • ANEURALNETWORKS_GREATER
  • ANEURALNETWORKS_GREATER_EQUAL
  • ANEURALNETWORKS_GROUPED_CONV_2D
  • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
  • ANEURALNETWORKS_INSTANCE_NORMALIZATION
  • ANEURALNETWORKS_LESS
  • ANEURALNETWORKS_LESS_EQUAL
  • ANEURALNETWORKS_LOG
  • ANEURALNETWORKS_LOGICAL_AND
  • ANEURALNETWORKS_LOGICAL_NOT
  • ANEURALNETWORKS_LOGICAL_OR
  • ANEURALNETWORKS_LOG_SOFTMAX
  • ANEURALNETWORKS_MAXIMUM
  • ANEURALNETWORKS_MINIMUM
  • ANEURALNETWORKS_NEG
  • ANEURALNETWORKS_NOT_EQUAL
  • ANEURALNETWORKS_PAD_V2
  • ANEURALNETWORKS_POW
  • ANEURALNETWORKS_PRELU
  • ANEURALNETWORKS_QUANTIZE
  • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
  • ANEURALNETWORKS_RANDOM_MULTINOMIAL
  • ANEURALNETWORKS_REDUCE_ALL
  • ANEURALNETWORKS_REDUCE_ANY
  • ANEURALNETWORKS_REDUCE_MAX
  • ANEURALNETWORKS_REDUCE_MIN
  • ANEURALNETWORKS_REDUCE_PROD
  • ANEURALNETWORKS_REDUCE_SUM
  • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_ROI_POOLING
  • ANEURALNETWORKS_RSQRT
  • ANEURALNETWORKS_SELECT
  • ANEURALNETWORKS_SIN
  • ANEURALNETWORKS_SLICE
  • ANEURALNETWORKS_SPLIT
  • ANEURALNETWORKS_SQRT
  • ANEURALNETWORKS_TILE
  • ANEURALNETWORKS_TOPK_V2
  • ANEURALNETWORKS_TRANSPOSE_CONV_2D
  • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
  • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

Android 10, আগে থেকে থাকা অনেক অপারেশনে আপডেট নিয়ে আসে। আপডেটগুলি মূলত নিম্নলিখিত বিষয়গুলির সাথে সম্পর্কিত:

• NCHW মেমরি লেআউটের জন্য সহায়তা
• softmax এবং নর্মালাইজেশন অপারেশনে র‍্যাঙ্ক ৪-এর থেকে আলাদা টেনসর কাজ করে
• ডাইলেটেড কনভলিউশন সংক্রান্ত সহায়তা
• ANEURALNETWORKS_CONCATENATION-এ মিক্সড কোয়ান্টাইজেশন সহ ইনপুটের জন্য সহায়তা

নিচের তালিকায় Android 10-এ পরিবর্তিত অপারেশনগুলি দেখানো হয়েছে। পরিবর্তন সম্পর্কে সম্পূর্ণ বিবরণ পেতে, NNAPI রেফারেন্স ডকুমেন্টেশনে OperationCode দেখুন।

• ANEURALNETWORKS_ADD
• ANEURALNETWORKS_AVERAGE_POOL_2D
• ANEURALNETWORKS_BATCH_TO_SPACE_ND
• ANEURALNETWORKS_CONCATENATION
• ANEURALNETWORKS_CONV_2D
• ANEURALNETWORKS_DEPTHWISE_CONV_2D
• ANEURALNETWORKS_DEPTH_TO_SPACE
• ANEURALNETWORKS_DEQUANTIZE
• ANEURALNETWORKS_DIV
• ANEURALNETWORKS_FLOOR
• ANEURALNETWORKS_FULLY_CONNECTED
• ANEURALNETWORKS_L2_NORMALIZATION
• ANEURALNETWORKS_L2_POOL_2D
• ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
• ANEURALNETWORKS_LOGISTIC
• ANEURALNETWORKS_LSH_PROJECTION
• ANEURALNETWORKS_LSTM
• ANEURALNETWORKS_MAX_POOL_2D
• ANEURALNETWORKS_MEAN
• ANEURALNETWORKS_MUL
• ANEURALNETWORKS_PAD
• ANEURALNETWORKS_RELU
• ANEURALNETWORKS_RELU1
• ANEURALNETWORKS_RELU6
• ANEURALNETWORKS_RESHAPE
• ANEURALNETWORKS_RESIZE_BILINEAR
• ANEURALNETWORKS_RNN
• ANEURALNETWORKS_ROI_ALIGN
• ANEURALNETWORKS_SOFTMAX
• ANEURALNETWORKS_SPACE_TO_BATCH_ND
• ANEURALNETWORKS_SPACE_TO_DEPTH
• ANEURALNETWORKS_SQUEEZE
• ANEURALNETWORKS_STRIDED_SLICE
• ANEURALNETWORKS_SUB
• ANEURALNETWORKS_SVDF
• ANEURALNETWORKS_TANH
• ANEURALNETWORKS_TRANSPOSE

Android 9

NN HAL 1.1 Android 9-এ চালু করা হয়েছে এবং এতে নিম্নলিখিত উল্লেখযোগ্য পরিবর্তন রয়েছে।

• IDevice::prepareModel_1_1-এ একটি ExecutionPreference প্যারামিটার আছে। অ্যাপ ব্যাটারি সেভ করতে পছন্দ করে অথবা দ্রুত একের পর এক কল করার সময় মডেল এক্সিকিউট করবে, এটি জেনে ড্রাইভার তার প্রস্তুতি অ্যাডজাস্ট করতে এটি ব্যবহার করতে পারে।
• নটি নতুন অপারেশন যোগ করা হয়েছে: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE.
• কোনও অ্যাপ নির্দিষ্ট করতে পারে যে Model.relaxComputationFloat32toFloat16-কে true হিসেবে সেট করে ১৬-বিট ফ্লোট রেঞ্জ এবং/অথবা প্রিসিশন ব্যবহার করে ৩২-বিট ফ্লোট কম্পিউটেশন রান করা যেতে পারে। Capabilities struct-এ অতিরিক্ত ফিল্ড relaxedFloat32toFloat16Performance আছে, তাই ড্রাইভার ফ্রেমওয়ার্কে এর রিল্যাক্সড পারফর্ম্যান্স রিপোর্ট করতে পারে।

Android 8.1

প্রাথমিক নিউরাল নেটওয়ার্ক HAL (1.0) Android 8.1-এ রিলিজ করা হয়েছিল। আরও তথ্যের জন্য, /neuralnetworks/1.0/ দেখুন।