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

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

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

  • במכשירים שמושקים עם Android מגרסה 14 ואילך, צריך להטמיע את גרסה 3.2 של Composer HAL API. האפשרות הזו מופעלת כברירת מחדל וחוסכת את כמות הזיכרון המקסימלית. במכשירים שמשדרגים לגרסה 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 מכיל מאגר זמני של placeholder בגודל 1x1 ומספר משבצת למשבצת של מאגר המטמון שצריך לנקות.

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

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

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

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

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

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