کیفیت خدمات

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

اولویت

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

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

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

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

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

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

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

مهلت‌ها

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

فراخوانی‌های 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 مراجعه کنید.

کدهای خطا

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

• MISSED_DEADLINE_TRANSIENT
• MISSED_DEADLINE_PERSISTENT
• RESOURCE_EXHAUSTED_TRANSIENT
• RESOURCE_EXHAUSTED_PERSISTENT

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

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

اعتبارسنجی

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