הפחתת השימוש בזיכרון ה-GPU

ב-stack הגרפיקה, מאגר מטמון של מאגרים לכל שכבה נמצא בין Composer HAL ל-SurfaceFlinger כדי לצמצם את התקורה המשויכת לשליחת מתארי קבצים דרך IPC. לפני Android 14, המטמון של המאגר לא נמחק כש-GraphicBufferProducer מתנתק מ-SurfaceFlinger‏ GraphicBufferConsumer, למשל כש-MediaCodec מתנתק מ-SurfaceView. החל מ-Android 14, אפשר למחוק בכוח את המטמון במאגר כדי לצמצם את צריכת הזיכרון של הגרפיקה.

בוחרים באחת משתי האפשרויות הבאות:

  • במכשירים שיושקו עם Android מגרסה 14 ואילך, צריך להטמיע את Composer HAL API בגרסה 3.2 החדשה. האפשרות הזו מופעלת כברירת מחדל ומאפשרת לחסוך הכי הרבה זיכרון. גם במכשירים שמוגדרים לשדרוג לגרסה 14 ואילך אפשר להשתמש באפשרות הזו כדי ליהנות מהיתרונות המלאים של הזיכרון.
  • במכשירים שמשודרגים ל-Android 14 ואתם לא רוצים להטמיע בהם את Composer HAL 3.2 API, תוכלו להפעיל את האפשרות לתאימות לאחור. האפשרות הזו חוסכת כמעט כמות זהה של זיכרון כמו האפשרות הקודמת.

בקטעים הבאים מוסבר איך להטמיע כל אחת מהאפשרויות.

הטמעה של Composer HAL 3.2 API

כדי ליהנות מהיתרונות המלאים של זיכרון מאגר הגרפיקה, צריך:

  1. מעדכנים את הטמעת HAL של Composer לגרסה 3.2.
  2. מעבדים את LayerCommand::bufferSlotsToClear על ידי ניקוי הרשומות במטמון המאגר שמסומנות במספרי התחנות שמופיעים ברשימה.

ממשקי ה-API של Composer HAL 3.2 שקשורים לזיכרון של מאגר נתונים גרפי, כולל LayerCommand:bufferSlotsToClear, נמצאים ב-LayerCommand.aidl-.

מפעילים את האפשרות לתאימות לאחור

האפשרות לצמצום הזיכרון עם תאימות לאחור מחליפה מאגר נתונים אמיתי בחריץ המטמון במאגר נתונים חלופי בגודל 1x1, וכתוצאה מכך חוסך זיכרון בכל החריצים שנמחקו, מלבד החריץ הפעיל הנוכחי של מאגר הנתונים. כדי ליהנות מהיתרונות החלקיים של חיסכון בזיכרון, מפעילים את האפשרות התואמת לאחור על ידי הגדרת המאפיין sysprop‏ surface_flinger.clear_slots_with_set_layer_buffer לערך true. ה-sysprop הזה נמצא בקובץ property_contexts.

כדי להגדיר את sysprop הזה, ההטמעה של HAL ב-Composer צריכה לטפל בצורה נכונה במספר פקודות setLayerBuffer לאותה שכבה במחזור אחד של הצגה.

להפעלת האפשרות התואמת לאחור יש את ההשפעות הבאות:

  • ל-HALs של AIDL: ‏ SurfaceFlinger שולח כמה מכונות LayerCommand לשכבה אחת, כל אחת עם BufferCommand יחיד. כל BufferCommand מכיל מאגר של placeholder בגודל 1x1 ומספר חריץ של מאגר מטמון שצריך לנקות.

  • ל-HALs של HIDL: ‏ SurfaceFlinger שולח כמה פקודות SELECT_DISPLAY,‏ SELECT_LAYER ו-SET_BUFFER. הפקודות האלה מכילות מאגר של placeholder בגודל 1x1 ומספר חריץ למאגר המטמון שצריך לנקות.

האפשרות עם תאימות לאחור עלולה לגרום לקריסה של HAL ב-Composer במכשירים מסוימים. יכול להיות שתוכלו לשנות את HAL של Composer כדי לפתור את הבעיה. הקוד שקובע את ההתנהגות הזו נמצא כאן:

בדיקת צריכת הזיכרון במטמון של מאגר הנתונים הזמני של הגרפיקה

אי אפשר לאמת באמצעות בדיקות אם תאי המטמון נמחקים על ידי הטמעות HAL. עם זאת, אפשר להשתמש בכלי לניפוי באגים כדי לעקוב אחרי השימוש במאגר הגרפיקה. במהלך המעקב, תוכלו לראות ירידה במספר השגיאות מסוג 'אין מספיק זיכרון' בתרחישים שבהם כמה סרטונים שונים מופסקים ומתחילים ברצף מהיר ב-YouTube.

יש בדיקות VTS שמאפשרות לוודא שהטמעת HAL מסוגלת לקבל באופן פונקציונלי את הקריאות החדשות ל-API (HAL מגרסה 3.2 ואילך) או כמה פקודות setLayerBuffer להטמעה עם תאימות לאחור. עם זאת, לא צריך להתייחס לבדיקה הזו כאל בדיקה מספקת כדי לוודא את הפונקציונליות הנכונה, כי יש מכשירים שעוברים את בדיקות ה-VTS האלה אבל נכשלים בתרחישי שימוש בעולם האמיתי.

כדי למצוא בדיקות VTS חדשות, עוברים לקישורים הבאים: