מסגרת סנכרון

מסגרת הסנכרון מתארת באופן מפורש יחסי תלות בין פעולות אסינכרוניות שונות במערכת הגרפיקה של Android. המסגרת מספקת ממשק API שמאפשר לרכיבים לציין מתי מאגרים מתפנים. ה-framework גם מאפשר העברה של רכיבי סנכרון בין מנהלי התקנים מהליבה למרחב המשתמשים ובין תהליכים במרחב המשתמש עצמם.

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

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

סנכרון מפורש

סנכרון מפורש מאפשר למפיקים ולצרכנים של מאגרי הנתונים הגרפיים לסמן שהם מסיימים להשתמש במאגר הנתונים הזמני. הסנכרון המפורש מיושם במרחב הליבה.

היתרונות של סנכרון מפורש כוללים:

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

יש שלושה סוגים של אובייקטים במסגרת הסנכרון:

• sync_timeline
• sync_pt
• sync_fence

sync_timeline

sync_timeline הוא ציר זמן שגדל באופן מונוטוני, שספקים צריכים להטמיע לכל מופע של הנהג, כמו הקשר GL, בקר תצוגה או 2D blitter. sync_timeline סופר את המשימות שנשלחו לליבה עבור חלק מסוים של חומרה. sync_timeline מספק ערבויות לגבי סדר הפעולות ומאפשר הטמעות ספציפיות לחומרה.

כשמטמיעים את sync_timeline, צריך לפעול לפי ההנחיות הבאות:

• כדי לפשט את ניפוי הבאגים, כדאי לתת שמות שימושיים לכל הגורמים, לוחות הזמנים והגדרות המכשול.
• מטמיעים את האופרטורים timeline_value_str ו-pt_value_str בזמני פעילות כדי להקל על הקריאה של הפלט של ניפוי הבאגים.
• אם רוצים, אפשר להטמיע את הפונקציה fill‏ driver_data כדי לתת לספריות במרחב המשתמש, כמו ספריית GL, גישה לנתוני ציר הזמן הפרטי. data_driver מאפשר לספקים להעביר מידע על sync_fence ו-sync_pts שלא ניתנים לשינוי כדי ליצור על סמך שורות הפקודה.
• אסור לאפשר למרחב המשתמש ליצור גדר או לסמן אותה באופן מפורש. יצירת אותות או גדרות באופן מפורש גורמת להתקפת מניעת שירות (DoS) שגורמת להפסקה של הפונקציונליות של צינור עיבוד הנתונים.
• אין לגשת לרכיבי sync_timeline, sync_pt או sync_fence באופן מפורש. ה-API מספק את כל הפונקציות הנדרשות.

sync_pt

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

סנכרון_גדר

sync_fence הוא אוסף של ערכי sync_pt שלעיתים קרובות יש להם הורים sync_timeline שונים (למשל לבקר התצוגה ולמעבד ה-GPU). sync_fence,‏ sync_pt ו-sync_timeline הם הפרימיטיבים העיקריים שבהם משתמשים מנהלי ההתקנים ומרחב המשתמש כדי להעביר את יחסי התלות שלהם. כשמתקבל אות לגדר, מובטח שכל הפקודות שהופקו לפני הגדר הושלמו, כי מנהל הליבה או בלוק החומרה מבצעים את הפקודות לפי הסדר.

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

גדרות, כמו ערכים של sync_pt, מתחילות להיות פעילות ומחליפות את המצב שלהן בהתאם למצב של הנקודות שלהן. אם כל הערכים של sync_pt יתקבלו אות, sync_fence יקבל אות. אם אחד מ-sync_pt נכנס למצב שגיאה, כל ה-sync_fence נכנס למצב שגיאה.

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

כדי להטמיע סנכרון מפורש, צריך לספק את הפרטים הבאים:

• מערכת משנה במרחב הליבה שמטמיעה את מסגרת הסנכרון למנהל חומרה מסוים. מנהלי התקנים שצריכים להיות מודעים למחסום הם בדרך כלל כל מה שיש לו גישה ל-Hardware Composer או מתקשר איתו. קבצים חשובים כוללים:
  • הטמעה ליבה:
    • kernel/common/include/linux/sync.h
    • kernel/common/drivers/base/sync.c
  • מסמכי התיעוד ב-kernel/common/Documentation/sync.txt
  • ספרייה לתקשורת עם מרחב הליבה ב-platform/system/core/libsync
• הספק צריך לספק את גבולות הסנכרון המתאימים כפרמטרים לפונקציות validateDisplay() ו-presentDisplay() ב-HAL.
• שני תוספים של GL שקשורים למחסום (EGL_ANDROID_native_fence_sync ו-EGL_ANDROID_wait_sync) ותמיכה במחסום במנהל הגרפיקה.

מקרה לדוגמה: הטמעת מנהל תצוגה

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

/*
 * assumes buffer is ready to be displayed.  returns when buffer is no longer on
 * screen.
 */
void display_buffer(struct dma_buf *buffer);

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

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

/*
 * displays buffer when fence is signaled.  returns immediately with a fence
 * that signals when buffer is no longer displayed.
 */
struct sync_fence* display_buffer(struct dma_buf *buffer, struct sync_fence
*fence);

סנכרון השילוב

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

מוסכמות השילוב

פועלים לפי המוסכמות של ממשק HAL ב-Android:

• אם ה-API מספק מתאר קובץ שמתייחס ל-sync_pt, הנהג של הספק או ה-HAL שמשתמש ב-API חייבים לסגור את מתאר הקובץ.
• אם מנהל ההתקן של הספק או ה-HAL מעבירים תיאור קובץ שמכיל sync_pt לפונקציית API, מנהל ההתקן של הספק או ה-HAL לא יכולים לסגור את תיאור הקובץ.
• כדי להמשיך להשתמש במתאר קובץ הגדר, מנהל ההתקן של הספק או ה-HAL צריכים לשכפל את המתאר.

שם של אובייקט גדר משתנה בכל פעם שהוא עובר דרך BufferQueue. התמיכה במחסום הליבה מאפשרת למחסומים לכלול מחרוזות לשמות, כך שמסגרת הסנכרון משתמשת בשם החלון ובאינדקס המאגר שנמצא בתור כדי לתת שם למחסום, למשל SurfaceView:0. האפשרות הזו מועילה לניפוי באגים כדי לזהות את המקור של נעילה מרומזת, כי השמות מופיעים בפלט של /d/sync ובדוחות באגים.

שילוב עם ANativeWindow

ANativeWindow מודע למחיצות. ל-dequeueBuffer,‏ queueBuffer ו-cancelBuffer יש פרמטרים של גדרות.

שילוב עם OpenGL ES

השילוב של OpenGL ES לסנכרון מסתמך על שני תוספי EGL:

• EGL_ANDROID_native_fence_sync מספק דרך לעטוף או ליצור מתארי קבצים של גדרות מקומיות של Android באובייקטים של EGLSyncKHR.
• EGL_ANDROID_wait_sync מאפשרת עיכובים בצד ה-GPU במקום בצד המעבד, כך שה-GPU ממתין ל-EGLSyncKHR. התוסף EGL_ANDROID_wait_sync זהה לתוסף EGL_KHR_wait_sync.

כדי להשתמש בתוספים האלה בנפרד, צריך להטמיע את התוסף EGL_ANDROID_native_fence_sync יחד עם תמיכת הליבה המשויכת. בשלב הבא, מפעילים את התוסף EGL_ANDROID_wait_sync ב-driver. התוסף EGL_ANDROID_native_fence_sync מורכב מסוג אובייקט EGLSyncKHR נפרד של גדר מקומית. כתוצאה מכך, תוספים שחלים על סוגי אובייקטים קיימים מסוג EGLSyncKHR לא חלים בהכרח על אובייקטים מסוג EGL_ANDROID_native_fence, וכך נמנעות אינטראקציות לא רצויות.

סיומת EGL_ANDROID_native_fence_sync משתמשת במאפיין מתאים של מתאר קובץ גדר מקומי, שאפשר להגדיר רק בזמן היצירה, ולא ניתן לשלוח שאילתות ישירות ממנו לאובייקט סנכרון קיים. אפשר להגדיר למאפיין הזה אחד משני המצבים הבאים:

• מתאר קובץ גדר תקין כולל מתאר קיים של קובץ גידור קיים ב-Android באובייקט EGLSyncKHR.
• הפקודה -1 יוצרת מתאר קובץ מקורי של Android מאובייקט EGLSyncKHR.

משתמשים בקריאה לפונקציה DupNativeFenceFD() כדי לחלץ את האובייקט EGLSyncKHR מתיאורי הקובץ של הגדרת המחיצה המקורית של Android. התוצאה הזו זהה לתוצאה של שליחת שאילתה על המאפיין שהוגדר, אבל היא פועלת בהתאם למוסכמות שהנמען סוגר את הגדר (מכאן הפעולה הכפולה). לבסוף, השמדת האובייקט EGLSyncKHR סוגרת את מאפיין הגדרת ההיקף הפנימי.

שילוב עם Hardware Composer

ה-Hardware Composer מטפל בשלושה סוגים של גדרות סנכרון:

• Acquire fences מועברים יחד עם מאגרי הקלט לשיחות setLayerBuffer ו-setClientTarget. הם מייצגים כתיבה בהמתנה למאגר, וצריך לסמן אותם לפני ש-SurfaceFlinger או ה-HWC מנסים לקרוא מהמאגר המשויך כדי לבצע קומפוזיציה.
• גדרות שחרור מאוחזרות אחרי הקריאה ל-presentDisplay באמצעות הקריאה getReleaseFences. אלה מייצגים קריאה בהמתנה מהמאגר הקודם באותה שכבה. ‎release fence מאותת כאשר ה-HWC כבר לא משתמש במאגר הקודם כי המאגר הנוכחי החליף את המאגר הקודם במסך. גדרות השחרור מועברות חזרה לאפליקציה יחד עם מאגרי הנתונים הקודמים, שיוחלפו במהלך היצירה הנוכחית. האפליקציה צריכה להמתין עד לשחרור של אותות גדר לפני שהיא תכתוב תוכן חדש למאגר הנתונים הזמני שמוחזר אליו.
• Present fences מוחזרים, אחד לכל פריים, כחלק מהקריאה ל-presentDisplay. הגדרות הגבולות הנוכחיות מייצגות כאשר הרכבת של המסגרת הזו הסתיימה, או לחלופין, כאשר אין יותר צורך בתוצאת ההרכבה של הפריים הקודם. במסכים פיזיים, הפונקציה presentDisplay מחזירה את המחיצות הנוכחיות כשהפריים הנוכחי מופיע במסך. אחרי שהגדרות הגדרת המכשול הקיימות מוחזרות, אפשר לכתוב שוב במאגר היעד של SurfaceFlinger, אם הדבר רלוונטי. במסכים וירטואליים, גדרות נוכחיות מוחזרות כשבטוח לקרוא מאגר הפלט.