RenderScript

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

تستخدم الأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث إطار عمل RenderScript وواجهات برمجة التطبيقات لمستوى الحِزم (HAL) الخاصة بالمورّدين التالية:

الشكل 1: رمز المورّد الذي يرتبط بالمكتبات الداخلية

تشمل الاختلافات عن RenderScript في الإصدار 7.x من نظام التشغيل Android والإصدارات الأقدم ما يلي:

  • مثيلان من RenderScript libs الداخلية في إحدى العمليات. المجموعة الأولى مخصّصة لمسار التراجع لوحدة المعالجة المركزية (CPU) وتبدأ مباشرةً من /system/lib، والمجموعة الأخرى مخصّصة لمسار وحدة معالجة الرسومات (GPU) وتبدأ من /system/lib/vndk-sp.
  • يتم إنشاء مكتبات RS الداخلية في /system/lib كجزء من منصّة ويتم تعديلها عند ترقية system.img. ومع ذلك، يتم إنشاء مكتبات في /system/lib/vndk-sp لموفّر التطبيق ولا يتم تحديثها عند ترقية system.img (على الرغم من إمكانية تحديثها لحلّ مشكلة أمنية، يظلّ معرّف ABI كما هو).
  • يتم ربط رمز المورّد (واجهة برمجة التطبيقات لنظام RenderScript وبرنامج تشغيل RenderScript وbcc plugin) بمكتبات RenderScript الداخلية المتوفّرة في /system/lib/vndk-sp. لا يمكن ربطها بالمكتبات في directory /system/lib لأنّ المكتبات في هذا الدليل تم إنشاؤها لمنصّة وبالتالي قد لا تكون متوافقة مع رمز المورّد (أي قد تتم إزالة الرموز ). سيؤدي ذلك إلى استحالة استخدام إطار العمل فقط في عملية OTA.

التصميم

توضِّح الأقسام التالية تفاصيل تصميم RenderScript في الإصدار 8.0 من نظام Android والإصدارات الأحدث.

مكتبات RenderScript المتاحة للمورّدين

يسرد هذا القسم مكتبات RenderScript (المعروفة باسم Vendor NDK لـ HALs في العملية نفسها أو VNDK-SP) المتوفّرة لرمز المورّد والتي يمكن ربطها بها. ويوضّح أيضًا المكتبات الإضافية غير المرتبطة بـ RenderScript والتي يتم توفيرها أيضًا لرمز المورّد.

قد تختلف قائمة المكتبات التالية بين إصدارات Android، ولكنها ثابتة لإصدار Android معيّن. للحصول على قائمة محدّثة بالمكتبات المتاحة، يُرجى الرجوع إلى /system/etc/ld.config.txt.

مكتبات RenderScript مكتبات غير 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

إعداد مساحة اسم أداة الربط

يتم فرض قيد الربط الذي يمنع استخدام مكتبات ‎VNDK-SP من قِبل код المورّد أثناء التشغيل باستخدام مساحة اسم الرابط. (لمعرفة التفاصيل، يُرجى الاطّلاع على العرض التقديمي حول VNDK Design).

على جهاز يعمل بالإصدار 8.0 من نظام التشغيل Android أو إصدار أحدث، يتم تحميل جميع مستويات HALs للعمليات نفسها (SP-HALs) باستثناء RenderScript، ضمن مساحة اسم الرابط sphal. يتم تحميل RenderScript في مساحة الاسم rs الخاصة بـ RenderScript، وهو موقع يتيح تنفيذ إجراءات أكثر صرامة بشأن RenderScript libs. بما أنّ عملية تنفيذ RS تحتاج إلى تحميل رمز البت المجمّع، تتم إضافة /data/*/*.so إلى مسار مساحة имен rs (لا يُسمح لواجهات برمجة التطبيقات الأخرى لوحدة التحكّم في الأجهزة بالاستناد إلى مكتبات من ملف مشاركة data).

بالإضافة إلى ذلك، تسمح مساحة الاسم rs بمزيد من المكتبات مقارنةً بما تقدّمه مساحات الأسماء الأخرى. يتم عرض libmediandk.so وlibft2.so لمساحة الاسم rs لأنّ libRS_internal.so لها تبعية داخلية إلى هذه المكتبات.

الشكل 2: إعدادات مساحة الاسم لرابط البيانات

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

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

وحسب وجود وحدة بت RS_CONTEXT_LOW_LATENCY عند إنشاء سياق RS، يتم اختيار مسار وحدة المعالجة المركزية (CPU) أو وحدة معالجة الرسومات. عند اختيار مسار وحدة المعالجة المركزية، يتم dlopen libRS_internal.so (التنفيذ الرئيسي لإطار عمل RS) مباشرةً من مساحة اسم الرابط التلقائية التي يتم فيها توفير إصدار النظام الأساسي لمكتبات RS.

لا يتم استخدام تنفيذ RS HAL من المورّد على الإطلاق عند اتّخاذ مسار النسخ الاحتياطي لوحدة المعالجة المركزية ، ويتم إنشاء كائن RsContext باستخدام mVendorDriverName فارغ. تُعَد السمة libRSDriver.so (تلقائيًا) dlopen ويتم تحميل مكتبة برنامج التشغيل من مساحة الاسم default لأنّ رقم المتصل (libRS_internal.so) يتم أيضًا تحميله في مساحة الاسم default.

الشكل 3: المسار الاحتياطي لوحدة المعالجة المركزية (CPU).

مسار وحدة معالجة الرسومات

بالنسبة إلى مسار وحدة معالجة الرسومات، يتم تحميل libRS_internal.so بشكل مختلف. أولاً، يستخدم libRS.so android.hardware.renderscript@1.0.so (وlibhidltransport.so الأساسي) لتحميل android.hardware.renderscript@1.0-impl.so (وهو تنفيذ مورِّد لـ RS HAL) في مساحة اسم مختلفة للرابط تُسمّى sphal. بعد ذلك، يُنشئ dlopen libRS_internal.so في rs مساحة اسم أخرى للمنسق.

يمكن للمورّدين توفير برنامج تشغيل RS الخاص بهم من خلال ضبط علامة وقت الإنشاء OVERRIDE_RS_DRIVER، والتي يتم تضمينها في تنفيذ hardware/interfaces/renderscript/1.0/default/Context.cpp (HAL) لوحدة معالجة الرسومات. ثم يتم dlopen اسم برنامج التشغيل هذا لسياق RS في مسار وحدة معالجة الرسومات.

يتم تفويض إنشاء عنصر RsContext إلى عملية تنفيذ RS HAL. يُعيد HAL الاتصال بإطار عمل RS باستخدام دالة rsContextCreateVendor() مع اسم برنامج التشغيل لاستخدامه كوسيطة. بعد ذلك، تحمِّل إطار عمل RS برنامج التشغيل المحدَّد عند بدء RsContext. في هذه الحالة، يتم تحميل مكتبة برامج التشغيل في مساحة الاسم rs لأنّه تم إنشاء RsContext العنصر داخل مساحة الاسم rs و/vendor/lib في مسار البحث لمساحة الاسم.

الشكل 4: مسار العنصر الاحتياطي لوحدة معالجة الرسومات

عند الانتقال من مساحة الاسم default إلى مساحة الاسم sphal، يستخدم libhidltransport.so دالة android_load_sphal_library() لطلب ربط libhidltransport.so الديناميكي بشكل صريح لتحميل مكتبة -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 هي عملية نظام في directory /system/bin، يمكن اعتبار مكتبة bcc plugin HAL للمورّد (أي HAL للمورّد يمكن تحميله مباشرةً في عملية النظام بدون ربطه). بصفتها مكتبة SP-HAL، توفّر مكتبة bcc-plugin ما يلي:

  • لا يمكن الربط بمكتبات إطار العمل فقط مثل libLLVM.so.
  • يمكن ربطها بمكتبات VNDK-SP المتاحة فقط للمورّد.

يتم فرض هذا القيد عن طريق تحميل bcc plugin في مساحة الاسم sphal باستخدام الدالة android_sphal_load_library(). في الإصدارات السابقة من Android، تم تحديد اسم المكوّن الإضافي باستخدام الخيار -load وتم تحميل المكتبة باستخدام dlopen() البسيط من libLLVM.so. في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، يتم تحديد ذلك في خيار -plugin ويتم تحميل المكتبة مباشرةً من قِبل bcc نفسه. يفعِّل هذا الخيار مسارًا غير خاص بنظام Android يؤدي إلى مشروع LLVM المفتوح المصدر.

الشكل 5: يتم تحميل المكوّن الإضافي bcc، الإصدار 7.x من نظام التشغيل Android والإصدارات الأقدم.



الشكل 6: تحميل مكوّن bcc الإضافي، الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث

البحث عن مسارات ld.mc

عند تنفيذ ld.mc، يتم إرسال بعض رموز libs لوقت تشغيل RS كإدخالات إلى أداة الربط. يتم ربط رمز الرموز الثنائية لنظام التشغيل Real-time Operating System (RS) من التطبيق بمكتبات وقت التشغيل وعند تحميل الرمز المُحوَّل إلى رمز ثنائي في عملية التطبيق، يتم ربط مكتبات وقت التشغيل ديناميكيًا مرة أخرى من الرمز المُحوَّل.

تشمل مكتبات وقت التشغيل ما يلي:

  • 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 واستخدام dladdr() لربط مسار الملف بالعنوان.

سياسة SELinux

نتيجةً للتغييرات في سياسة SELinux في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، عليك اتّباع قواعد محدّدة (يتم فرضها من خلال neverallows) عند تصنيف الملفات الإضافية في قسم vendor:

  • يجب أن يكون vendor_file هو التصنيف التلقائي لجميع الملفات في القسم vendor. تتطلّب سياسة المنصة ذلك للوصول إلى عمليات تنفيذ HAL للمرور.
  • يجب أن تحتوي كل exec_types جديدة تمت إضافتها إلى قسم vendor من خلال سياسة SEPolicy الخاصة بالمورّد على سمة vendor_file_type. ويتم فرض ذلك من خلال neverallows.
  • لتجنُّب حدوث تعارضات مع تحديثات المنصة أو الإطار في المستقبل، تجنَّب تصنيف الملفات بغير exec_types في قسم vendor.
  • يجب تصنيف جميع العناصر الاعتمادية في المكتبة الخاصة بـ HALs للعملية نفسها التي يحدّدها AOSP على أنّها same_process_hal_file.

للاطّلاع على تفاصيل حول سياسة SELinux، يُرجى الاطّلاع على مقالة نظام التشغيل Linux المحسَّن للأمان في Android.

توافق ABI لرمز البت

في حال عدم إضافة واجهات برمجة تطبيقات جديدة، ما يعني عدم ترقية إصدار HAL، ستستمر إطارات عمل RS في استخدام برنامج تشغيل وحدة معالجة الرسومات الحالية (HAL 1.0).

بالنسبة إلى التغييرات البسيطة في HAL (HAL 1.1) التي لا تؤثّر في رمز البت، يجب أن تلجأ الإطارات الأساسية إلى وحدة المعالجة المركزية (CPU) لاستخدام واجهات برمجة التطبيقات المُضافة حديثًا هذه ومواصلة استخدام برنامج تشغيل وحدة معالجة الرسومات (HAL 1.0) في مكان آخر.

بالنسبة إلى تغييرات HAL الرئيسية (HAL 2.0) التي تؤثر في تجميع أو ربط رموز بت، يجب أن تختار أُطر عمل RS عدم تحميل برامج تشغيل وحدة معالجة الرسومات التي يوفّرها المورّد، وبدلاً من ذلك تستخدم مسار وحدة المعالجة المركزية (CPU) أو Vulkan للتسريع.

يتم استخدام رمز البت RenderScript على ثلاث مراحل:

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

بالإضافة إلى HAL، واجهات برمجة التطبيقات لوقت التشغيل والرموز المصدَّرة هي أيضًا واجهات. لم تتغيّر أي من الواجهات منذ الإصدار 7.0 من نظام التشغيل Android (واجهة برمجة التطبيقات 24)، ولا توجد خطط فورية لتغييرها في الإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث. ومع ذلك، إذا تغيّرت واجهة العميل، ستزداد أيضًا إصدارات HAL.

عمليات تنفيذ المورّدين

يتطلّب الإصدار 8.0 من Android والإصدارات الأحدث إجراء بعض التغييرات على برنامج تشغيل وحدة معالجة الرسومات لكي يعمل بشكلٍ سليم.

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

  • يجب ألّا تعتمد وحدات برامج التشغيل على أي مكتبات نظام غير مدرَجة في القائمة.
  • يجب أن يقدّم برنامج التشغيل android.hardware.renderscript@1.0-impl_{NAME} الخاص به أو أن يفصح عن عملية التنفيذ التلقائية android.hardware.renderscript@1.0-impl كعنصر يعتمد عليها.
  • ويُعدّ استخدام libRSDriver.so لوحدة المعالجة المركزية (CPU) مثالاً جيدًا على كيفية إزالة التبعيات غير التابعة لـ VNDK-SP.

محول رمز Bitcode

يمكنك تجميع رمز RenderScript الثنائي لبرنامج تشغيل المورّد بطريقتَين:

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

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

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

الشكل 7. التغييرات في برنامج تشغيل المورّد

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

يجب أن يكون بإمكان عملية التطبيق استدعاء الملف التنفيذي للمجمِّع، كما هو الحال مع نسخة المورّد من bcc (/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 من الآن فصاعدًا. تتضمّن معلومات المرجع المتعلّقة بإيقاف هذه الميزة نهائيًا ما يلي: