RenderScript कम्प्यूटेशनल इंटेंसिव चलाने के लिए एक फ़्रेमवर्क है Android पर बेहतर तरीके से टास्क पूरे करते हैं. इसे इस तरह से डिज़ाइन किया गया है कि डेटा-पैरलल कंप्यूटेशन की मदद से ऐसा किया जा सकता है. हालांकि, सीरियल वर्कलोड से भी फ़ायदा हो सकता है. कॉन्टेंट बनाने RenderScript रनटाइम, जैसे, मल्टी-कोर सीपीयू और जीपीयू जैसे डिवाइस से, डेवलपर को इन चीज़ों पर फ़ोकस करने में मदद मिलती है काम शेड्यूल करने के बजाय एल्गोरिदम को बता रहे हैं. RenderScript खास तौर पर यह सुविधा, इमेज प्रोसेसिंग और कंप्यूटेशनल ऐप्लिकेशन के लिए काम की है या कंप्यूटर विज़न.
Android 8.0 और उसके बाद के वर्शन पर चलने वाले डिवाइस, नीचे दिए गए RenderScript का इस्तेमाल करते हैं फ़्रेमवर्क और वेंडर एचएएल:
![](https://source.android.com/docs/core/architecture/images/treble_rs_linking.png?authuser=2&hl=hi)
पहला डायग्राम. इंटरनल लिब्स से लिंक करने वाला वेंडर कोड.
Android 7.x और उससे पहले के वर्शन वाले RenderScript के अंतरों में शामिल हैं:
- किसी प्रोसेस में RenderScript इंटरनल लिब्स के दो इंस्टेंस. एक सेट इसके लिए है
सीपीयू फ़ॉलबैक पाथ और सीधे
/system/lib
से होता है; अन्य सेट, जीपीयू पाथ के लिए है और यह/system/lib/vndk-sp
से लिया गया है. /system/lib
में आरएस इंटरनल लाइब्रेरी, औरsystem.img
के अपग्रेड होने पर अपडेट हो जाते हैं. हालांकि, लिब्स/system/lib/vndk-sp
में वेंडर के लिए बनाए गए हैं औरsystem.img
के अपग्रेड होने पर अपडेट किया जाता है (जब तक कि उन्हें अपडेट किया जा सकता है उनका एबीआई वैसा ही रहता है).- वेंडर कोड (RS HAL, RS ड्राइवर, और
bcc plugin
) यह हैं RenderScript आंतरिक लिब्स के साथ लिंक किया गया/system/lib/vndk-sp
. वे इसमें लाइब्रेरी के साथ लिंक नहीं कर सकते/system/lib
क्योंकि उस डायरेक्ट्री में लिब्स इस आधार पर बनाई गई हैं: इसलिए, हो सकता है कि यह वेंडर कोड (जैसे, सिंबल) के साथ काम न करे हटाई जा सकती है). ऐसा करने से, सिर्फ़ फ़्रेमवर्क के लिए काम करने वाला ओटीए नामुमकिन हो जाएगा.
डिज़ाइन
नीचे दिए गए सेक्शन, Android 8.0 और इसके बाद के वर्शन में RenderScript के डिज़ाइन के बारे में बताते हैं.
वेंडर के लिए RenderScript लिब्स उपलब्ध
इस सेक्शन में RenderScript लिब्स (एक ही प्रोसेस के लिए वेंडर एनडीके के नाम से जाना जाता है) को लिस्ट किया गया है HAL या VNDK-SP), जो वेंडर कोड में उपलब्ध होते हैं. साथ ही, जिन्हें लिंक किया जा सकता है टीम में हुए हैं. इसमें ऐसी दूसरी लाइब्रेरी की जानकारी भी दी गई है जो RenderScript, लेकिन जिसे वेंडर कोड के लिए भी उपलब्ध कराया गया है.
Android के अलग-अलग वर्शन के लिए, नीचे दी गई लाइब्रेरी की सूची अलग-अलग हो सकती है.
Android के किसी खास वर्शन में इसे बदला न जा सके; की अप-टू-डेट सूची देखने के लिए
उपलब्ध लाइब्रेरी के लिए, /system/etc/ld.config.txt
देखें.
RenderScript लिब | नॉन-RenderScript लिब |
---|---|
|
|
लिंकर नेमस्पेस कॉन्फ़िगरेशन
लिंक करने की वह पाबंदी जो उन लाइब्रेरी को इस्तेमाल करने से रोकती है जो VNDK-SP में नहीं हैं वेंडर कोड को लिंकर नेमस्पेस का इस्तेमाल करके, रनटाइम के दौरान लागू किया जाता है. (जानकारी के लिए, वीएनडीके डिज़ाइन देखें प्रज़ेंटेशन शामिल करें.)
Android 8.0 और उसके बाद के वर्शन वाले डिवाइस पर, सभी एक ही प्रोसेस वाले HAL (SP-HAL) होते हैं
RenderScript के अलावा लिंकर नेमस्पेस के अंदर लोड किया जाता है
sphal
. RenderScript को RenderScript के खास इवेंट में लोड किया जाता है
नेमस्पेस rs
, जो एक ऐसी जगह है जो कुछ हद तक ढीला करने वाले लोगों को चालू करती है
RenderScript लिब्स के लिए लागू करना. क्योंकि RS लागू करने के लिए लोड होना ज़रूरी है
कंपाइल किया गया बिटकोड, /data/*/*.so
को
rs
नेमस्पेस (अन्य SP-HAL को,
डेटा विभाजन).
इसके अलावा, rs
नेमस्पेस के लिए दिए गए टूल से ज़्यादा लाइब्रेरी को अनुमति मिलती है
अन्य नेमस्पेस से. libmediandk.so
और libft2.so
rs
नेमस्पेस के संपर्क में आते हैं, क्योंकि
libRS_internal.so
की इन लाइब्रेरी पर इंटरनल डिपेंडेंसी है.
![](https://source.android.com/docs/core/architecture/images/treble_rs_namespace.png?authuser=2&hl=hi)
दूसरा डायग्राम. लिंकर के लिए नाम स्थान कॉन्फ़िगरेशन.
ड्राइवर लोड करें
सीपीयू फ़ॉलबैक पाथ
RS_CONTEXT_LOW_LATENCY
बिट की मौजूदगी के आधार पर
आरएस कॉन्टेक्स्ट बनाते समय, सीपीयू या जीपीयू पाथ चुना जाता है. जब
सीपीयू पाथ चुना गया, libRS_internal.so
(लागू करने का मुख्य तरीका
आरएस फ़्रेमवर्क के मुताबिक)dlopen
नेमस्पेस जहां आरएस लिब्स का प्लैटफ़ॉर्म वर्शन दिया गया है.
जब सीपीयू (CPU)
फ़ॉलबैक पाथ लिया जाता है और इसके साथ एक RsContext
ऑब्जेक्ट बनाया जाता है
शून्य mVendorDriverName
. libRSDriver.so
है (इसके ज़रिए
डिफ़ॉल्ट) dlopen
होती है और ड्राइवर लिब,
default
नेमस्पेस, क्योंकि कॉलर
(libRS_internal.so
) default
में भी लोड होता है
नेमस्पेस.
![](https://source.android.com/docs/core/architecture/images/treble_rs_cpu_fallback.png?authuser=2&hl=hi)
तीसरी इमेज. सीपीयू फ़ॉलबैक पाथ.
जीपीयू पाथ
जीपीयू पाथ के लिए, libRS_internal.so
को अलग तरीके से लोड किया जाता है.
सबसे पहले, libRS.so
इस्तेमाल
android.hardware.renderscript@1.0.so
(और इसकी बुनियादी जानकारी
libhidltransport.so
) को लोड करने के लिए
android.hardware.renderscript@1.0-impl.so
(एक वेंडर
आरएस एचएएल को एक अलग लिंकर नेमस्पेस में लागू करना
sphal
. द आरएस
HAL फिर dlopen
का libRS_internal.so
लिंकर नेमस्पेस को rs
कहा जाता है.
बिल्ड टाइम फ़्लैग सेट करके, वेंडर अपना आरएस ड्राइवर उपलब्ध करा सकते हैं
OVERRIDE_RS_DRIVER
, जिसे आरएस एचएएल में एम्बेड किया गया है
लागू करना
(hardware/interfaces/renderscript/1.0/default/Context.cpp
). यह
इसके बाद, जीपीयू पाथ के लिए आरएस के हिसाब से ड्राइवर का नाम dlopen
किया जाता है.
RsContext
ऑब्जेक्ट बनाने का अनुरोध आरएस एचएएल को किया गया है
लागू करना. एचएएल, इसकी मदद से आरएस फ़्रेमवर्क पर वापस कॉल करता है
rsContextCreateVendor()
फ़ंक्शन, जिसमें ड्राइवर का नाम लिया जाता है
का इस्तेमाल आर्ग्युमेंट के तौर पर करें. इसके बाद, आरएस फ़्रेमवर्क तय किए गए ड्राइवर को तब लोड करता है, जब
RsContext
शुरू किया गया. इस मामले में, ड्राइवर लाइब्रेरी
rs
नेमस्पेस में लोड किया गया, क्योंकि RsContext
ऑब्जेक्ट को rs
नेमस्पेस के अंदर बनाया जाता है और
/vendor/lib
नेमस्पेस के खोज पाथ में है.
![](https://source.android.com/docs/core/architecture/images/treble_rs_gpu_fallback.png?authuser=2&hl=hi)
चौथी इमेज. जीपीयू फ़ॉलबैक पाथ.
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
इस लाइन से पता चलता है कि डाइनैमिक लिंकर को लोड होना चाहिए
लिबिंग के समय rs
नेमस्पेस से libRS_internal.so
sphal
नेमस्पेस से नहीं ढूंढा जा सकता या लोड नहीं किया जा सकता (जो कि हमेशा होता है
मामला इसलिए है, क्योंकि sphal
नेमस्पेस, खोज नहीं करता
/system/lib/vndk-sp
जहां libRS_internal.so
निवास स्थान है). इस कॉन्फ़िगरेशन के साथ, एक सामान्य dlopen()
कॉल
नेमस्पेस का ट्रांज़िशन करने के लिए, libRS_internal.so
काफ़ी है.
गुप्त कॉपी प्लगिन लोड करें
bcc plugin
, वेंडर की तरफ़ से उपलब्ध कराई गई लाइब्रेरी है, जिसे
bcc
कंपाइलर. क्योंकि bcc
एक सिस्टम प्रोसेस है, जो
/system/bin
डायरेक्ट्री, bcc plugin
लाइब्रेरी
इसे SP-HAL माना जाता है. इसका मतलब है कि वेंडर एचएएल को
प्रोसेस करने के लिए प्रोत्साहित भी करते हैं. एसपी-एचएएल के तौर पर,
bcc-plugin
लाइब्रेरी:
- सिर्फ़ फ़्रेमवर्क वाली लाइब्रेरी से लिंक नहीं किया जा सकता, जैसे कि
libLLVM.so
. - सिर्फ़ वेंडर के लिए उपलब्ध VNDK-SP लाइब्रेरी से लिंक किया जा सकता है.
यह पाबंदी, bcc plugin
को लोड करने पर लागू होती है
sphal
नेमस्पेस
android_sphal_load_library()
फ़ंक्शन का इस्तेमाल करना होगा. इसके पिछले वर्शन में
Android के लिए, प्लग इन का नाम -load
विकल्प का इस्तेमाल करके बताया गया था और
लाइब्रेरी को इसके आसान dlopen()
का इस्तेमाल करके लोड किया गया
libLLVM.so
. Android 8.0 और उसके बाद वाले वर्शन में, यह
-plugin
विकल्प और लाइब्रेरी को सीधे तौर पर
bcc
. यह विकल्प, Android के बजाय किसी दूसरे ऐप्लिकेशन का पाथ चालू करता है
तो यह एक ओपन सोर्स LLVM प्रोजेक्ट है.
![](https://source.android.com/docs/core/architecture/images/treble_rs_bcc_plugin_old.png?authuser=2&hl=hi)
पांचवी इमेज. गुप्त कॉपी प्लगिन, Android 7.x और उससे पहले के वर्शन लोड हो रहे हैं.
![](https://source.android.com/docs/core/architecture/images/treble_rs_bcc_plugin_new.png?authuser=2&hl=hi)
छठी इमेज. गुप्त कॉपी प्लगिन, Android 8.0 और इसके बाद के वर्शन लोड हो रहे हैं.
ld.mc के लिए खोज पाथ
ld.mc
को एक्ज़ीक्यूट करने पर, कुछ आरएस रनटाइम लिब्स को इनपुट के तौर पर दिया जाता है
लिंकर पर ले जाएगा. ऐप्लिकेशन से मिले आरएस बिटकोड को रनटाइम लिब्स के साथ लिंक किया गया है
और जब कन्वर्ट किए गए बिटकोड को किसी ऐप्लिकेशन प्रोसेस में लोड किया जाता है, तो रनटाइम लिब्स
रूपांतरित बिट कोड से फिर से डायनामिक रूप से लिंक कर दिए जाते हैं.
रनटाइम लिब्स में ये शामिल हैं:
libcompiler_rt.so
libm.so
libc.so
- आरएस ड्राइवर (
libRSDriver.so
याOVERRIDE_RS_DRIVER
)
ऐप्लिकेशन की प्रोसेस में, कंपाइल किए गए बिटकोड को लोड करते समय,
लाइब्रेरी जिसे ld.mc
ने इस्तेमाल किया. या फिर, कंपाइल किया गया बिटकोड
शायद वह सिंबल न मिले जो लिंक होते समय उपलब्ध था.
ऐसा करने के लिए, आरएस फ़्रेमवर्क रनटाइम लिब्स के लिए अलग-अलग खोज पाथ का इस्तेमाल करता है, जब
ld.mc
एक्ज़ीक्यूट हो रहा है. यह इस बात पर निर्भर करता है कि आरएस फ़्रेमवर्क खुद
इसे /system/lib
या /system/lib/vndk-sp
से लोड किया गया.
इसका पता लगाने के लिए, किसी आरएस के आर्बिट्रेरी सिंबल के पते को पढ़ें
फ़्रेमवर्क लिब और dladdr()
का इस्तेमाल करके फ़ाइल पाथ को मैप करना
पता.
SELinux नीति
SELinux नीति की वजह से Android 8.0 और इसके बाद वाले वर्शन में बदलाव हो रहे हैं, तो आपके लिए ज़रूरी है कि
neverallows
से लागू होने वाले खास नियमों का पालन करें, जब
vendor
पार्टीशन में अतिरिक्त फ़ाइलों को लेबल किया जा रहा है:
- इसमें मौजूद सभी फ़ाइलों के लिए
vendor_file
को डिफ़ॉल्ट लेबल होना चाहिएvendor
विभाजन. ऐक्सेस करने के लिए, प्लैटफ़ॉर्म की नीति के मुताबिक यह ज़रूरी है पासथ्रू एचएएल लागू करना. vendor
विभाजन में सभी नएexec_types
जोड़े गए थ्रू वेंडर SEPolicy मेंvendor_file_type
एट्रिब्यूट होना ज़रूरी है. इसेneverallows
की मदद से लागू किया गया है.- आने वाले समय में प्लैटफ़ॉर्म/फ़्रेमवर्क से जुड़े अपडेट में कोई समस्या न आए, इसके लिए लेबल करने से बचें
vendor
पार्टीशन मेंexec_types
के अलावा अन्य फ़ाइलें. - एओएसपी से तय की गई एक जैसी प्रोसेस एचएएल के लिए, सभी लाइब्रेरी डिपेंडेंसी
same_process_hal_file
के तौर पर लेबल किया गया है.
SELinux नीति के विवरण के लिए, देखें Android में बेहतर सुरक्षा के साथ Linux.
बिटकोड के लिए एबीआई की सुविधा
अगर कोई नया एपीआई नहीं जोड़ा जाता है, तो इसका मतलब है कि एचएएल वर्शन में कोई बंप नहीं है, तो आरएस फ़्रेमवर्क मौजूदा जीपीयू (HAL 1.0) ड्राइवर का इस्तेमाल करता रहेगा.
एचएएल में किए गए छोटे-मोटे बदलावों (HAL 1.1) का बिटकोड पर कोई असर नहीं पड़ता. इसके लिए, फ़्रेमवर्क को इन नए जोड़े गए एपीआई के लिए, सीपीयू पर फ़ॉलबैक और जीपीयू (HAL 1.0) ड्राइवर का इस्तेमाल करते रहें कहीं और.
बिटकोड कंपाइलेशन/लिंकिंग को प्रभावित करने वाले एचएएल 2.0 बड़े बदलावों के लिए, आरएस फ़्रेमवर्क को यह विकल्प चुनना चाहिए कि वह वेंडर के उपलब्ध कराए गए जीपीयू ड्राइवरों को लोड न करे. रफ़्तार बढ़ाने के लिए, सीपीयू या Vulkan पाथ का इस्तेमाल करें.
RenderScript बिट कोड का इस्तेमाल तीन चरणों में होता है:
स्टेज | जानकारी |
---|---|
कंपाइल करें |
|
लिंक |
|
लोड करना |
|
HAL के अलावा, रनटाइम एपीआई और एक्सपोर्ट किए गए सिंबल भी इंटरफ़ेस. Android 7.0 (एपीआई 24) के बाद से, दोनों में से कोई भी इंटरफ़ेस नहीं बदला Android 8.0 और इसके बाद के वर्शन पर, इसे तुरंत बदलने की कोई योजना नहीं है. हालांकि, अगर इंटरफ़ेस बदलता है, तो एचएएल वर्शन में भी बदलाव होता रहेगा.
वेंडर के लिए लागू करना
Android 8.0 और उसके बाद के वर्शन में जीपीयू ड्राइवर के लिए, कुछ जीपीयू ड्राइवर में बदलाव करने की ज़रूरत होती है ठीक से काम करता है.
ड्राइवर मॉड्यूल
- ड्राइवर मॉड्यूल ऐसी किसी भी सिस्टम लाइब्रेरी पर निर्भर नहीं होना चाहिए जो सूची.
- ड्राइवर को अपनी जानकारी खुद देनी होगी
android.hardware.renderscript@1.0-impl_{NAME}
या डिफ़ॉल्ट रूप से,android.hardware.renderscript@1.0-impl
इस तौर पर लागू होता है भी शामिल नहीं है. libRSDriver.so
में, सीपीयू को लागू करने के तरीके की जानकारी दी गई है. इसकी मदद से, गैर-VNDK-SP डिपेंडेंसी हटाएं.
बिटकोड कंपाइलर
वेंडर ड्राइवर के लिए RenderScript बिटकोड को दो तरीकों से कंपाइल किया जा सकता है:
/vendor/bin/
में वेंडर के हिसाब से खास तौर पर रेंडर होने वाले स्क्रिप्ट को शुरू करें (जीपीयू को कंपाइल करने का पसंदीदा तरीका). अन्य ड्राइवर मॉड्यूल की तरह, वेंडर कंपाइलर बाइनरी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकती जो RenderScript libs की सूची जो वेंडर के लिए उपलब्ध होते हैं.- सिस्टम की गुप्त कॉपी शुरू करें: वेंडर के दिए हुए
/system/bin/bcc
की मदद सेbcc plugin
; यह प्लगिन ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकता जो की सूची में नहीं है RenderScript लिब्स उपलब्ध करना ज़रूरी है.
अगर bcc plugin
वेंडर को सीपीयू में रुकावट डालने की ज़रूरत पड़ती है
कंपाइलेशन और libLLVM.so
पर इसकी निर्भरता को आसानी से नहीं
हटाया गया, वेंडर को bcc
(और गैर-LL-NDK के सभी
डिपेंडेंसी, जिनमें libLLVM.so
, libbcc.so
शामिल हैं)
/vendor
विभाजन.
इसके अलावा, वेंडर को ये बदलाव करने होंगे:
![](https://source.android.com/docs/core/architecture/images/treble_rs_vendor_driver.png?authuser=2&hl=hi)
सातवीं इमेज. वेंडर ड्राइवर में बदलाव.
libclcore.bc
को/vendor
पार्टीशन में कॉपी करें. यह पक्का करता है किlibclcore.bc
,libLLVM.so
, औरlibbcc.so
सिंक में हैं.- सेटिंग का इस्तेमाल करके,
bcc
एक्ज़ीक्यूटेबल फ़ाइल का पाथ बदलें आरएस एचएएल लागू करने से मिलाRsdCpuScriptImpl::BCC_EXE_PATH
.
SELinux नीति
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 रनटाइम लागू हो जाता है
सीपीयू पाथ पर फ़ॉलबैक.
रेंडर स्क्रिप्ट का इस्तेमाल बंद होने की वजह जानने के लिए, Android Developers देखें ब्लॉग: Android जीपीयू कंप्यूटिंग आगे जा रही है. इस रोक के लिए संसाधन की जानकारी में ये चीज़ें शामिल हैं:
- 'रेंडरस्क्रिप्ट' से माइग्रेट करना
- RenderScript Migration सैंपल
- इंट्रिंसिक्स रिप्लेसमेंट टूलकिट README
- मूल जानकारी का रिप्लेसमेंटToolkit.kt