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

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

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

নিউরাল নেটওয়ার্ক এইচএএল

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

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

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

সূচনা

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

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

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

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

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

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

সংকলন

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

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

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

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

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

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

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

মৃত্যুদন্ড

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

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

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

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

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

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

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

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

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

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

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

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

আউটপুট আকৃতি

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

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

টাইমিং

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

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

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

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

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

বেড়া ফাঁসি

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

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

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

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

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

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

সেবার মান

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

ক্লিনআপ

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

CPU ব্যবহার

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

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

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

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

এনএনএপিআই কোডবেসে ইউটিলিটি ফাংশন রয়েছে যা ড্রাইভার পরিষেবা দ্বারা ব্যবহার করা যেতে পারে।

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

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

  • একটি খালি স্ট্রিং, নির্দেশ করে যে কোন লগিং করা হবে না।
  • টোকেন 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 বস্তুকে এক সংস্করণ থেকে অন্য সংস্করণে রূপান্তর করে। একটি সতর্কতা লগ করা হয় যদি রূপান্তরের ফলে তথ্যের ক্ষতি হয় (অর্থাৎ, যদি টাইপের নতুন সংস্করণ মানটিকে সম্পূর্ণরূপে উপস্থাপন করতে না পারে)।

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

• প্রকারের বৈশিষ্ট্যগুলি জিজ্ঞাসা করা: isExtensionOperandType , isExtensionOperationType , nonExtensionSizeOfData , nonExtensionOperandSizeOfData , nonExtensionOperandTypeIsScalar , tensorHasUnspecifiedDimensions Dimensions।

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 : নির্দিষ্ট স্ট্রিম (যদি প্রদান করা হয়) অথবা logcat (যদি কোনো স্ট্রিম প্রদান না করা হয়) গ্রাফভিজ ( .dot ) বিন্যাসে মডেলের একটি উপস্থাপনা লেখে।

বৈধতা

আপনার NNAPI বাস্তবায়ন পরীক্ষা করতে, Android ফ্রেমওয়ার্কে অন্তর্ভুক্ত 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 দেখুন।

ফাজ টেস্টিং

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

আপনার ড্রাইভার বাস্তবায়ন যাচাই করার জন্য ফাজ টেস্টিং করতে, আপনার ড্রাইভার কোড অন্তর্ভুক্ত করার জন্য 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-এ বিক্রেতার ডিভাইসে আসল মডেলের যথার্থতা যাচাই করার জন্য অন্তর্ভুক্ত। বেঞ্চমার্ক লেটেন্সি এবং নির্ভুলতা মূল্যায়ন করে এবং একই মডেল এবং ডেটাসেটের জন্য CPU-তে চলমান TF Lite ব্যবহার করে ফলাফলের সাথে ড্রাইভারের ফলাফলের তুলনা করে। এটি নিশ্চিত করে যে ড্রাইভারের নির্ভুলতা CPU রেফারেন্স বাস্তবায়নের চেয়ে খারাপ নয়।

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

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

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

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

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

• MobileNetV1 ফ্লোট এবং u8 বিভিন্ন আকারে কোয়ান্টাইজড, ওপেন ইমেজ ডেটাসেট v4-এর একটি ছোট উপসেটের (1500 ছবি) বিপরীতে চলে।
• MobileNetV2 ফ্লোট এবং u8 বিভিন্ন আকারের কোয়ান্টাইজড, ওপেন ইমেজ ডেটাসেট v4-এর একটি ছোট উপসেটের (1500 ছবি) বিপরীতে চলে।
• দীর্ঘ স্বল্প-মেয়াদী মেমরি (LSTM) টেক্সট-টু-স্পীচের জন্য অ্যাকোস্টিক মডেল, CMU আর্কটিক সেটের একটি ছোট উপসেটের বিপরীতে চলে।
• স্বয়ংক্রিয় বক্তৃতা শনাক্তকরণের জন্য LSTM ভিত্তিক অ্যাকোস্টিক মডেল, LibriSpeech ডেটাসেটের একটি ছোট উপসেটের বিপরীতে চালানো হয়।

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

স্ট্রেস পরীক্ষা

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

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

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

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

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

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

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

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 সংস্করণ

এই বিভাগে Android এবং নিউরাল নেটওয়ার্ক HAL সংস্করণে প্রবর্তিত পরিবর্তনগুলি বর্ণনা করে৷

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

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

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

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

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

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

অ্যান্ড্রয়েড 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

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

• NCHW মেমরি লেআউটের জন্য সমর্থন
• সফটম্যাক্স এবং নরমালাইজেশন অপারেশনে 4 থেকে ভিন্ন র্যাঙ্ক সহ টেনসরগুলির জন্য সমর্থন
• প্রসারিত convolutions জন্য সমর্থন
• 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

অ্যান্ড্রয়েড 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 সেট করে 16-বিট ফ্লোট রেঞ্জ এবং/অথবা নির্ভুলতা ব্যবহার করে 32-বিট ফ্লোট গণনা চালানো যেতে পারে। Capabilities স্ট্রাকটে অতিরিক্ত ফিল্ড relaxedFloat32toFloat16Performance পারফরমেন্স রয়েছে যাতে ড্রাইভার ফ্রেমওয়ার্কে তার স্বস্তিদায়ক পারফরম্যান্স রিপোর্ট করতে পারে।

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

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