নিউরাল নেটওয়ার্ক এপিআই ড্রাইভার

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

নিউরাল নেটওয়ার্কস এপিআই সম্পর্কে আরও তথ্যের জন্য, নিউরাল নেটওয়ার্কস এপিআই দেখুন।

নিউরাল নেটওয়ার্ক HAL

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

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

চিত্র ১. নিউরাল নেটওয়ার্কের প্রবাহ

প্রারম্ভিকীকরণ

প্রারম্ভিকীকরণের সময়, ফ্রেমওয়ার্কটি IDevice::getCapabilities_1_3 ব্যবহার করে ড্রাইভারের সক্ষমতা সম্পর্কে জিজ্ঞাসা করে। @1.3::Capabilities কাঠামোটিতে সমস্ত ডেটা টাইপ অন্তর্ভুক্ত থাকে এবং এটি একটি ভেক্টর ব্যবহার করে অনমনীয় পারফরম্যান্স উপস্থাপন করে।

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

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

অ্যান্ড্রয়েড ৯ এবং এর পূর্ববর্তী সংস্করণগুলিতে, Capabilities স্ট্রাকচারে শুধুমাত্র ফ্লোটিং পয়েন্ট এবং কোয়ান্টাইজড টেনসরের জন্য ড্রাইভার পারফরম্যান্সের তথ্য অন্তর্ভুক্ত থাকে এবং এতে স্কেলার ডেটা টাইপ অন্তর্ভুক্ত থাকে না।

প্রারম্ভিকীকরণ প্রক্রিয়ার অংশ হিসেবে, ফ্রেমওয়ার্কটি IDevice::getType , IDevice::getVersionString , IDevice:getSupportedExtensions , এবং IDevice::getNumberOfCacheFilesNeeded ব্যবহার করে আরও তথ্য জানতে চাইতে পারে।

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

সংকলন

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

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

• ড্রাইভারটি ডেটা টাইপটি সমর্থন করে না।
• ড্রাইভারটি শুধুমাত্র নির্দিষ্ট ইনপুট প্যারামিটারযুক্ত অপারেশনগুলোই সমর্থন করে। উদাহরণস্বরূপ, একটি ড্রাইভার 3x3 এবং 5x5 সমর্থন করতে পারে, কিন্তু 7x7 কনভোলিউশন অপারেশন সমর্থন করে না।
• ড্রাইভারটির মেমোরির সীমাবদ্ধতা থাকায় এটি বড় গ্রাফ বা ইনপুট পরিচালনা করতে পারে না।

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

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

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

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

মৃত্যুদণ্ড

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

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

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

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

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

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

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

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

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

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

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

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

আউটপুট আকৃতি

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

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

সময়

অ্যান্ড্রয়েড ১০-এ, কোনো অ্যাপ কম্পাইলেশন প্রক্রিয়ার সময় ব্যবহারের জন্য একটিমাত্র ডিভাইস নির্দিষ্ট করে দিলে, অ্যাপটি তার এক্সিকিউশন টাইম জানতে চাইতে পারে। বিস্তারিত জানতে, MeasureTiming এবং Device Discovery and Assignment দেখুন। এক্ষেত্রে, একটি অনুরোধ কার্যকর করার সময় NN HAL 1.2 ড্রাইভারকে অবশ্যই এক্সিকিউশন ডিউরেশন পরিমাপ করতে হবে অথবা UINT64_MAX রিপোর্ট করতে হবে (যা নির্দেশ করে যে ডিউরেশন উপলব্ধ নেই)। এক্সিকিউশন ডিউরেশন পরিমাপের ফলে সৃষ্ট যেকোনো পারফরম্যান্সের ঘাটতি ড্রাইভারটির সর্বনিম্ন রাখা উচিত।

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

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

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

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

বেড়ার মধ্যে মৃত্যুদণ্ড

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

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

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

• timingLaunched : executeFenced কল করার মুহূর্ত থেকে শুরু করে executeFenced ফেরত আসা syncFence সংকেত পাঠানোর মুহূর্ত পর্যন্ত সময়কাল।
• timingFenced : এক্সিকিউশন যে সমস্ত সিঙ্ক ফেন্সের জন্য অপেক্ষা করে, সেগুলোকে সিগন্যাল দেওয়ার মুহূর্ত থেকে executeFenced ফেরত আসা syncFence কে সিগন্যাল দেওয়া পর্যন্ত সময়কাল।

প্রবাহ নিয়ন্ত্রণ করুন

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

পরিষেবার মান

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

পরিষ্কার-পরিচ্ছন্নতা

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

সিপিইউ ব্যবহার

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

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

অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯)-এ প্রবর্তিত অপারেশনগুলোতে শুধুমাত্র একটি রেফারেন্স সিপিইউ ইমপ্লিমেন্টেশন রয়েছে, যা দিয়ে CTS এবং VTS টেস্টগুলো সঠিক কিনা তা যাচাই করা যায়। NNAPI সিপিইউ ইমপ্লিমেন্টেশনের চেয়ে মোবাইল মেশিন লার্নিং ফ্রেমওয়ার্কগুলোতে অন্তর্ভুক্ত অপটিমাইজড ইমপ্লিমেন্টেশনগুলো বেশি পছন্দনীয়।

উপযোগিতা ফাংশন

NNAPI কোডবেসে এমন ইউটিলিটি ফাংশন অন্তর্ভুক্ত রয়েছে যা ড্রাইভার সার্ভিসগুলো ব্যবহার করতে পারে।

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

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

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

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

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

• Capabilities: 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 টাইপ এবং এক্সটেনশন টাইপগুলো ভ্যালিডেট করা হয় না। উদাহরণস্বরূপ, validateModel false রিটার্ন করে যদি মডেলে এমন কোনো অপারেশন থাকে যা এমন একটি অপারেন্ড ইনডেক্সকে রেফারেন্স করে যার অস্তিত্ব নেই, অথবা এমন কোনো অপারেশন থাকে যা সেই HAL সংস্করণে সমর্থিত নয়।

frameworks/ml/nn/common/include/Tracing.h ফাইলটিতে নিউরাল নেটওয়ার্ক কোডে সিস্ট্রেসিং তথ্য যোগ করার প্রক্রিয়া সহজ করার জন্য ম্যাক্রো রয়েছে। একটি উদাহরণের জন্য, নমুনা ড্রাইভারের মধ্যে NNTRACE_* ম্যাক্রো আহ্বানগুলো দেখুন।

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

• graphDump : মডেলের একটি উপস্থাপনাকে গ্রাফভিজ ( .dot ) ফরম্যাটে নির্দিষ্ট স্ট্রিমে (যদি দেওয়া থাকে) অথবা লগক্যাটে (যদি কোনো স্ট্রিম না দেওয়া থাকে) লিখে রাখে।

বৈধতা

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

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

• ফ্লোটিং-পয়েন্ট: abs(প্রত্যাশিত - প্রকৃত) <= atol + rtol * abs(প্রত্যাশিত); যেখানে:

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

• কোয়ান্টাইজড: এক দ্বারা অফ ( mobilenet_quantized ব্যতীত, যা তিন দ্বারা অফ)

• বুলিয়ান: সঠিক মিল

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

ফাজ টেস্টিং

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

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

নিরাপত্তা

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

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

অ্যান্ড্রয়েড মেশিন লার্নিং টেস্ট স্যুট

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

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

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

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

মডেল এবং ডেটাসেট

NNAPI বেঞ্চমার্কটি নিম্নলিখিত মডেল এবং ডেটাসেটগুলো ব্যবহার করে।

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

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

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

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

সকল ক্র্যাশ টেস্ট নিম্নলিখিত বৈশিষ্ট্যগুলো প্রদান করে:

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

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

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

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

MLTS ব্যবহার করুন

এমএলটিএস ব্যবহার করতে:

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

2. অ্যান্ড্রয়েডের শীর্ষ-স্তরের সোর্স ডিরেক্টরিতে প্রবেশ 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 দেখুন।

নিউরাল নেটওয়ার্ক HAL সংস্করণ

এই অংশে অ্যান্ড্রয়েড এবং নিউরাল নেটওয়ার্কস HAL সংস্করণগুলিতে প্রবর্তিত পরিবর্তনগুলি বর্ণনা করা হয়েছে।

অ্যান্ড্রয়েড ১১

অ্যান্ড্রয়েড ১১-এর সাথে এনএন এইচএএল ১.৩ চালু করা হয়েছে, যাতে নিম্নলিখিত উল্লেখযোগ্য পরিবর্তনগুলো রয়েছে।

• 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) উন্নত হয়, কারণ অ্যাপগুলো তার মডেলগুলোর আপেক্ষিক অগ্রাধিকার, একটি মডেল প্রস্তুত হতে প্রত্যাশিত সর্বোচ্চ সময় এবং একটি কার্য সম্পাদন সম্পন্ন হতে প্রত্যাশিত সর্বোচ্চ সময় নির্দেশ করতে পারে। আরও তথ্যের জন্য, পরিষেবার মান (Quality of Service ) দেখুন।
• ড্রাইভার-পরিচালিত বাফারের জন্য অ্যালোকেটর ইন্টারফেস প্রদানকারী মেমরি ডোমেইনের সমর্থন। এটি এক এক্সিকিউশন থেকে অন্য এক্সিকিউশনে ডিভাইসের নেটিভ মেমরি পাস করার সুযোগ দেয়, যা একই ড্রাইভারের অধীনে পরপর এক্সিকিউশনের মধ্যে অপ্রয়োজনীয় ডেটা কপি এবং রূপান্তরকে দমন করে। আরও তথ্যের জন্য, মেমরি ডোমেইন দেখুন।

অ্যান্ড্রয়েড ১০

অ্যান্ড্রয়েড ১০-এ এনএন এইচএএল ১.২ চালু করা হয়েছে, যাতে নিম্নলিখিত উল্লেখযোগ্য পরিবর্তনগুলো রয়েছে।

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

অ্যান্ড্রয়েড ১০-এ নিম্নলিখিত অপারেন্ডের প্রকার ও অপারেশনগুলো চালু করা হয়েছে।

• অপারেন্ডের প্রকারভেদ

  • 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

অ্যান্ড্রয়েড ১০ বিদ্যমান অনেক কার্যক্রমে আপডেট এনেছে। এই আপডেটগুলো প্রধানত নিম্নলিখিত বিষয়গুলোর সাথে সম্পর্কিত:

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

নিচের তালিকায় অ্যান্ড্রয়েড ১০-এ পরিবর্তিত অপারেশনগুলো দেখানো হয়েছে। পরিবর্তনগুলোর সম্পূর্ণ বিবরণের জন্য, 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

অ্যান্ড্রয়েড ৯

অ্যান্ড্রয়েড ৯-এ এনএন এইচএএল ১.১ চালু করা হয়েছে এবং এতে নিম্নলিখিত উল্লেখযোগ্য পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে।

• 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 স্ট্রাকচারটিতে relaxedFloat32toFloat16Performance নামক একটি অতিরিক্ত ফিল্ড রয়েছে, যাতে ড্রাইভার তার রিল্যাক্সড পারফরম্যান্স ফ্রেমওয়ার্ককে রিপোর্ট করতে পারে।

অ্যান্ড্রয়েড ৮.১

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