איכות השירות

החל מגרסה 11 של Android, ‏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.

    • כדי לתמוך בהקדמה, צריך לשמור את הקשר הביצוע, כולל הפעולה או מודל המשנה הבאים שיתבצעו ואת כל נתוני המשתנים הביניים הרלוונטיים. אפשר להשתמש בהקשר הביצוע הזה כדי להמשיך את הביצוע במועד מאוחר יותר.
    • אין צורך בתמיכה מלאה בהחלפה מיידית, ולכן אין צורך לשמור את הקשר של הביצוע. מכיוון שההפעלות של מודלים ב-NNAPI הן גורמיות, אפשר להפעיל אותן מחדש מהתחלה בשלב מאוחר יותר.

מערכת Android מאפשרת לשירותים להבדיל בין אפליקציות שיחה שונות באמצעות שימוש ב-AID‏ (Android UID). ל-HIDL יש מנגנונים מובנים לאחזור ה-UID של האפליקציה הקוראת באמצעות השיטה ::android::hardware::IPCThreadState::getCallingUid. רשימה של מזהי AID מופיעה בקובץ libcutils/include/cutils/android_filesystem_config.h.

מועדים אחרונים

החל מ-Android 11, אפשר להפעיל את הכנת המודל והרצות שלו באמצעות הארגומנט OptionalTimePoint deadline. לנהגים שיכולים להעריך את משך הזמן של המשימה, המועד האחרון הזה מאפשר להם לבטל את המשימה לפני שהיא מתחילה, אם הם סבורים שהיא לא תסתיים לפני המועד האחרון. באופן דומה, המועד האחרון מאפשר לנהג לבטל משימה מתמשכת שהוא מעריך שלא תסתיים לפני המועד האחרון. הארגומנט של מועד היעד לא מאלץ את הנהג לבטל משימה אם היא לא הושלמה עד למועד היעד או אם מועד היעד חלף. אפשר להשתמש בארגומנט 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.

קודי שגיאה

Android 11 כולל ארבעה ערכים של קודי שגיאה ב-NN HAL 1.3 כדי לשפר את הדיווח על שגיאות, ולאפשר לנהגים לתקשר טוב יותר על המצב שלהם, ולאפליקציות להתאושש בצורה חלקה יותר. אלה הערכים של קודי השגיאה ב-ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

ב-Android 10 ואילך, מנהל התקן יכול לציין כשל רק באמצעות קוד השגיאה GENERAL_FAILURE. החל מ-Android 11, אפשר להשתמש בשני קודי השגיאה MISSED_DEADLINE כדי לציין שעומס העבודה בוטל כי פג המועד האחרון או כי מנהל ההתקן חזה שעומס העבודה לא יושלם עד למועד האחרון. אפשר להשתמש בשני קודי השגיאה RESOURCE_EXHAUSTED כדי לציין שהמשימה נכשלה בגלל מגבלה של משאבים בתוך הנהג, למשל אם לנהג אין מספיק זיכרון לקריאה.

הגרסה TRANSIENT של שתי השגיאות מציינת שהבעיה זמנית, ושקריאות עתידיות לאותה משימה עשויות להצליח אחרי עיכוב קצר. לדוגמה, קוד השגיאה הזה אמור להופיע כשהנהג עסוק בעבודה קודמת ממושכת או בעבודה שדורשת הרבה משאבים, אבל המשימה החדשה הייתה תושלם בהצלחה אם הנהג לא היה עסוק בעבודה הקודמת. הגרסה PERSISTENT של שתי השגיאות מציינת שכינויים עתידיים לאותה משימה תמיד צפויים להיכשל. לדוגמה, קוד השגיאה הזה אמור להופיע כשהמנגנון מעריך שהמשימה לא תושלם עד למועד היעד גם בתנאים מושלמים, או שהמודל גדול מדי באופן מהותי וחורג מהמשאבים של מנגנון הטעינה.

אימות

הפונקציונליות של איכות השירות נבדקת בבדיקות NNAPI VTS (VtsHalNeuralnetworksV1_3Target). הבדיקות האלה כוללות קבוצה של בדיקות לאימות (TestGenerated/ValidationTest#Test/) כדי לוודא שהנהג דוחה תעדוף לא חוקי, וקבוצה של בדיקות שנקראות DeadlineTest (TestGenerated/DeadlineTest#Test/) כדי לוודא שהנהג מטפל בזמנים מוגדרים בצורה נכונה.