کیفیت خدمات

با شروع از اندروید 11، NNAPI کیفیت خدمات (QoS) بهتری را با اجازه دادن به برنامه برای نشان دادن اولویت های نسبی مدل های خود، حداکثر زمان مورد انتظار برای آماده شدن یک مدل معین و حداکثر زمان مورد انتظار برای ارائه می دهد. یک اجرای معین باید تکمیل شود. علاوه بر این، Android 11 مقادیر اضافی خطای NNAPI را معرفی می‌کند که به یک سرویس امکان می‌دهد با دقت بیشتری نشان دهد که در صورت بروز نقص چه اشتباهی رخ داده است تا برنامه مشتری بتواند بهتر واکنش نشان دهد و بازیابی کند.

اولویت

برای Android 11 یا بالاتر، مدل‌ها با اولویت در NN HAL 1.3 آماده شده‌اند. این اولویت نسبت به سایر مدل های آماده شده متعلق به همان برنامه است. اجراهای با اولویت بالاتر می‌توانند از منابع محاسباتی بیشتری نسبت به اجراهای با اولویت پایین‌تر استفاده کنند و می‌توانند از اجرای با اولویت پایین‌تر جلوگیری کنند یا از آن جلوگیری کنند.

فراخوانی NN HAL 1.3 که شامل Priority به عنوان یک آرگومان صریح است IDevice::prepareModel_1_3 است. توجه داشته باشید که IDevice::prepareModelFromCache_1_3 به طور ضمنی Priority در آرگومان های کش گنجانده است.

بسته به توانایی های راننده و شتاب دهنده، استراتژی های ممکن زیادی برای پشتیبانی از اولویت ها وجود دارد. در اینجا چندین استراتژی وجود دارد:

• برای درایورهایی که پشتیبانی از اولویت داخلی دارند، فیلد Priority را مستقیماً در شتاب دهنده پخش کنید.
• حتی قبل از اینکه اجرا به شتاب دهنده برسد، از یک صف اولویت برای هر برنامه برای پشتیبانی از اولویت های مختلف استفاده کنید.

• مدل‌های با اولویت پایین را که در حال اجرا هستند متوقف یا لغو کنید تا شتاب‌دهنده برای اجرای مدل‌های با اولویت بالا آزاد شود. این کار را با قرار دادن نقاط بازرسی در مدل‌های با اولویت پایین انجام دهید که پس از رسیدن به آن، پرچمی را برای تعیین اینکه آیا اجرای فعلی باید زودتر از موعد متوقف شود یا با تقسیم کردن مدل به مدل‌های فرعی و جستجوی پرچم بین اجرای زیرمدل، درخواست می‌کند. توجه داشته باشید که استفاده از نقاط بازرسی یا مدل‌های فرعی در مدل‌های آماده‌شده با اولویت می‌تواند سربار اضافی را ایجاد کند که برای مدل‌های بدون اولویت در نسخه‌های کمتر از NN HAL 1.3 وجود ندارد.

  • برای پشتیبانی از Preemption، زمینه اجرا شامل عملیات بعدی یا مدل فرعی که باید اجرا شود و هر داده عملوند میانی مربوطه را حفظ کنید. از این زمینه اجرا برای از سرگیری اجرا در زمان دیگری استفاده کنید.
  • پشتیبانی کامل Preemption لازم نیست، بنابراین زمینه اجرا نیازی به حفظ نیست. از آنجایی که اجرای مدل NNAPI قطعی است، اجراها را می‌توان از ابتدا مجدداً شروع کرد.

Android سرویس‌ها را قادر می‌سازد تا از طریق استفاده از AID (Android UID) بین برنامه‌های تماس مختلف تمایز قائل شوند. HIDL دارای مکانیسم‌های داخلی برای بازیابی UID برنامه تماس‌گیرنده از طریق روش ::android::hardware::IPCThreadState::getCallingUid . فهرستی از ایدزها را می‌توانید در libcutils/include/cutils/android_filesystem_config.h پیدا کنید.

مهلت ها

با شروع از اندروید 11، آماده سازی و اجرای مدل را می توان با آرگومان مهلت زمانی OptionalTimePoint راه اندازی کرد. برای رانندگانی که می توانند مدت زمان انجام یک کار را تخمین بزنند، این مهلت به راننده اجازه می دهد تا کار را قبل از شروع آن متوقف کند، اگر راننده تخمین بزند که کار نمی تواند قبل از ضرب الاجل کامل شود. به طور مشابه، مهلت به راننده اجازه می دهد تا یک کار در حال انجام را که تخمین می زند قبل از مهلت تکمیل نمی شود، متوقف کند. استدلال ضرب‌الاجل راننده را مجبور نمی‌کند تا یک کار را متوقف کند، اگر کار در مهلت مقرر کامل نشده باشد یا مهلت آن تمام شده باشد. آرگومان مهلت را می توان برای آزاد کردن منابع محاسباتی در درایور و بازگرداندن کنترل به برنامه سریعتر از آنچه که بدون ضرب الاجل ممکن است استفاده کرد.

فراخوانی‌های NN HAL 1.3 که مهلت‌های OptionalTimePoint به عنوان آرگومان شامل می‌شوند عبارتند از:

• IDevice::prepareModel_1_3
• IDevice::prepareModelFromCache_1_3
• IPreparedModel::execute_1_3
• IPreparedModel::executeSynchronously_1_3
• IPreparedModel::executeFenced

برای مشاهده اجرای مرجع ویژگی ضرب‌الاجل برای هر یک از روش‌های بالا، درایور نمونه NNAPI را در frameworks/ml/nn/driver/sample/SampleDriver.cpp ببینید.

کدهای خطا

اندروید 11 شامل چهار مقدار کد خطا در NN HAL 1.3 است تا گزارش خطا را بهبود بخشد و به رانندگان اجازه می‌دهد وضعیت خود را بهتر و برنامه‌ها را برای بازیابی زیباتر ارتباط برقرار کنند. اینها مقادیر کد خطا در ErrorStatus هستند.

• MISSED_DEADLINE_TRANSIENT
• MISSED_DEADLINE_PERSISTENT
• RESOURCE_EXHAUSTED_TRANSIENT
• RESOURCE_EXHAUSTED_PERSISTENT

در اندروید 10 یا پایین‌تر، یک درایور فقط از طریق کد خطای GENERAL_FAILURE می‌تواند خطا را نشان دهد. از Android 11، از دو کد خطای MISSED_DEADLINE می‌توان برای نشان دادن این که حجم کار به دلیل پایان مهلت مقرر یا به دلیل اینکه راننده پیش‌بینی کرده بود حجم کار تا مهلت مقرر تکمیل نمی‌شود، متوقف شده است، استفاده شود. دو کد خطای RESOURCE_EXHAUSTED را می توان برای نشان دادن اینکه کار به دلیل محدودیت منابع در درایور، مانند نداشتن حافظه کافی برای تماس، انجام نشد، استفاده کرد.

نسخه TRANSIENT هر دو خطا نشان می‌دهد که مشکل موقتی است و ممکن است تماس‌های بعدی برای همان کار پس از تأخیر کوتاهی موفق شوند. به عنوان مثال، این کد خطا باید زمانی که راننده مشغول کار طولانی مدت یا پر منابع قبلی است، بازگردانده شود، اما اگر راننده با کار قبلی مشغول نبود، کار جدید با موفقیت انجام می شود. نسخه PERSISTENT هر دو خطا نشان می دهد که همیشه انتظار می رود تماس های آینده برای یک کار مشابه با شکست مواجه شوند. به عنوان مثال، زمانی که راننده تخمین می‌زند که کار حتی در شرایط عالی نیز تا مهلت مقرر تکمیل نمی‌شود، یا اینکه مدل ذاتاً خیلی بزرگ است و از منابع راننده فراتر می‌رود، باید این کد خطا برگردانده شود.

اعتبار سنجی

کیفیت عملکرد سرویس در تست های NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ) آزمایش می شود. این شامل مجموعه‌ای از تست‌ها برای اعتبارسنجی ( TestGenerated/ValidationTest#Test/ ) برای اطمینان از اینکه راننده اولویت‌های نامعتبر را رد می‌کند و مجموعه‌ای از تست‌ها به نام DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) است تا اطمینان حاصل شود که راننده به درستی ضرب‌الاجل‌ها را انجام می‌دهد.