عرض

RenderScript هو إطار عمل لتشغيل المهام الحسابية المكثفة بأداء عالٍ على Android. وهو مصمم للاستخدام مع العمليات الحسابية المتوازية للبيانات، على الرغم من أن أحمال العمل التسلسلية يمكن أن تستفيد أيضًا. يعمل وقت تشغيل RenderScript على موازنة العمل عبر المعالجات المتوفرة على الجهاز، مثل وحدات المعالجة المركزية متعددة النواة ووحدات معالجة الرسومات، مما يتيح للمطورين التركيز على التعبير عن الخوارزميات بدلاً من جدولة العمل. يعد RenderScript مفيدًا بشكل خاص للتطبيقات التي تقوم بمعالجة الصور أو التصوير الحسابي أو رؤية الكمبيوتر.

تستخدم الأجهزة التي تعمل بنظام التشغيل Android 8.0 والإصدارات الأحدث إطار عمل RenderScript وأنظمة HALs للموردين التالية:

الشكل 1. رمز البائع الذي يرتبط بالمكتبات الداخلية

تشمل الاختلافات عن 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
  • android.hardware.graphics.renderscript@1.0.so
  • libRS_internal.so
  • libRSCpuRef.so
  • libblas.so
  • libbcinfo.so
  • libcompiler_rt.so
  • libRSDriver.so
  • libc.so
  • libm.so
  • libdl.so
  • libstdc++.so
  • liblog.so
  • libnativewindow.so
  • libsync.so
  • libvndksupport.so
  • libbase.so
  • libc++.so
  • libcutils.so
  • libutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidltransport.so
  • libhwbinder.so
  • liblzma.so
  • libz.so
  • libEGL.so
  • libGLESv1_CM.so
  • libGLESv2.so

تكوين مساحة الاسم رابط

يتم فرض قيود الارتباط التي تمنع استخدام 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 لديه تبعية داخلية لهذه المكتبات.

الشكل 2. تكوين مساحة الاسم للرابط

تحميل برامج التشغيل

المسار الاحتياطي لوحدة المعالجة المركزية

اعتمادًا على وجود بت 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 .

الشكل 4. المسار الاحتياطي لوحدة المعالجة المركزية

مسار 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 في مسار البحث لمساحة الاسم.

الشكل 5. المسار الاحتياطي لوحدة معالجة الرسومات

عند الانتقال من مساحة الاسم 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 مفتوح المصدر.

الشكل 6. تحميل البرنامج المساعد لنسخة مخفية الوجهة، Android 7.x والإصدارات الأقدم


الشكل 7. تحميل البرنامج الإضافي لنسخة مخفية الوجهة، Android 8.0 والإصدارات الأحدث

مسارات البحث عن 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 الثنائي على ثلاث مراحل:

منصة تفاصيل
تجميع
  • يجب أن يكون رمز بت الإدخال (.bc) لـ bcc بتنسيق رمز بت LLVM 3.2 ويجب أن يكون bcc متوافقًا مع التطبيقات (القديمة) الحالية.
  • ومع ذلك، يمكن أن تتغير البيانات الوصفية في .bc (قد تكون هناك وظائف وقت تشغيل جديدة، على سبيل المثال، محددات التخصيص ∓ الحروف، والوظائف الرياضية، وما إلى ذلك). يوجد جزء من وظائف وقت التشغيل في libclcore.bc ، وجزء منها موجود في LibRSDriver أو ما يعادله من البائع.
  • تتطلب وظائف وقت التشغيل الجديدة أو تغييرات البيانات التعريفية المعطلة زيادة مستوى واجهة برمجة التطبيقات الخاصة بالرمز البتي. ونظرًا لأن برامج تشغيل الموردين لن تكون قادرة على استهلاكه، فيجب أيضًا زيادة إصدار HAL.
  • قد يكون لدى البائعين مترجمين خاصين بهم، ولكن الاستنتاجات/المتطلبات الخاصة bcc تنطبق أيضًا على هؤلاء المجمعين.
وصلة
  • سيتم ربط الملف .o المترجم مع برنامج تشغيل البائع، على سبيل المثال، libRSDriver_foo.so و libcompiler_rt.so . سيتم ربط مسار وحدة المعالجة المركزية بـ libRSDriver.so .
  • إذا كان .o يتطلب واجهة برمجة تطبيقات جديدة لوقت التشغيل من libRSDriver_foo ، فيجب تحديث برنامج تشغيل البائع لدعمه.
  • قد يكون لدى بعض البائعين روابط خاصة بهم، ولكن حجة ld.mc تنطبق عليهم أيضًا.
حمولة
  • يقوم libRSCpuRef بتحميل الكائن المشترك. إذا كانت هناك تغييرات على هذه الواجهة، فستكون هناك حاجة إلى ترقية إصدار HAL.
  • سيعتمد البائعون إما على libRSCpuRef لتحميل الكائن المشترك، أو تنفيذ كائن خاص بهم.

بالإضافة إلى 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 لبرنامج تشغيل البائع بطريقتين:

  1. قم باستدعاء برنامج التحويل البرمجي RenderScript الخاص بالمورد في /vendor/bin/ (الطريقة المفضلة لتجميع GPU). كما هو الحال مع وحدات التشغيل الأخرى، لا يمكن لبرنامج التحويل البرمجي الثنائي للمورد أن يعتمد على أي مكتبة نظام غير موجودة في قائمة RenderScript libs المتاحة للبائعين .
  2. استدعاء نسخة مخفية للنظام: /system/bin/bcc مع bcc plugin الوجهة الذي يوفره البائع؛ لا يمكن أن يعتمد هذا البرنامج المساعد على أي مكتبة نظام غير موجودة في قائمة RenderScript libs المتاحة للبائعين .

إذا كان bcc plugin يحتاج إلى التدخل في تجميع وحدة المعالجة المركزية ولا يمكن إزالة اعتماده على libLLVM.so بسهولة، فيجب على البائع نسخ bcc (وجميع التبعيات غير LL-NDK، بما في ذلك libLLVM.so و libbcc.so ) إلى /vendor .

بالإضافة إلى ذلك، يحتاج البائعون إلى إجراء التغييرات التالية:

الشكل 8. التغييرات في برنامج تشغيل البائع
  1. انسخ libclcore.bc إلى قسم /vendor . وهذا يضمن مزامنة libclcore.bc و libLLVM.so و libbcc.so .
  2. قم بتغيير المسار إلى الملف القابل للتنفيذ 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

الأجهزة القديمة

الأجهزة القديمة هي تلك التي تستوفي الشروط التالية:

  1. PRODUCT_SHIPPING_API_LEVEL أقل من 26.
  2. لم يتم تعريف 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 . تتضمن معلومات الموارد الخاصة بهذا الإهمال ما يلي: