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

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

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

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

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

הטמעה של Composer HAL 3.2 API

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

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

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

הפעלת האפשרות שתואמת לדור הקודם

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

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

הפעלת האפשרות של תאימות לדור הקודם משפיעה על הדברים הבאים:

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

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

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

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

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

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

למבחני VTS חדשים, אפשר לעבור לקישורים הבאים: