איכות השירות

החל מ-Android 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.

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

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

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

החל מ-Android 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

כדי לראות הסבר על ההטמעה של מאפיין תאריך היעד בכל אחת מה-methods שלמעלה, תוכלו לעיין במנהל התקן לדוגמה של 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/), כדי לוודא שהנהג מטפל בתאריכי יעד בצורה נכונה.