রেন্ডারস্ক্রিপ্ট

রেন্ডারস্ক্রিপ্ট হলো অ্যান্ড্রয়েডে উচ্চ পারফরম্যান্সে গণনা-নিবিড় কাজ চালানোর জন্য একটি ফ্রেমওয়ার্ক। এটি ডেটা-প্যারালাল কম্পিউটেশনের জন্য ডিজাইন করা হয়েছে, যদিও সিরিয়াল ওয়ার্কলোডও এর থেকে উপকৃত হতে পারে। রেন্ডারস্ক্রিপ্ট রানটাইম একটি ডিভাইসে উপলব্ধ প্রসেসর, যেমন মাল্টি-কোর সিপিইউ এবং জিপিইউ জুড়ে কাজকে সমান্তরালভাবে চালায়, যা ডেভেলপারদের কাজের সময়সূচী নির্ধারণের পরিবর্তে অ্যালগরিদম প্রকাশের উপর মনোযোগ দিতে সক্ষম করে। রেন্ডারস্ক্রিপ্ট বিশেষত ইমেজ প্রসেসিং, কম্পিউটেশনাল ফটোগ্রাফি বা কম্পিউটার ভিশন সম্পাদনকারী অ্যাপগুলির জন্য উপযোগী।

অ্যান্ড্রয়েড ৮.০ এবং তার পরবর্তী সংস্করণে চালিত ডিভাইসগুলো নিম্নলিখিত রেন্ডারস্ক্রিপ্ট ফ্রেমওয়ার্ক এবং ভেন্ডর এইচএএল (HAL) ব্যবহার করে:

চিত্র ১. অভ্যন্তরীণ লাইব্রেরির সাথে ভেন্ডর কোডের সংযোগ।

Android 7.x এবং এর পূর্ববর্তী সংস্করণগুলিতে RenderScript-এর সাথে পার্থক্যগুলো হলো:

  • একটি প্রসেসে RenderScript-এর অভ্যন্তরীণ লাইব্রেরির দুটি ইনস্ট্যান্স থাকে। একটি সেট সিপিইউ ফলব্যাক পাথের জন্য এবং এটি সরাসরি /system/lib থেকে নেওয়া হয়; অন্য সেটটি জিপিইউ পাথের জন্য এবং এটি /system/lib/vndk-sp থেকে নেওয়া হয়।
  • /system/lib এ থাকা RS-এর অভ্যন্তরীণ লাইব্রেরিগুলো প্ল্যাটফর্মের অংশ হিসেবে বিল্ড করা হয় এবং system.img আপগ্রেড করার সাথে সাথে আপডেট হয়। তবে, /system/lib/vndk-sp তে থাকা লাইব্রেরিগুলো ভেন্ডরের জন্য বিল্ড করা হয় এবং system.img আপগ্রেড করার সময় আপডেট হয় না (যদিও কোনো নিরাপত্তাজনিত ত্রুটি সংশোধনের জন্য এগুলো আপডেট করা যেতে পারে, এদের ABI একই থাকে)।
  • ভেন্ডর কোড (RS HAL, RS ড্রাইভার, এবং bcc plugin ) /system/lib/vndk-sp তে অবস্থিত RenderScript-এর অভ্যন্তরীণ লাইব্রেরিগুলোর সাথে লিঙ্ক করা থাকে। এগুলো /system/lib লাইব্রেরিগুলোর সাথে লিঙ্ক করা যায় না, কারণ ঐ ডিরেক্টরির লাইব্রেরিগুলো প্ল্যাটফর্মের জন্য বিল্ড করা হয়েছে এবং তাই ভেন্ডর কোডের সাথে সামঞ্জস্যপূর্ণ নাও হতে পারে (যেমন, সিম্বলগুলো সরিয়ে ফেলা হতে পারে)। এমনটা করলে শুধুমাত্র ফ্রেমওয়ার্ক-ভিত্তিক OTA অসম্ভব হয়ে পড়বে।

ডিজাইন

নিম্নলিখিত বিভাগগুলিতে অ্যান্ড্রয়েড ৮.০ এবং তার পরবর্তী সংস্করণগুলিতে RenderScript ডিজাইন বিস্তারিতভাবে বর্ণনা করা হয়েছে।

ভেন্ডরদের জন্য উপলব্ধ RenderScript লাইব্রেরি

এই বিভাগে RenderScript লাইব্রেরিগুলির (যা Vendor NDK for Same-Process HALs বা VNDK-SP নামে পরিচিত) একটি তালিকা দেওয়া হয়েছে, যেগুলি ভেন্ডর কোডের জন্য উপলব্ধ এবং যেগুলির সাথে লিঙ্ক করা যায়। এছাড়াও, এতে RenderScript-এর সাথে সম্পর্কহীন কিন্তু ভেন্ডর কোডে সরবরাহ করা হয় এমন অতিরিক্ত লাইব্রেরিগুলিরও বিস্তারিত বিবরণ দেওয়া হয়েছে।

যদিও লাইব্রেরির নিম্নলিখিত তালিকাটি বিভিন্ন অ্যান্ড্রয়েড রিলিজের মধ্যে ভিন্ন হতে পারে, তবে একটি নির্দিষ্ট অ্যান্ড্রয়েড রিলিজের জন্য এটি অপরিবর্তনীয়; উপলব্ধ লাইব্রেরির একটি হালনাগাদ তালিকার জন্য, /system/etc/ld.config.txt দেখুন।

রেন্ডারস্ক্রিপ্ট লাইব্রেরি নন-রেন্ডারস্ক্রিপ্ট লাইব্রেরি
  • 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 ডিজাইন প্রেজেন্টেশনটি দেখুন।)

অ্যান্ড্রয়েড ৮.০ এবং তার পরবর্তী সংস্করণে চালিত ডিভাইসে, RenderScript ছাড়া বাকি সব Same-Process HAL (SP-HAL) sphal লিঙ্কার নেমস্পেসের ভেতরে লোড করা হয়। RenderScript লোড করা হয় RenderScript-এর জন্য নির্দিষ্ট rs নেমস্পেসে, যা RenderScript লাইব্রেরিগুলোর ক্ষেত্রে কিছুটা শিথিল নিয়মকানুন প্রয়োগের সুযোগ দেয়। যেহেতু RS ইমপ্লিমেন্টেশনকে কম্পাইল করা বিটকোড লোড করতে হয়, /data/*/*.so .so` rs নেমস্পেসের পাথে যুক্ত করা হয় (অন্যান্য SP-HAL-গুলোকে `data` পার্টিশন থেকে লাইব্রেরি লোড করার অনুমতি দেওয়া হয় না)।

এছাড়াও, rs নেমস্পেস অন্যান্য নেমস্পেসের তুলনায় আরও বেশি লাইব্রেরি ব্যবহারের সুযোগ দেয়। libmediandk.so এবং libft2.so লাইব্রেরি দুটি rs নেমস্পেসের আওতাভুক্ত, কারণ libRS_internal.so এই লাইব্রেরিগুলোর উপর একটি অভ্যন্তরীণ নির্ভরতা রয়েছে।

চিত্র ২. লিঙ্কারের জন্য নেমস্পেস কনফিগারেশন।

লোড ড্রাইভার

সিপিইউ ফলব্যাক পাথ

একটি RS কনটেক্সট তৈরি করার সময় RS_CONTEXT_LOW_LATENCY বিটটির উপস্থিতির উপর নির্ভর করে CPU অথবা GPU পাথ নির্বাচিত হয়। যখন CPU পাথ নির্বাচিত হয়, তখন libRS_internal.so (RS ফ্রেমওয়ার্কের প্রধান ইমপ্লিমেন্টেশন) সরাসরি ডিফল্ট লিঙ্কার নেমস্পেস থেকে dlopen করা হয়, যেখানে RS লাইব্রেরিগুলোর প্ল্যাটফর্ম সংস্করণ সরবরাহ করা থাকে।

যখন সিপিইউ ফলব্যাক পথটি অনুসরণ করা হয়, তখন ভেন্ডরের RS HAL ইমপ্লিমেন্টেশনটি মোটেও ব্যবহৃত হয় না এবং null mVendorDriverName সহ একটি RsContext অবজেক্ট তৈরি করা হয়। libRSDriver.so (ডিফল্টরূপে) dlopen করা হয় এবং ড্রাইভার লাইব্রেরিটি default নেমস্পেস থেকে লোড করা হয়, কারণ কলার ( libRS_internal.so ) নিজেও default নেমস্পেসে লোড করা থাকে।

চিত্র ৩. সিপিইউ ফলব্যাক পথ।

জিপিইউ পথ

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, rs নামক আরেকটি লিঙ্কার নেমস্পেসে libRS_internal.so কে dlopen ।

ভেন্ডররা বিল্ড টাইম ফ্ল্যাগ OVERRIDE_RS_DRIVER সেট করার মাধ্যমে তাদের নিজস্ব RS ড্রাইভার সরবরাহ করতে পারে, যা RS HAL ইমপ্লিমেন্টেশনে ( hardware/interfaces/renderscript/1.0/default/Context.cpp ) এমবেড করা থাকে। এরপর এই ড্রাইভার নামটি GPU পাথের জন্য RS কনটেক্সটে dlopen করা হয়।

RsContext অবজেক্ট তৈরির কাজটি RS HAL ইমপ্লিমেন্টেশনের উপর অর্পণ করা হয়। HAL, ব্যবহৃত ড্রাইভারের নামটি আর্গুমেন্ট হিসেবে দিয়ে rsContextCreateVendor() ফাংশনটির মাধ্যমে RS ফ্রেমওয়ার্ককে কলব্যাক করে। এরপর, RsContext ইনিশিয়ালাইজ হওয়ার সময় RS ফ্রেমওয়ার্ক নির্দিষ্ট ড্রাইভারটি লোড করে। এক্ষেত্রে, ড্রাইভার লাইব্রেরিটি rs নেমস্পেসের মধ্যে লোড হয়, কারণ RsContext অবজেক্টটি rs নেমস্পেসের ভেতরে তৈরি হয় এবং /vendor/lib নেমস্পেসটির সার্চ পাথে অবস্থিত।

চিত্র ৪. জিপিইউ ফলব্যাক পাথ।

default নেমস্পেস থেকে sphal নেমস্পেসে স্থানান্তরের সময়, libhidltransport.so তার android_load_sphal_library() ফাংশনটি ব্যবহার করে ডাইনামিক লিঙ্কারকে স্পষ্টভাবে sphal নেমস্পেস থেকে -impl.so লাইব্রেরিটি লোড করার নির্দেশ দেয়।

sphal নেমস্পেস থেকে rs নেমস্পেসে স্থানান্তরের সময়, /system/etc/ld.config.txt ফাইলের নিম্নলিখিত লাইনের মাধ্যমে পরোক্ষভাবে লোডিং সম্পন্ন করা হয়:

namespace.sphal.link.rs.shared_libs = libRS_internal.so

এই লাইনটি নির্দিষ্ট করে যে, যখন sphal নেমস্পেস থেকে libRS_internal.so লাইব্রেরিটি খুঁজে পাওয়া বা লোড করা যায় না, তখন ডাইনামিক লিঙ্কার যেন rs নেমস্পেস থেকে libRS_internal.so লোড করে (যা সবসময়ই ঘটে, কারণ sphal নেমস্পেস /system/lib/vndk-sp তে অনুসন্ধান করে না, যেখানে libRS_internal.so থাকে)। এই কনফিগারেশনের মাধ্যমে, নেমস্পেস পরিবর্তনের জন্য libRS_internal.so তে একটি সাধারণ dlopen() কলই যথেষ্ট।

বিসিসি প্লাগইন লোড করুন

bcc plugin হলো একটি ভেন্ডর-প্রদত্ত লাইব্রেরি যা bcc কম্পাইলারে লোড করা হয়। যেহেতু bcc হলো /system/bin ডিরেক্টরিতে অবস্থিত একটি সিস্টেম প্রসেস, তাই bcc plugin লাইব্রেরিকে একটি SP-HAL (অর্থাৎ, এমন একটি ভেন্ডর HAL যা বাইন্ডারাইজড না হয়েই সরাসরি সিস্টেম প্রসেসে লোড করা যায়) হিসেবে বিবেচনা করা যেতে পারে। একটি SP-HAL হিসেবে, bcc-plugin লাইব্রেরিটি:

  • libLLVM.so এর মতো ফ্রেমওয়ার্ক-ভিত্তিক লাইব্রেরিগুলোর সাথে লিঙ্ক করা যাবে না।
  • শুধুমাত্র বিক্রেতার কাছে উপলব্ধ VNDK-SP লাইব্রেরিগুলোর সাথেই লিঙ্ক করা যাবে।

android_sphal_load_library() ফাংশন ব্যবহার করে sphal নেমস্পেসে bcc plugin লোড করার মাধ্যমে এই সীমাবদ্ধতাটি কার্যকর করা হয়। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, -load অপশন ব্যবহার করে প্লাগইনের নাম নির্দিষ্ট করা হতো এবং libLLVM.so এর সহজ dlopen() ব্যবহার করে লাইব্রেরিটি লোড করা হতো। অ্যান্ড্রয়েড ৮.০ এবং তার পরবর্তী সংস্করণগুলিতে, এটি -plugin অপশনে নির্দিষ্ট করা হয় এবং লাইব্রেরিটি সরাসরি bcc নিজেই লোড করে। এই অপশনটি ওপেন সোর্স LLVM প্রজেক্টের জন্য একটি নন-অ্যান্ড্রয়েড-নির্দিষ্ট পাথ ব্যবহারের সুযোগ দেয়।

চিত্র ৫. বিসিসি প্লাগইন লোড করা, অ্যান্ড্রয়েড ৭.x এবং নিম্নতর সংস্করণ।



চিত্র ৬. বিসিসি প্লাগইন লোড করা, অ্যান্ড্রয়েড ৮.০ এবং উচ্চতর সংস্করণ।

ld.mc-এর জন্য পথ অনুসন্ধান করুন

ld.mc এক্সিকিউট করার সময়, কিছু RS রানটাইম লাইব্রেরি লিঙ্কারকে ইনপুট হিসেবে দেওয়া হয়। অ্যাপ থেকে আসা RS বিটকোড রানটাইম লাইব্রেরিগুলোর সাথে লিঙ্ক করা হয় এবং যখন রূপান্তরিত বিটকোডটি কোনো অ্যাপ প্রসেসে লোড করা হয়, তখন রানটাইম লাইব্রেরিগুলো সেই রূপান্তরিত বিটকোড থেকে পুনরায় ডায়নামিকভাবে লিঙ্ক করা হয়।

রানটাইম লাইব্রেরিগুলোর মধ্যে রয়েছে:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • আরএস ড্রাইভার (হয় libRSDriver.so অথবা OVERRIDE_RS_DRIVER )

অ্যাপ প্রসেসে কম্পাইল করা বিটকোড লোড করার সময়, ld.mc দ্বারা ব্যবহৃত হুবহু একই লাইব্রেরিটি সরবরাহ করুন। অন্যথায়, কম্পাইল করা বিটকোড এমন কোনো সিম্বল খুঁজে নাও পেতে পারে যা লিঙ্ক করার সময় উপলব্ধ ছিল।

এটি করার জন্য, rs ফ্রেমওয়ার্ক ld.mc এক্সিকিউট করার সময় রানটাইম লাইব্রেরিগুলোর জন্য ভিন্ন ভিন্ন সার্চ পাথ ব্যবহার করে, যা নির্ভর করে RS ফ্রেমওয়ার্কটি নিজে /system/lib থেকে লোড করা হচ্ছে নাকি /system/lib/vndk-sp থেকে। এটি নির্ধারণ করা যায় RS ফ্রেমওয়ার্ক লাইব্রেরির যেকোনো একটি সিম্বলের অ্যাড্রেস পড়ে এবং সেই অ্যাড্রেসের সাথে ম্যাপ করা ফাইল পাথটি পাওয়ার জন্য dladdr() ব্যবহার করে।

SELinux নীতি

Android 8.0 এবং তার পরবর্তী সংস্করণগুলিতে SELinux পলিসির পরিবর্তনের ফলে, vendor পার্টিশনে অতিরিক্ত ফাইল লেবেল করার সময় আপনাকে অবশ্যই নির্দিষ্ট কিছু নিয়ম (যা neverallows এর মাধ্যমে প্রয়োগ করা হয়) অনুসরণ করতে হবে:

  • vendor পার্টিশনের সমস্ত ফাইলের জন্য vendor_file অবশ্যই ডিফল্ট লেবেল হতে হবে। পাসথ্রু HAL ইমপ্লিমেন্টেশনগুলো অ্যাক্সেস করার জন্য প্ল্যাটফর্ম পলিসি অনুযায়ী এটি আবশ্যক।
  • ভেন্ডর SEPolicy-এর মাধ্যমে vendor পার্টিশনে যোগ করা সমস্ত নতুন exec_types অবশ্যই vendor_file_type অ্যাট্রিবিউট থাকতে হবে। এটি neverallows এর মাধ্যমে কার্যকর করা হয়।
  • ভবিষ্যতের প্ল্যাটফর্ম/ফ্রেমওয়ার্ক আপডেটের সাথে সংঘাত এড়াতে, vendor পার্টিশনে exec_types ফাইলটি ছাড়া অন্য কোনো ফাইল লেবেল করা থেকে বিরত থাকুন।
  • AOSP দ্বারা চিহ্নিত একই প্রসেস HAL-গুলোর জন্য সমস্ত লাইব্রেরি নির্ভরতাকে অবশ্যই same_process_hal_file হিসেবে লেবেল করতে হবে।

SELinux পলিসি সম্পর্কে বিস্তারিত জানতে, Android-এ নিরাপত্তা-বর্ধিত লিনাক্স দেখুন।

বিটকোডের জন্য ABI সামঞ্জস্যতা

যদি কোনো নতুন API যোগ করা না হয়, অর্থাৎ HAL ভার্সন আপগ্রেড না করা হয়, তাহলে RS ফ্রেমওয়ার্কগুলো বিদ্যমান GPU (HAL 1.0) ড্রাইভারটিই ব্যবহার করতে থাকবে।

বিটকোডকে প্রভাবিত করে না এমন ছোটখাটো HAL পরিবর্তনের (HAL 1.1) ক্ষেত্রে, ফ্রেমওয়ার্কগুলোর উচিত এই নতুন যুক্ত হওয়া API-গুলোর জন্য CPU-তে ফিরে যাওয়া এবং অন্যান্য ক্ষেত্রে GPU (HAL 1.0) ড্রাইভার ব্যবহার করা চালিয়ে যাওয়া।

বিটকোড কম্পাইলেশন/লিঙ্কিংকে প্রভাবিত করে এমন বড় ধরনের HAL পরিবর্তনের (HAL 2.0) ক্ষেত্রে, RS ফ্রেমওয়ার্কগুলোর উচিত ভেন্ডর-প্রদত্ত GPU ড্রাইভার লোড না করে, এর পরিবর্তে অ্যাক্সিলারেশনের জন্য CPU বা Vulkan পথ ব্যবহার করা।

RenderScript বিটকোড ব্যবহার তিনটি পর্যায়ে সম্পন্ন হয়:

মঞ্চ বিস্তারিত
সংকলন করুন
  • bcc এর জন্য ইনপুট বিটকোড (.bc) অবশ্যই 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 ছাড়াও, রানটাইম এপিআই এবং এক্সপোর্টেড সিম্বলগুলোও ইন্টারফেস। অ্যান্ড্রয়েড ৭.০ (এপিআই ২৪) থেকে এই দুটি ইন্টারফেসের কোনোটিই পরিবর্তিত হয়নি এবং অ্যান্ড্রয়েড ৮.০ ও তার পরবর্তী সংস্করণগুলোতে এটি পরিবর্তন করার কোনো তাৎক্ষণিক পরিকল্পনা নেই। তবে, যদি ইন্টারফেসটি পরিবর্তিত হয়, তাহলে HAL-এর ভার্সনও বৃদ্ধি পাবে।

বিক্রেতার বাস্তবায়ন

অ্যান্ড্রয়েড ৮.০ এবং এর পরবর্তী সংস্করণগুলোতে জিপিইউ ড্রাইভার সঠিকভাবে কাজ করার জন্য কিছু পরিবর্তনের প্রয়োজন হয়।

ড্রাইভার মডিউল

  • ড্রাইভার মডিউলগুলো তালিকায় নেই এমন কোনো সিস্টেম লাইব্রেরির উপর নির্ভর করতে পারবে না।
  • ড্রাইভারকে অবশ্যই তার নিজস্ব android.hardware.renderscript@1.0-impl_{NAME} প্রদান করতে হবে, অথবা ডিফল্ট ইমপ্লিমেন্টেশন android.hardware.renderscript@1.0-impl তার ডিপেন্ডেন্সি হিসেবে ঘোষণা করতে হবে।
  • সিপিইউ ইমপ্লিমেন্টেশন libRSDriver.so হলো VNDK-SP-বহির্ভূত নির্ভরতাগুলো কীভাবে অপসারণ করতে হয় তার একটি ভালো উদাহরণ।

বিটকোড কম্পাইলার

আপনি ভেন্ডর ড্রাইভারের জন্য RenderScript বিটকোড দুটি উপায়ে কম্পাইল করতে পারেন:

  1. /vendor/bin/ এ থাকা ভেন্ডর-নির্দিষ্ট RenderScript কম্পাইলারটি চালু করুন (এটি GPU কম্পাইলেশনের জন্য পছন্দের পদ্ধতি)। অন্যান্য ড্রাইভার মডিউলের মতোই, ভেন্ডর কম্পাইলার বাইনারিটি এমন কোনো সিস্টেম লাইব্রেরির উপর নির্ভর করতে পারে না, যা ভেন্ডরদের জন্য উপলব্ধ RenderScript লাইব্রেরির তালিকায় নেই।
  2. ভেন্ডর-প্রদত্ত bcc plugin ব্যবহার করে সিস্টেম bcc: /system/bin/bcc চালু করুন; এই প্লাগইনটি এমন কোনো সিস্টেম লাইব্রেরির উপর নির্ভর করতে পারবে না যা ভেন্ডরদের জন্য উপলব্ধ RenderScript লাইব্রেরির তালিকায় নেই।

যদি ভেন্ডর bcc plugin সিপিইউ কম্পাইলেশনে হস্তক্ষেপ করে এবং libLLVM.so এর উপর এর নির্ভরতা সহজে অপসারণ করা না যায়, তবে ভেন্ডরের উচিত bcc (এবং libLLVM.so ও libbcc.so সহ LL-NDK-বহির্ভূত সমস্ত নির্ভরতা) /vendor পার্টিশনে কপি করা।

এছাড়াও, বিক্রেতাদের নিম্নলিখিত পরিবর্তনগুলি করতে হবে:

চিত্র ৭. ভেন্ডর ড্রাইভারের পরিবর্তনসমূহ।

  1. libclcore.bc ফাইলটি /vendor পার্টিশনে কপি করুন। এর ফলে libclcore.bc , libLLVM.so এবং libbcc.so সিঙ্ক অবস্থায় থাকবে।
  2. RS HAL ইমপ্লিমেন্টেশন থেকে RsdCpuScriptImpl::BCC_EXE_PATH সেট করে bcc এক্সিকিউটেবলের পাথ পরিবর্তন করুন।

SELinux নীতি

SELinux পলিসি ড্রাইভার এবং কম্পাইলার উভয় এক্সিকিউটেবলকেই প্রভাবিত করে। ডিভাইসের file_contexts এ সমস্ত ড্রাইভার মডিউলকে অবশ্যই same_process_hal_file হিসেবে লেবেল করতে হবে। উদাহরণস্বরূপ:

/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 ২৬-এর চেয়ে কম।
  2. PRODUCT_FULL_TREBLE_OVERRIDE সংজ্ঞায়িত নয়।

পুরানো ডিভাইসগুলির জন্য, Android 8.0 এবং উচ্চতর সংস্করণে আপগ্রেড করার সময় বিধিনিষেধগুলি প্রয়োগ করা হয় না, যার অর্থ ড্রাইভারগুলি /system/lib[64] -এ থাকা লাইব্রেরিগুলির সাথে লিঙ্ক করা চালিয়ে যেতে পারে। যাইহোক, OVERRIDE_RS_DRIVER সম্পর্কিত আর্কিটেকচার পরিবর্তনের কারণে, android.hardware.renderscript@1.0-impl অবশ্যই /vendor পার্টিশনে ইনস্টল করতে হবে; এটি করতে ব্যর্থ হলে RenderScript রানটাইম CPU পাথে ফিরে যেতে বাধ্য হয়।

Renderscript বাতিলের কারণ সম্পর্কে জানতে, অ্যান্ড্রয়েড ডেভেলপারস ব্লগের “ Android GPU Compute Going Forward” অংশটি দেখুন। এই বাতিলের জন্য রিসোর্স তথ্যের মধ্যে নিম্নলিখিত বিষয়গুলো অন্তর্ভুক্ত রয়েছে: