RenderScript הוא framework להרצה עתירת חישוב לביצועים גבוהים ב-Android. הוא מיועד לשימוש חישוב מקבילי של נתונים, למרות שגם עומסי עבודה טוריים יכולים להפיק תועלת. זמן הריצה של RenderScript פועל במקביל בין מעבדים שונים שזמינים כמו מעבדים (CPU) עם כמה ליבות ומעבדי GPU, וכך המפתחים יכולים להתמקד שמציינים אלגוריתמים במקום לתזמן עבודה. במיוחד עבור RenderScript שימושי לאפליקציות שמבצעות עיבוד תמונות, או ראייה ממוחשבת.
מכשירים עם Android מגרסה 8.0 ואילך משתמשים ב-RenderScript הבא HALs של framework ו-HAL של ספק:
איור 1. קוד ספק שמקשר ל-libs פנימיים.
ההבדלים בין RenderScript ב-Android 7.x ומטה כוללים:
- שני מופעים של libs פנימיים ב-RenderScript. קבוצה אחת היא עבור
נתיב החלופי של ה-CPU הוא ישירות ב-
/system/lib
. השני מוגדר לנתיב GPU ומקורו ב-/system/lib/vndk-sp
. - קישורים פנימיים של RSD ב-
/system/lib
נבנים כחלק הפלטפורמה והם מתעדכנים במהלך השדרוג שלsystem.img
. לעומת זאת, libs ב-/system/lib/vndk-sp
נבנו עבור הספק מעודכן כאשרsystem.img
משודרג (בזמן שניתן לעדכן אותם לצורך תיקון אבטחה, ה-ABI שלהם נשאר ללא שינוי). - קוד הספק (RS HAL, מנהל התקן RS וה-
bcc plugin
) הם מקושר ל-libs הפנימיים של RenderScript שנמצאים בכתובת/system/lib/vndk-sp
. הם לא יכולים לקשר ל-libs ב-/system/lib
כי lib בספרייה הזו נבנו עבור פלטפורמה אחרת, ולכן ייתכן שלא יתאימו לקוד הספק (כלומר, סמלים ). אם תעשו זאת, יהיה בלתי אפשרי להשתמש ב-OTA עם מסגרת בלבד.
עיצוב
הקטעים הבאים מפרטים את העיצוב של RenderScript ב-Android 8.0 ואילך.
קישורים של RenderScript זמינים לספקים
בקטע הזה רשומים מילות המפתח (libs) של RenderScript (שנקראות 'Vendor NDK' לתהליך זהה (Same-Process) HAL או VNDK-SP) שזמינים לקוד הספק ואפשר לקשר אותם נגד. בנוסף, מפורטות בו ספריות נוספות שאינן קשורות RenderScript, אבל מסופקים גם לקוד הספק.
רשימת הספריות הבאה עשויה להשתנות בין גרסאות Android,
לא ניתן לשנות אותה בגרסה ספציפית של Android. לרשימה עדכנית של
ספריות זמינות, בכתובת /system/etc/ld.config.txt
.
דפי RenderScript | Libs שאינם RenderScript |
---|---|
|
|
הגדרת מרחב השמות של מקשר
הגבלת הקישור שמונעת שימוש ב-libs שלא נמצאים ב-VNDK-SP קוד הספק נאכף בזמן הריצה באמצעות מרחב השמות המקשר. (לפרטים, לעיון בעיצוב VNDK מצגת.)
במכשיר עם Android מגרסה 8.0 ואילך, כל המעבדים מסוג Same-Process HALs (SP-HAL)
חוץ מ-RenderScript נטענים בתוך מרחב השמות של המקשר
sphal
. RenderScript נטען בקובץ ה-RenderScript הספציפי
מרחב השמות rs
, מיקום שבו אפשר להשתמש
אכיפה של RenderScript libs. כי צריך לטעון את הטמעת ה-RS
קוד הביטקוד המורכב, /data/*/*.so
, מתווסף לנתיב של
מרחב השמות rs
(שירותי SP-HAL אחרים אינם מורשים לטעון libs
חלוקת נתונים).
בנוסף, מרחב השמות rs
מאפשר יותר קישורים ממה שצוין ל-
לפי מרחבי שמות אחרים. libmediandk.so
ו-libft2.so
נחשפו למרחב השמות rs
כי
ל-libRS_internal.so
יש תלות פנימית בספריות האלה.
איור 2. הגדרת מרחב שמות לקישור.
טעינת נהגים
נתיב חלופי של מעבד (CPU)
בהתאם לקיומו של הביט RS_CONTEXT_LOW_LATENCY
כשיוצרים הקשר RS, נבחר נתיב ה-CPU או ה-GPU. כאשר
נבחר נתיב המעבד (CPU), libRS_internal.so
(ההטמעה הראשית
של ה-framework של RS) dlopen
ישירות מהמקשר המוגדר כברירת מחדל
מרחב שמות שבו סופקה גרסת הפלטפורמה של RSA.
לא נעשה בכלל שימוש בהטמעת RS HAL של הספק כשהמעבד
נעשה שימוש בנתיב החלופי, ואובייקט RsContext
נוצר עם
null mVendorDriverName
. libRSDriver.so
הוא (לפי
ברירת מחדל) dlopen
ורשימת הנהג נטענת
מרחב השמות default
כי המתקשר/ת
(libRS_internal.so
) נטען גם ב-default
מרחב שמות.
איור 3. נתיב חלופי למעבד (CPU).
נתיב GPU
לנתיב ה-GPU, השדה libRS_internal.so
נטען באופן שונה.
הראשון, libRS.so
משתמש
android.hardware.renderscript@1.0.so
(והיסודות שלו
libhidltransport.so
) כדי לטעון
android.hardware.renderscript@1.0-impl.so
(ספק
RS HAL) במרחב שמות אחר שמקשר שנקרא
sphal
RSD
HAL ואז dlopen
libRS_internal.so
מרחב שמות של מקשר בשם rs
.
ספקים יכולים לספק מנהל התקן RS משלהם על ידי הגדרת התכונה הניסיונית 'זמן build'
OVERRIDE_RS_DRIVER
, שמוטמע ב-RS HAL
יישום
(hardware/interfaces/renderscript/1.0/default/Context.cpp
). הזה
לאחר מכן, שם מנהל ההתקן מקבל dlopen
עבור ההקשר של ה-RS בנתיב ה-GPU.
יצירת האובייקט RsContext
מועברת ל-RS HAL
יישום בפועל. פרוטוקול HAL מבצע קריאה חוזרת ל-framework של RSD באמצעות
rsContextCreateVendor()
עם שם הנהג/ת
כארגומנט. לאחר מכן, מסגרת ה-RS טוענת את מנהל ההתקן שצוין כאשר
RsContext
הופעל. במקרה הזה, ספריית הנהגים
נטען למרחב השמות של rs
כי RsContext
נוצר בתוך מרחב השמות rs
.
/vendor/lib
נמצא בנתיב החיפוש של מרחב השמות.
איור 4. נתיב חלופי של GPU.
במעבר ממרחב השמות default
אל
מרחב השמות sphal
, libhidltransport.so
משתמש ב
בפונקציה android_load_sphal_library()
כדי לסדר באופן מפורש את הפונקציה
מקשר דינמי כדי לטעון את הספרייה -impl.so
מרחב השמות sphal
.
במעבר ממרחב השמות sphal
אל
מרחב השמות rs
, הטעינה מתבצעת בעקיפין על ידי השורה הבאה ב-
/system/etc/ld.config.txt
:
namespace.sphal.link.rs.shared_libs = libRS_internal.so
השורה הזו מציינת שצריך לטעון את המנגנון לקישור הדינמי
libRS_internal.so
ממרחב השמות rs
כשה-lib
לא ניתן למצוא או לטעון אותו ממרחב השמות sphal
(שתמיד מוגדר
מכיוון שמרחב השמות sphal
אינו מבצע חיפוש
/system/lib/vndk-sp
כאשר libRS_internal.so
כתובת המגורים). בתצורה הזו, ניתן לבצע קריאה פשוטה של dlopen()
אל
libRS_internal.so
מספיק כדי לבצע את מעבר מרחב השמות.
טעינת הפלאגין 'עותק מוסתר'
bcc plugin
היא ספרייה שסופקה על ידי ספק, נטענת
מהדר (bcc
). כי bcc
הוא תהליך מערכת
ספריית /system/bin
, הספרייה bcc plugin
יכולה להיות
נחשב כ-SP-HAL (כלומר, HAL של ספק שניתן לטעון ישירות
במערכת שלא מקשרת ביניהם). בתור SP-HAL,
ספרייה של bcc-plugin
:
- לא ניתן לקשר לספריות של framework בלבד כמו
libLLVM.so
- הקישור יכול לקשר רק לספריות VNDK-SP שזמינות לספק.
ההגבלה הזו נאכפת על ידי טעינת bcc plugin
אל
מרחב השמות sphal
שמשתמש ברכיב
android_sphal_load_library()
. בגרסאות קודמות של
Android, שם הפלאגין צוין באמצעות האפשרות -load
וגם
הליב נטען באמצעות הפקודה dlopen()
הפשוטה של
libLLVM.so
. ב-Android מגרסה 8.0 ואילך, הדבר מצוין
האפשרות -plugin
וה-lib נטען ישירות על ידי
bcc
עצמו. אם בוחרים באפשרות הזו, נתיב לא ספציפי ל-Android
בפרויקט של קוד פתוח ב-LLVM.
איור 5. מתבצעת טעינה של הפלאגין 'עותק מוסתר', Android 7.x ומטה.
איור 6. מתבצעת טעינה של הפלאגין 'עותק מוסתר', Android מגרסה 8.0 ואילך.
נתיבי חיפוש של ld.mc
כשמריצים את הפקודה ld.mc
, חלק מפריטי ה-lib של זמן הריצה של RS ניתנים כקלט
למנגנון לקישור. ה-bitcode של ה-RS מהאפליקציה מקושר אל ה-libs של סביבת זמן הריצה
וכשהביטקוד שהומר נטען לתהליך אפליקציה, libs בסביבת זמן הריצה
מקושרים שוב באופן דינמי מהביטקוד שהומר.
כללי זמן הריצה כוללים:
libcompiler_rt.so
libm.so
libc.so
- מנהל התקן RS (
libRSDriver.so
אוOVERRIDE_RS_DRIVER
)
כשטוענים את קטע הקוד שעבר הידור לתהליך האפליקציה, צריך לספק את אותו קוד אימות
שהיו בשימוש על ידי ld.mc
. אחרת, קטע הקוד שעבר הידור
ייתכן שלא ימצא סמל שהיה זמין כשביצעתם קישור.
כדי לעשות זאת, ה-framework של RSD משתמש בנתיבי חיפוש שונים של ה-libs של זמן הריצה כאשר
מריצים את ld.mc
, בהתאם למסגרת ה-RS עצמה
נטען מ-/system/lib
או מ-/system/lib/vndk-sp
.
אפשר לקבוע זאת לפי הכתובת של סמל שרירותי של RS
framework lib ומשתמשים ב-dladdr()
כדי למפות את נתיב הקובץ אל
את הכתובת.
מדיניות SELinux
כתוצאה משינויים במדיניות SELinux ב-Android 8.0 ואילך,
לציית לכללים ספציפיים (הנאכפים דרך neverallows
) כאשר
תיוג קבצים נוספים במחיצה vendor
:
vendor_file
חייבת להיות תווית ברירת המחדל בכל הקבצים ב- מחיצהvendor
. לפי מדיניות הפלטפורמה, צריך את זה כדי הטמעת פרוטוקול HAL של העברה.- כל ערכי
exec_types
החדשים נוספו במחיצהvendor
דרך SEPolicy של הספק, חייב להיות מאפייןvendor_file_type
. המדיניות הזו נאכפת דרךneverallows
. - כדי למנוע התנגשויות עם עדכונים עתידיים של פלטפורמה או framework, מומלץ לא להוסיף תוויות
קבצים אחרים מלבד
exec_types
במחיצהvendor
. - לכל יחסי התלות של ספריות עבור HAL של תהליך שמזוהה על ידי AOSP צריך להיות
מתויג בתור
same_process_hal_file
.
פרטים נוספים על המדיניות של SELinux זמינים כאן Linux עם שיפור אבטחה ב-Android.
תאימות ABI לביטקוד
אם לא יתווספו ממשקי API חדשים, כלומר לא תהיה תמיכה בגרסת HAL, של frameworks של RS ימשיך להשתמש במנהל התקן ה-GPU (HAL 1.0) הקיים.
במקרה של שינויי HAL קלים (HAL 1.1) שלא משפיעים על סיביות קוד, ה-frameworks צריך החלופה לשימוש במעבד (CPU) בממשקי ה-API החדשים שנוספו, וממשיכים להשתמש במנהל התקן GPU (HAL 1.0). במקום אחר.
לשינויים משמעותיים ב-HAL (HAL 2.0) שמשפיעים על הידור/קישור של קוד ביטים, RS על frameworks לבחור שלא לטעון מנהלי התקנים של GPU שסופקו על ידי הספק, ובמקום זאת להשתמש במעבד (CPU) או בנתיב Vulkan לצורך האצה.
השימוש ב-bitcode של RenderScript מתרחשת בשלושה שלבים:
שלב | פרטים |
---|---|
הידור |
|
קישור |
|
טעינה |
|
בנוסף ל-HAL, ממשקי API של זמן ריצה והסמלים המיוצאים נכללים גם הם ממשקים. אף אחד מהממשקים לא השתנה מאז Android 7.0 (API 24) אין תוכניות מיידיות לשנות אותו ב-Android מגרסה 8.0 ואילך. אבל אם והממשק משתנה, גם גרסת HAL תגדל.
הטמעות של ספקים
למערכת Android מגרסה 8.0 ואילך נדרשים כמה שינויים במנהל ההתקן של ה-GPU כדי שמנהל התקן ה-GPU יוכל להשתמש בו. פועלות כראוי.
מודולים של מנהלי התקנים
- המודולים של מנהלי התקן לא יכולים להיות תלויים בספריות מערכת שלא הרשימה.
- הנהג/ת צריך/ה לספק תוכן משלו
android.hardware.renderscript@1.0-impl_{NAME}
, או להצהיר על הטמעת ברירת המחדלandroid.hardware.renderscript@1.0-impl
בתור שתלויות בו. - דוגמה טובה להטמעה של המעבד (CPU)
libRSDriver.so
להסיר יחסי תלות שאינם VNDK-SP.
מהדר ב-Bitcode
יש שתי דרכים להדרת קוד ביט של RenderScript עבור מנהל התקן של הספק:
- הפעלת מהדר (compiler) ספציפי לספק ב-
/vendor/bin/
(השיטה המועדפת להדרת GPU). בדומה למודולים אחרים של מנהלי התקנים, הבינארי של מהדר (compiler) של הספק לא יכול להיות תלוי בספריית מערכת כלשהי שלא נמצאת רשימה של libs ב-RenderScript שזמינות לספקים. - הפעלת 'עותק מוסתר של המערכת':
/system/bin/bcc
עם ספק שסופק על ידי ספקbcc plugin
; הפלאגין הזה לא יכול להסתמך על ספריית מערכת כלשהי לא מופיע ברשימה של libs זמינים ב-RenderScript לספקים.
אם הספק bcc plugin
צריך להפריע למעבד (CPU)
את המידע ואת התלות שלו ב-libLLVM.so
שלא ניתן לחרוג ממנו בקלות
הוסר, הספק צריך להעתיק את bcc
(וכל הקבצים שאינם LL-NDK
של יחסי התלות, כולל libLLVM.so
, libbcc.so
)
מחיצה /vendor
.
בנוסף, הספקים צריכים לבצע את השינויים הבאים:
איור 7. שינויים במנהל ההתקן של הספק.
- העתקת
libclcore.bc
אל המחיצה/vendor
. הזה מבטיחlibclcore.bc
,libLLVM.so
וגםlibbcc.so
מסונכרנים. - שינוי הנתיב לקובץ ההפעלה
bcc
על ידי הגדרהRsdCpuScriptImpl::BCC_EXE_PATH
מהטמעת ה-RS HAL.
מדיניות SELinux
מדיניות SELinux משפיעה גם על מנהל ההתקן וגם על קובצי ההפעלה של המהדר. הכול
למודולים של מנהלי התקנים צריך להיות את התווית same_process_hal_file
file_contexts
של המכשיר. לדוגמה:
/vendor/lib(64)?/libRSDriver_EXAMPLE\.so u:object_r:same_process_hal_file:s0
חובה לאפשר את הפעלת קובץ ההפעלה של המהדר על ידי תהליך של אפליקציה, כמו גם
עותק של עותק הספק בעותק מוסתר (/vendor/bin/bcc
). מוצרים לדוגמה:
device/vendor_foo/device_bar/sepolicy/file_contexts: /vendor/bin/bcc u:object_r:same_process_hal_file:s0
מכשירים מדור קודם
מכשירים מדור קודם הם מכשירים שעומדים בתנאים הבאים:
- הערך PRODUCT_SHIPPING_API_LEVEL נמוך מ-26.
- PRODUCT_FULL_TREBLE_OVERRIDE לא מוגדר.
במכשירים מדור קודם, ההגבלות לא נאכפות כאשר משדרגים ל-
Android מגרסה 8.0 ואילך, כלומר מנהלי ההתקנים יכולים להמשיך לקשר לספריות
ב-/system/lib[64]
. עם זאת, בגלל השינוי בארכיטקטורה
שקשור אל OVERRIDE_RS_DRIVER
,
חובה להתקין את android.hardware.renderscript@1.0-impl
ב
מחיצת /vendor
; אם לא עושים זאת, מאלצים את זמן הריצה של RenderScript
חלופה לנתיב ה-CPU.
מידע לגבי המניע להוצאה משימוש של השירות Renderscript זמין באתר המפתחים של Android בלוג: Android GPU Compute קדימה. הפרטים של המשאבים להוצאה משימוש כוללים את הפרטים הבאים:
- מעבר מ-Renderscript
- דוגמה של RenderScript Migration
- ערכת הכלים להחלפה של Intrinsics README
- החלפה של IntrinsicsToolkit.kt