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

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

অ্যান্ড্রয়েড 8.0 এবং উচ্চতর চলমান ডিভাইসগুলি নিম্নলিখিত রেন্ডারস্ক্রিপ্ট ফ্রেমওয়ার্ক এবং বিক্রেতা HALগুলি ব্যবহার করে:

চিত্র 1. অভ্যন্তরীণ libs লিঙ্ক বিক্রেতা কোড.

অ্যান্ড্রয়েড 7.x এবং তার নিচের রেন্ডারস্ক্রিপ্ট থেকে পার্থক্যগুলির মধ্যে রয়েছে:

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

ডিজাইন

নিম্নলিখিত বিভাগগুলি Android 8.0 এবং উচ্চতর সংস্করণে রেন্ডারস্ক্রিপ্ট ডিজাইনের বিশদ বিবরণ দেয়৷

রেন্ডারস্ক্রিপ্ট libs বিক্রেতাদের জন্য উপলব্ধ

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

যদিও নিম্নলিখিত লাইব্রেরিগুলির তালিকা অ্যান্ড্রয়েড রিলিজের মধ্যে ভিন্ন হতে পারে, এটি একটি নির্দিষ্ট অ্যান্ড্রয়েড রিলিজের জন্য অপরিবর্তনীয়; উপলব্ধ লাইব্রেরিগুলির একটি আপ-টু-ডেট তালিকার জন্য, /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-তে না থাকা libsকে ভেন্ডর কোড দ্বারা ব্যবহার করা থেকে বাধা দেয় তা রানটাইমে লিঙ্কার নেমস্পেস ব্যবহার করে প্রয়োগ করা হয়। (বিশদ বিবরণের জন্য, ভিএনডিকে ডিজাইন উপস্থাপনা পড়ুন।)

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

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

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

লোড ড্রাইভার

CPU ফলব্যাক পথ

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

যখন CPU ফলব্যাক পাথ নেওয়া হয় তখন বিক্রেতার কাছ থেকে RS HAL বাস্তবায়ন ব্যবহার করা হয় না এবং null mVendorDriverName দিয়ে একটি RsContext অবজেক্ট তৈরি করা হয়। libRSDriver.so হল (ডিফল্টরূপে) dlopen ed এবং ড্রাইভার lib 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 নামক একটি ভিন্ন লিঙ্কার নেমস্পেসে লোড করতে। RS HAL তারপর s libRS_internal.so তাই rs নামক আরেকটি লিঙ্কার নামস্থানে dlopen ।

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

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

চিত্র 4. GPU ফলব্যাক পথ।

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

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

bcc প্লাগইন লোড করুন

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 বিকল্পটি ব্যবহার করে নির্দিষ্ট করা হয়েছিল এবং lib-কে libLLVM.so দ্বারা সরল dlopen() ব্যবহার করে লোড করা হয়েছিল। অ্যান্ড্রয়েড 8.0 এবং উচ্চতর সংস্করণে, এটি -plugin বিকল্পে নির্দিষ্ট করা আছে এবং lib সরাসরি bcc নিজেই লোড করা হয়। এই বিকল্পটি ওপেন সোর্স LLVM প্রোজেক্টে একটি নন-অ্যান্ড্রয়েড-নির্দিষ্ট পথ সক্ষম করে।

চিত্র 5. bcc প্লাগইন লোড হচ্ছে, Android 7.x এবং নিম্নতর।



চিত্র 6. bcc প্লাগইন, Android 8.0 এবং উচ্চতর লোড হচ্ছে।

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

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

রানটাইম libs অন্তর্ভুক্ত:

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

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

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

SELinux নীতি

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

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

SELinux নীতির বিস্তারিত জানার জন্য, Android-এ নিরাপত্তা-বর্ধিত Linux দেখুন।

বিটকোডের জন্য 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 বা ভেন্ডারের সমতুল্য থাকে৷
  • নতুন রানটাইম ফাংশন বা ব্রেকিং মেটা-ডেটা পরিবর্তনের জন্য বিটকোড API স্তর বৃদ্ধি করা প্রয়োজন। যেহেতু বিক্রেতা ড্রাইভাররা এটি ব্যবহার করতে সক্ষম হবে না, তাই HAL সংস্করণটিও বৃদ্ধি করতে হবে।
  • বিক্রেতাদের নিজস্ব কম্পাইলার থাকতে পারে, কিন্তু bcc জন্য উপসংহার/প্রয়োজনীয়তা সেই কম্পাইলারদের ক্ষেত্রেও প্রযোজ্য।
লিঙ্ক
  • কম্পাইল করা .o-কে ভেন্ডর ড্রাইভারের সাথে লিঙ্ক করা হবে, যেমন, libRSDriver_foo.so , এবং libcompiler_rt.so । CPU পাথ libRSDriver.so সাথে লিঙ্ক করবে।
  • .o-এর libRSDriver_foo থেকে একটি নতুন রানটাইম API প্রয়োজন হলে, এটি সমর্থন করার জন্য ভেন্ডর ড্রাইভারকে আপডেট করতে হবে।
  • কিছু বিক্রেতাদের নিজস্ব লিঙ্কার থাকতে পারে, কিন্তু ld.mc এর যুক্তি তাদের ক্ষেত্রেও প্রযোজ্য।
লোড
  • libRSCpuRef শেয়ার করা অবজেক্ট লোড করে। এই ইন্টারফেসে পরিবর্তন হলে, একটি HAL সংস্করণ বাম্প প্রয়োজন।
  • শেয়ার্ড অবজেক্ট লোড করতে বিক্রেতারা হয় libRSCpuRef উপর নির্ভর করবে, অথবা তাদের নিজস্ব বাস্তবায়ন করবে।

HAL ছাড়াও, রানটাইম API এবং রপ্তানি করা প্রতীকগুলিও ইন্টারফেস। অ্যান্ড্রয়েড 7.0 (API 24) থেকে কোনও ইন্টারফেস পরিবর্তিত হয়নি এবং Android 8.0 এবং তার পরেও এটিকে পরিবর্তন করার কোনো তাৎক্ষণিক পরিকল্পনা নেই। যাইহোক, যদি ইন্টারফেস পরিবর্তন হয়, HAL সংস্করণও বৃদ্ধি পাবে।

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

GPU ড্রাইভার সঠিকভাবে কাজ করার জন্য Android 8.0 এবং উচ্চতর কিছু GPU ড্রাইভার পরিবর্তন প্রয়োজন।

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

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

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

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

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

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

উপরন্তু, বিক্রেতাদের নিম্নলিখিত পরিবর্তন করতে হবে:

চিত্র 7. বিক্রেতা ড্রাইভার পরিবর্তন.

  1. /vendor পার্টিশনে libclcore.bc কপি করুন। এটি নিশ্চিত করে 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 26-এর থেকে কম৷
  2. PRODUCT_FULL_TREBLE_OVERRIDE সংজ্ঞায়িত করা হয়নি৷

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

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