RenderScript هو إطار عمل لتشغيل المهام الحسابية المكثفة بأداء عالٍ على Android. وهو مصمم للاستخدام مع العمليات الحسابية المتوازية للبيانات، على الرغم من أن أحمال العمل التسلسلية يمكن أن تستفيد أيضًا. يعمل وقت تشغيل RenderScript على موازنة العمل عبر المعالجات المتوفرة على الجهاز، مثل وحدات المعالجة المركزية متعددة النواة ووحدات معالجة الرسومات، مما يتيح للمطورين التركيز على التعبير عن الخوارزميات بدلاً من جدولة العمل. يعد RenderScript مفيدًا بشكل خاص للتطبيقات التي تقوم بمعالجة الصور أو التصوير الحسابي أو رؤية الكمبيوتر.
تستخدم الأجهزة التي تعمل بنظام التشغيل Android 8.0 والإصدارات الأحدث إطار عمل RenderScript وأنظمة HALs للموردين التالية:
تشمل الاختلافات عن RenderScript في Android 7.x والإصدارات الأقدم ما يلي:
- حالتان من libs الداخلية لـ RenderScript في العملية. مجموعة واحدة مخصصة للمسار الاحتياطي لوحدة المعالجة المركزية وهي مباشرة من
/system/lib
؛ المجموعة الأخرى مخصصة لمسار GPU وهي من/system/lib/vndk-sp
. - تم إنشاء مكتبات RS الداخلية في
/system/lib
كجزء من النظام الأساسي ويتم تحديثها مع ترقيةsystem.img
. ومع ذلك، فإن libs الموجودة في/system/lib/vndk-sp
مصممة للمورد ولا يتم تحديثها عند ترقيةsystem.img
(بينما يمكن تحديثها لإصلاح الأمان، تظل واجهة ABI الخاصة بها كما هي). - يتم ربط رمز البائع (RS HAL، وRS driver،
bcc plugin
) بمكتبات RenderScript الداخلية الموجودة في/system/lib/vndk-sp
. لا يمكنهم الارتباط بالمكتبات الموجودة في/system/lib
لأن المكتبات الموجودة في هذا الدليل مصممة للنظام الأساسي وبالتالي قد لا تكون متوافقة مع كود البائع (أي قد تتم إزالة الرموز). إن القيام بذلك من شأنه أن يجعل استخدام OTA للإطار فقط أمرًا مستحيلًا.
تصميم
توضح الأقسام التالية تفاصيل تصميم RenderScript في Android 8.0 والإصدارات الأحدث.
مكتبات RenderScript متاحة للبائعين
يسرد هذا القسم مكتبات RenderScript (المعروفة باسم Vendor NDK لـ HALs لنفس العملية أو VNDK-SP) المتوفرة لتعليمات البائع البرمجية والتي يمكن ربطها بها. كما أنه يعرض تفاصيل المكتبات الإضافية التي لا علاقة لها بـ RenderScript ولكن يتم توفيرها أيضًا لرمز البائع.
على الرغم من أن قائمة المكتبات التالية قد تختلف بين إصدارات Android، إلا أنها غير قابلة للتغيير لإصدار Android محدد؛ للحصول على قائمة محدثة بالمكتبات المتاحة، راجع /system/etc/ld.config.txt
.
ريندرسكريبت ليبز | Libs غير تابعة لـ RenderScript |
---|---|
|
|
تكوين مساحة الاسم رابط
يتم فرض قيود الارتباط التي تمنع استخدام libs غير الموجودة في VNDK-SP بواسطة كود البائع في وقت التشغيل باستخدام مساحة اسم الرابط. (لمزيد من التفاصيل، راجع العرض التقديمي لتصميم VNDK .)
على جهاز يعمل بنظام التشغيل Android 8.0 والإصدارات الأحدث، يتم تحميل جميع شرائح HAL ذات العملية نفسها (SP-HALs) باستثناء RenderScript داخل مساحة اسم الرابط sphal
. يتم تحميل RenderScript في مساحة الاسم الخاصة بـ RenderScript rs
، وهو موقع يتيح تطبيقًا أكثر مرونة قليلاً لمكتبات RenderScript. نظرًا لأن تطبيق RS يحتاج إلى تحميل رمز البت المترجم، تتم إضافة /data/*/*.so
إلى مسار مساحة الاسم rs
(لا يُسمح لـ SP-HALs الأخرى بتحميل libs من قسم البيانات).
بالإضافة إلى ذلك، تسمح مساحة الاسم rs
بمكتبات أكثر مما توفره مساحات الأسماء الأخرى. يتعرض libmediandk.so
و libft2.so
لمساحة الاسم rs
لأن libRS_internal.so
لديه تبعية داخلية لهذه المكتبات.
تحميل برامج التشغيل
المسار الاحتياطي لوحدة المعالجة المركزية
اعتمادًا على وجود بت RS_CONTEXT_LOW_LATENCY
عند إنشاء سياق RS، يتم تحديد مسار وحدة المعالجة المركزية أو وحدة معالجة الرسومات. عند تحديد مسار وحدة المعالجة المركزية، يتم dlopen
libRS_internal.so
(التنفيذ الرئيسي لإطار عمل RS) مباشرةً من مساحة اسم الرابط الافتراضي حيث يتم توفير إصدار النظام الأساسي لمكتبات RS.
لا يتم استخدام تطبيق RS HAL من البائع على الإطلاق عند اتخاذ المسار الاحتياطي لوحدة المعالجة المركزية، ويتم إنشاء كائن RsContext
باستخدام mVendorDriverName
فارغ. libRSDriver.so
هو (افتراضيًا) dlopen
ed ويتم تحميل lib برنامج التشغيل من مساحة الاسم default
لأن المتصل ( libRS_internal.so
) يتم تحميله أيضًا في مساحة الاسم default
.
مسار 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
. ثم يقوم RS HAL dlopen
libRS_internal.so
في مساحة اسم رابط أخرى تسمى rs
.
يمكن للموردين توفير برنامج تشغيل RS الخاص بهم عن طريق تعيين علامة وقت البناء OVERRIDE_RS_DRIVER
، المضمنة في تطبيق RS HAL ( hardware/interfaces/renderscript/1.0/default/Context.cpp
). يتم بعد ذلك dlopen
اسم برنامج التشغيل هذا لسياق RS لمسار GPU.
يتم تفويض إنشاء كائن RsContext
إلى تطبيق RS HAL. يستدعي HAL مرة أخرى إلى إطار عمل RS باستخدام الدالة rsContextCreateVendor()
مع اسم برنامج التشغيل لاستخدامه كوسيطة. يقوم إطار عمل RS بعد ذلك بتحميل برنامج التشغيل المحدد عند تهيئة RsContext
. في هذه الحالة، يتم تحميل مكتبة برنامج التشغيل في مساحة الاسم rs
لأنه تم إنشاء كائن RsContext
داخل مساحة الاسم rs
ويكون /vendor/lib
في مسار البحث لمساحة الاسم.
عند الانتقال من مساحة الاسم 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
:
- لا يمكن الارتباط بمكتبات إطار العمل فقط مثل
libLLVM.so
. - يمكن الارتباط بمكتبات VNDK-SP المتاحة للبائع فقط.
يتم فرض هذا القيد عن طريق تحميل bcc plugin
في مساحة الاسم sphal
باستخدام وظيفة android_sphal_load_library()
. في الإصدارات السابقة من Android، تم تحديد اسم المكون الإضافي باستخدام خيار -load
وتم تحميل lib باستخدام dlopen()
البسيط بواسطة libLLVM.so
. في نظام Android 8.0 والإصدارات الأحدث، يتم تحديد ذلك في خيار -plugin
ويتم تحميل lib مباشرة بواسطة bcc
نفسها. يمكّن هذا الخيار مسارًا غير خاص بنظام Android إلى مشروع LLVM مفتوح المصدر.
مسارات البحث عن ld.mc
عند تنفيذ ld.mc
، يتم توفير بعض libs لوقت تشغيل RS كمدخلات للرابط. يتم ربط رمز بت RS من التطبيق مع libs وقت التشغيل وعندما يتم تحميل رمز البت المحول في عملية التطبيق، يتم ربط libs وقت التشغيل مرة أخرى ديناميكيًا من رمز البت المحول.
تتضمن libs وقت التشغيل ما يلي:
-
libcompiler_rt.so
-
libm.so
-
libc.so
- برنامج تشغيل RS (إما
libRSDriver.so
أوOVERRIDE_RS_DRIVER
)
عند تحميل رمز البت المترجم في عملية التطبيق، قم بتوفير نفس المكتبة التي تم استخدامها بواسطة ld.mc
. وإلا، فقد لا يجد رمز البت المترجم الرمز الذي كان متاحًا عندما تم ربطه.
للقيام بذلك، يستخدم إطار عمل RS مسارات بحث مختلفة لمكتبات وقت التشغيل عند تنفيذ ld.mc
، اعتمادًا على ما إذا كان إطار عمل RS نفسه قد تم تحميله من /system/lib
أو من /system/lib/vndk-sp
. يمكن تحديد ذلك من خلال قراءة عنوان رمز عشوائي لـ RS Framework lib واستخدام dladdr()
للحصول على مسار الملف المعين للعنوان.
سياسة سيلينوكس
نتيجة لتغييرات سياسة SELinux في Android 8.0 والإصدارات الأحدث، يجب عليك اتباع قواعد محددة (يتم فرضها من خلال neverallows
) عند تصنيف الملفات الإضافية في قسم vendor
:
- يجب أن يكون
vendor_file
هو التسمية الافتراضية لجميع الملفات الموجودة في قسمvendor
. تتطلب سياسة النظام الأساسي هذا للوصول إلى تطبيقات العبور HAL. - يجب أن تحتوي جميع
exec_types
الجديدة التي تمت إضافتها في قسمvendor
من خلال البائع SEPolicy على سمةvendor_file_type
. يتم فرض ذلك من خلالneverallows
. - لتجنب التعارضات مع تحديثات النظام الأساسي/إطار العمل المستقبلية، تجنب تسمية الملفات بخلاف
exec_types
في قسمvendor
. - يجب تسمية جميع تبعيات المكتبة لنفس العمليات التي تم تحديدها من قبل AOSP باسم
same_process_hal_file
.
للحصول على تفاصيل حول سياسة SELinux، راجع Linux المحسّن للأمان في Android .
توافق ABI مع رمز البت
إذا لم تتم إضافة واجهات برمجة تطبيقات جديدة، مما يعني عدم وجود زيادة في إصدار HAL، فستستمر أطر عمل RS في استخدام برنامج تشغيل GPU (HAL 1.0) الحالي.
بالنسبة إلى تغييرات HAL البسيطة (HAL 1.1) التي لا تؤثر على رمز البت، يجب أن ترجع أطر العمل إلى وحدة المعالجة المركزية (CPU) لواجهات برمجة التطبيقات المضافة حديثًا هذه وتستمر في استخدام برنامج تشغيل GPU (HAL 1.0) في مكان آخر.
بالنسبة إلى تغييرات HAL الرئيسية (HAL 2.0) التي تؤثر على تجميع/ربط رمز البت، يجب على أطر عمل RS اختيار عدم تحميل برامج تشغيل GPU المقدمة من البائع واستخدام مسار وحدة المعالجة المركزية أو Vulkan بدلاً من ذلك للتسريع.
يتم استهلاك كود RenderScript الثنائي على ثلاث مراحل:
منصة | تفاصيل |
---|---|
تجميع |
|
وصلة |
|
حمولة |
|
بالإضافة إلى HAL، تعد واجهات برمجة تطبيقات وقت التشغيل والرموز المصدرة أيضًا واجهات. لم تتغير أي من الواجهتين منذ 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
هو التبعية الخاصة به. - يعد تنفيذ وحدة المعالجة المركزية
libRSDriver.so
مثالًا جيدًا لكيفية إزالة التبعيات غير VNDK-SP.
مترجم رمز البت
يمكنك تجميع رمز بت RenderScript لبرنامج تشغيل البائع بطريقتين:
- قم باستدعاء برنامج التحويل البرمجي RenderScript الخاص بالمورد في
/vendor/bin/
(الطريقة المفضلة لتجميع GPU). كما هو الحال مع وحدات التشغيل الأخرى، لا يمكن لبرنامج التحويل البرمجي الثنائي للمورد أن يعتمد على أي مكتبة نظام غير موجودة في قائمة RenderScript libs المتاحة للبائعين . - استدعاء نسخة مخفية للنظام:
/system/bin/bcc
معbcc plugin
الوجهة الذي يوفره البائع؛ لا يمكن أن يعتمد هذا البرنامج المساعد على أي مكتبة نظام غير موجودة في قائمة RenderScript libs المتاحة للبائعين .
إذا كان bcc plugin
يحتاج إلى التدخل في تجميع وحدة المعالجة المركزية ولا يمكن إزالة اعتماده على libLLVM.so
بسهولة، فيجب على البائع نسخ bcc
(وجميع التبعيات غير LL-NDK، بما في ذلك libLLVM.so
و libbcc.so
) إلى /vendor
.
بالإضافة إلى ذلك، يحتاج البائعون إلى إجراء التغييرات التالية:
- انسخ
libclcore.bc
إلى قسم/vendor
. وهذا يضمن مزامنةlibclcore.bc
وlibLLVM.so
وlibbcc.so
. - قم بتغيير المسار إلى الملف القابل للتنفيذ
bcc
عن طريق تعيينRsdCpuScriptImpl::BCC_EXE_PATH
من تطبيق RS HAL.
سياسة سيلينوكس
تؤثر سياسة 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 إلى مسار وحدة المعالجة المركزية.
للحصول على معلومات حول الدافع وراء إيقاف Renderscript، راجع مدونة مطوري Android: Android GPU Compute Going Forward . تتضمن معلومات الموارد الخاصة بهذا الإهمال ما يلي:
- الهجرة من Renderscript
- نموذج ترحيل RenderScript
- مجموعة أدوات استبدال Intrinsics README
- مجموعة أدوات الاستبدال الجوهرية