रेंडरस्क्रिप्ट भाग दो

रेंडरस्क्रिप्ट हनीकॉम्ब में पेश की गई एक नई सुविधा है। यह भी ज्ञात है कि पहले रेंडरस्क्रिप्ट पहले से ही एंड्रॉइड डेवलपर्स द्वारा उपयोग किया गया था (उदाहरण के लिए, 2.1 में निर्मित लाइव वॉलपेपर (एक्लेयर) इस पर लिखे गए थे)। एक तरह से या किसी अन्य, एपीआई का पूरा उपयोग केवल हनीकॉम्ब में खोला गया था। डेवलपर्स ब्लॉग से पहला परिचयात्मक लेख ( मूल अनुवाद ) ने वादा किया कि जल्द ही एक दूसरा होगा, जिसमें रेंडरस्क्रिप्ट वास्तुकला का अधिक विस्तृत विवरण और इसके उपयोग का एक उदाहरण होगा। दरअसल, दोनों कट के नीचे।


इसके बाद, एंड्रॉइड डेवलपमेंट टीम के इंजीनियर आर। जेसन सैम्स की तरफ से।

रेंडरस्क्रिप्ट में अपने परिचय में, मैंने इस तकनीक का संक्षिप्त विवरण दिया। इस पोस्ट में मैं "कंप्यूटिंग" पर ध्यान केंद्रित करूँगा। रेंडरस्क्रिप्ट शब्दों में, "संगणना" का अर्थ है, डाल्विक कोड से रेंडरस्क्रिप्ट कोड तक डेटा प्रोसेसिंग का कुछ उतार-चढ़ाव, जो बदले में एक ही प्रोसेसर पर, या अन्य (कई पर) चल सकता है।

रेंडरस्क्रिप्ट डिजाइन लक्ष्य

रेंडरस्क्रिप्ट के तीन मुख्य लक्ष्य हैं, उन्हें अधिक महत्वपूर्ण से कम महत्वपूर्ण के क्रम में समझें:

पोर्टेबिलिटी: एप्लिकेशन कोड सभी उपकरणों पर चलना चाहिए, भले ही उनके हार्डवेयर भरण एक दूसरे से मौलिक रूप से भिन्न हों। अब ARM कई संस्करणों में आता है - वीएफएन सपोर्ट के साथ और उसके बिना, नीयन सपोर्ट के साथ और बिना अलग-अलग रजिस्टर काउंटर्स के साथ। एआरएम के अलावा, x86 के समान अन्य सीपीयू आर्किटेक्चर भी हैं, विभिन्न जीपीयू और यहां तक ​​कि विभिन्न डीएसपी (डिजिटल सिग्नल प्रोसेसर) भी हैं।

प्रदर्शन: दूसरा लक्ष्य उच्चतम स्तर के प्रदर्शन को प्राप्त करना है जो संभव है, लेकिन पोर्टेबिलिटी सीमाओं के साथ। रेंडरस्क्रिप्ट के लिए, हमने पहले से ही स्थापित समाधानों की तुलना में बहुत अधिक प्रदर्शन प्राप्त करने का प्रयास किया।

प्रयोज्यता: तीसरा लक्ष्य विकास को यथासंभव सरल बनाना था। हमने "ग्लू कोड" और अन्य अनावश्यक डेवलपर लोडिंग की उपस्थिति से बचने के लिए कुछ विकास चरणों को जितना संभव हो सके स्वचालित किया है।

ये तीन लक्ष्य डिजाइन को सीमित करते हैं और कुछ समझौता करते हैं। ये वो ट्रेडऑफ़ हैं जो रैंडलस्क्रिप्ट को मौजूदा समाधान जैसे डाल्विक या एनडीके से अलग करते हैं। उन्हें विभिन्न उपकरणों के रूप में माना जाना चाहिए जो विभिन्न कार्यों को करने के लिए कार्य करते हैं।

डिजाइन चरण में मुख्य निर्णय

पहला निर्णय जो हमें करने की जरूरत थी, वह थी विकास की भाषा। जब पसंद किस भाषा का उपयोग करना है, तो विकल्पों का लगभग असीमित सेट होता है। प्रोग्रामिंग शेडर्स के लिए भाषाओं के रूप में, C और C ++ पर विचार किया गया था। इसके बाद, आलेखीय अनुप्रयोगों, जैसे दृश्यों के लिए डेटा संरचनाओं में हेरफेर करने की आवश्यकता के कारण, हमें shader भाषाओं को छोड़ना पड़ा। संकेत और पुनरावृत्ति का अभाव प्रयोज्य की सीमाओं के रूप में देखा गया था। दूसरी ओर, C ++ का उपयोग करना वांछनीय होगा, लेकिन तब आपको पोर्टेबिलिटी प्रतिबंधों का सामना करना पड़ेगा। गैर-प्रोसेसर हार्डवेयर पर उन्नत C ++ सुविधाएँ चलाना मुश्किल है। नतीजतन, हमने रेंडरस्क्रिप्ट पर C99 मानक को आधार बनाने का फैसला किया, क्योंकि यह बाकी समाधानों के लिए समान प्रदर्शन प्रदान करता है, हम इसे डेवलपर्स द्वारा अच्छी तरह से समझते हैं, और विभिन्न उपकरणों की एक विस्तृत श्रृंखला पर चलने के लिए कोई समस्या उत्पन्न नहीं करते हैं।

दूसरा ट्रेडऑफ़ रेंडरस्क्रिप्ट वर्कफ़्लो है। हमने विशेष रूप से मशीन कोड में स्रोत कोड को संकलित करने के तरीके पर ध्यान केंद्रित किया। विकास के दौरान विभिन्न विकल्पों की जांच करने के बाद, हमने दो समाधान लागू किए। पुराने संस्करण (एक्लेयर और जिंजरब्रेड के बीच) ने मूल स्रोत सी कोड को पूरी तरह से संकलित किया। जबकि इसने मक्खी पर कोड जेनरेशन जैसे एप्लिकेशन दिए, यह एक प्रयोज्य समस्या में बदल गया। एप्लिकेशन को संकलित करना, उसे स्थापित करना, उसे चलाना और उसके बाद सिंटैक्स त्रुटि का पता लगाना बहुत असुविधाजनक था। इसके अलावा, कमजोर सीपीयू को स्थैतिक विश्लेषण की संभावना से वंचित रखा गया था और कुछ अनुकूलन किए जा सकते थे।

फिर हमने LLVM (एक निम्न-स्तरीय आभासी मशीन में स्विच किया, यह स्क्रिप्ट को एक प्लेटफ़ॉर्म-स्वतंत्र बायोटेक में संकलित करता है), एक ऐसे मॉडल पर जा रहा है जिसमें लिपियों को होस्ट (जिस डिवाइस पर स्क्रिप्ट चल रही है) का विश्लेषण किया गया है, क्लैंग के संशोधित संस्करण का उपयोग करके (जो नहीं करता है) जानता है - यह LLVM संकलक के लिए सामने का छोर है)। इस स्तर पर, हम कई उच्च-स्तरीय अनुकूलन करते हैं, जिसके बाद हम एलएलवीएम बायटेकोड का चयन करते हैं। इंटरमीडिएट बायोटेक से मशीन में अनुवाद मेजबान पर होता है (अतिरिक्त डिवाइस-विशिष्ट अनुकूलन के साथ)।

डिजाइनिंग में आखिरी प्रमुख ट्रेड थ्रेड्स शुरू करना था। यह प्रदर्शन और पोर्टेबिलिटी के बीच एक व्यापार है। पर्याप्त ज्ञान के साथ, मौजूदा कंप्यूटिंग समाधान डेवलपर को किसी विशेष हार्डवेयर प्लेटफ़ॉर्म के लिए एप्लिकेशन को कॉन्फ़िगर करने की अनुमति देते हैं, दूसरों के लिए। असीमित समय और संसाधनों को देखते हुए, डेवलपर्स हार्डवेयर के किसी भी संयोजन के लिए एप्लिकेशन को अनुकूलित कर सकते हैं। यद्यपि उपकरणों के एक निश्चित सेट के लिए परीक्षण और ट्यूनिंग खराब नहीं है, काम की कोई भी राशि उन उपकरणों के लिए आवेदन को समायोजित करने की अनुमति नहीं देगी जो अभी तक जारी नहीं किए गए हैं और डेवलपर से उपलब्ध नहीं हैं। रन-टाइम विश्लेषण के लिए एक अधिक पोर्टेबल समाधान होगा, जो पीक प्रदर्शन के कारण अधिक औसत प्रदर्शन प्रदान करता है। यह देखते हुए कि पोर्टेबिलिटी हमारा नंबर एक लक्ष्य था, हमने इस समाधान को चुना।

रनटाइम पर थ्रेड्स की शुरुआत को नियंत्रित करने की पसंद का दूसरा प्रभाव डायनेमिक निर्णय जहां स्क्रिप्ट को चलाने के लिए था। उदाहरण के लिए, कुछ कंप्यूटिंग हार्डवेयर संकेत और पुनरावृत्ति का समर्थन करते हैं, जबकि अन्य नहीं करते हैं। हम इन चीजों पर प्रतिबंध लगा सकते हैं और डेवलपर्स को एपीआई के कम से कम सामान्य भाजक के कुछ उदाहरण दे सकते हैं, लेकिन इसके बजाय हमने रन-टाइम विश्लेषण को चुना। यह डेवलपर्स को समर्थित हार्डवेयर की सभी क्षमताओं का उपयोग करने की अनुमति देता है, हालांकि एक ही समय में एक पूरी तरह कार्यात्मक सीपीयू है जिसे आप हमेशा स्थापित कर सकते हैं। अंत में, डेवलपर्स अच्छे एप्लिकेशन लिखने पर ध्यान केंद्रित कर सकते हैं, जबकि हार्डवेयर निर्माता पूर्ण विशेषताओं और शक्तिशाली हार्डवेयर पर काम कर सकते हैं। जैसे ही एक नया प्रदर्शन लाभ का अवसर प्रकट होता है, एप्लिकेशन इसका उपयोग बिना किसी कोड परिवर्तन के करता है।

डिजाइन के दौरान प्रयोज्य हमारा मुख्य लक्ष्य था। अधिकांश मौजूदा कंप्यूटिंग और ग्राफिक्स समाधानों को उच्च-प्रदर्शन कोड को एप्लिकेशन कोड से जोड़ने के लिए "चिपके हुए" तर्क की आवश्यकता होती है। ऐसा कोड लिखने में त्रुटि प्रवण और समस्याग्रस्त है। मेजबान पर रेंडस्क्रिप्ट द्वारा निष्पादित स्थैतिक विश्लेषण इस समस्या को हल करने में मदद करता है। स्क्रिप्ट का प्रत्येक उपयोगकर्ता अपनी "एक साथ चिपके हुए" Dalvik क्लास बनाता है। ग्लूइंग क्लास और उसके एक्सेसर्स के नाम स्क्रिप्ट से लिए गए हैं। यह दाल्विक से एक स्क्रिप्ट के उपयोग को सरल करता है।

उदाहरण: अनुप्रयोग स्तर

ऊपर उल्लिखित सभी ट्रेडऑफ़ को देखते हुए, कंप्यूटिंग एप्लिकेशन का एक सरल उदाहरण कैसा दिखना चाहिए? इस मूल उदाहरण में, हम एक नियमित रूप से android.graphics.Bitmap ऑब्जेक्ट लेंगे और एक स्क्रिप्ट चलाएंगे, जो इसे दूसरे बिटमैप पर कॉपी करेगा, उसी समय इसे मोनोक्रोम में परिवर्तित कर देगा। आइए एक नज़र डालते हैं उस एप्लिकेशन कोड पर जो स्क्रिप्ट को देखने से पहले स्क्रिप्ट को इनवॉइस करता है; HelloCompute SDK से उदाहरण:

private Bitmap mBitmapIn; private Bitmap mBitmapOut; private RenderScript mRS; private Allocation mInAllocation; private Allocation mOutAllocation; private ScriptC_mono mScript; private void createScript() { mRS = RenderScript.create(this); mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn, Allocation.MipmapControl.MIPMAP_NONE, Allocation.USAGE_SCRIPT); mOutAllocation = Allocation.createTyped(mRS, mInAllocation.getType()); mScript = new ScriptC_mono(mRS, getResources(), R.raw.mono); mScript.set_gIn(mInAllocation); mScript.set_gOut(mOutAllocation); mScript.set_gScript(mScript); mScript.invoke_filter(); mOutAllocation.copyTo(mBitmapOut); 

यह विधि मानती है कि दो बिटमैप पहले से ही निर्मित हैं और उनका आकार और स्वरूप समान है। पहली चीज रेंडरस्क्रिप्ट एप्लिकेशन की आवश्यकता एक संदर्भ वस्तु है। यह केंद्रीय वस्तु है जिसका उपयोग अन्य रेंडरस्क्रिप्ट ऑब्जेक्ट बनाने और प्रबंधित करने के लिए किया जाता है। कोड की पहली पंक्ति एक mRS ऑब्जेक्ट बनाती है, इस ऑब्जेक्ट को जीवित रहना चाहिए, जबकि एप्लिकेशन इसे या इसके साथ बनाई गई किसी भी ऑब्जेक्ट का उपयोग करने का इरादा रखता है।

निम्नलिखित दो विधियाँ गणना के लिए बिटमैप्स से आवंटन के निर्माण का कारण बनती हैं। रेंडरस्क्रिप्ट का अपना मेमोरी एलोकेटर है, क्योंकि यह संभावना है कि मेमोरी कई प्रोसेसर के बीच साझा की जाएगी और एक से अधिक मेमोरी स्पेस मौजूद हो सकते हैं। जब आवंटनकर्ता बनाया जाता है, तो इसके संभावित उपयोगों को क्रमांकित किया जाना चाहिए ताकि सिस्टम इच्छित कार्यों के लिए वांछित प्रकार की मेमोरी का निर्धारण कर सके।

पहला createFromBitmap () विधि एक प्लेसमेंट बनाता है और उसमें बिटमैप की सामग्री की प्रतिलिपि बनाता है। स्थान स्मृति की मूल इकाइयाँ हैं जो रेंडरस्क्रिप्ट उपयोग करती हैं। CreateTyped () के साथ बनाया गया दूसरा प्लेसमेंट पहले के समान प्लेसमेंट उत्पन्न करता है। इसके अलावा, इस संरचना की परिभाषा पहले से getType () अनुरोध द्वारा वापस आ गई है। रेंडरस्क्रिप्ट प्रकार लेआउट संरचना को परिभाषित करते हैं। इस मामले में, इनपुट बिटमैप की ऊंचाई, चौड़ाई और प्रारूप का उपयोग करके प्रकार उत्पन्न होता है।

अगली पंक्ति "mono.rs" नामक स्क्रिप्ट को लोड करती है, इसे प्राप्त करने के लिए R.raw.mono का उपयोग किया जाता है। स्क्रिप्ट स्वयं को अनुप्रयोग पैकेज (एपीके में) में एक कच्चे संसाधन के रूप में संग्रहीत किया जाता है। उत्पन्न "ग्लूइंग" वर्ग, ScriptC_mono के नाम पर ध्यान दें।

निम्न लाइनें "ग्लूइंग" वर्ग के उत्पन्न तरीकों का उपयोग करके स्क्रिप्ट गुण सेट करती हैं।

अब सब कुछ तैयार है, हालांकि वास्तव में invoke_filter () विधि ने हमारे लिए कुछ काम किया। लब्बोलुआब यह है कि "mono.rs" लिपि के फ़िल्टर () विधि को ही कॉल किया जाता है। यदि विधि में पैरामीटर होंगे, तो उन्हें यहां पारित करने की आवश्यकता है। मान वापस करना मना है क्योंकि कॉल अतुल्यकालिक हैं।

अंतिम पंक्ति बिटमैप की स्क्रिप्ट के परिणाम की प्रतिलिपि बनाती है। यह सुनिश्चित करने के लिए कुछ सिंक्रनाइज़ेशन कोड अंतर्निहित है कि स्क्रिप्ट ने निष्पादन पूरा कर लिया है।

उदाहरण: स्क्रिप्ट

यहाँ स्वयं "mono.rs" स्क्रिप्ट है, जिसे उपरोक्त कोड द्वारा कहा जाता है:

 #pragma version(1) #pragma rs java_package_name(com.android.example.hellocompute) rs_allocation gIn; rs_allocation gOut; rs_script gScript; const static float3 gMonoMult = {0.299f, 0.587f, 0.114f}; void root(const uchar4 *v_in, uchar4 *v_out, const void *usrData, uint32_t x, uint32_t y) { float4 f4 = rsUnpackColor8888(*v_in); float3 mono = dot(f4.rgb, gMonoMult); *v_out = rsPackColorTo8888(mono); } void filter() { rsForEach(gScript, gIn, gOut, 0); } 

स्क्रिप्ट की पहली पंक्ति कंपाइलर को बताती है कि यह किस संशोधन के लिए लिखा गया है। दूसरी पंक्ति एप्लिकेशन पैकेज के साथ उत्पन्न चिंतनशील कोड के संघ को नियंत्रित करती है।

अगले तीन वैश्विक चर हैं जो नियंत्रण कोड में बनाए गए हैं। चौथा वैश्विक चर चिंतनशील नहीं है, क्योंकि यह स्थिर है। स्थिरांक को स्थैतिक रूप से चिह्नित करना हमेशा बेहतर होता है, क्योंकि हमारा स्क्रिप्ट कोड नियंत्रण के साथ सिंक्रनाइज़ होता है।

रूट () विधि Renderscript के लिए विशेष है। वैचारिक रूप से, यह C. में मुख्य () विधि के समान है। जब कोई स्क्रिप्ट रन टाइम पर कॉल की जाती है, तो यह फ़ंक्शन एंट्री पॉइंट होता है। इस मामले में, पैरामीटर हमारे प्लेसमेंट से पिक्सेल हैं। एक सामान्य उपयोगकर्ता पॉइंटर को उस स्थान के भीतर एक पते के साथ भी प्रदान किया जाता है जिसे इस कॉल द्वारा संसाधित किया जा रहा है। इस उदाहरण में, इन मापदंडों की अनदेखी की जाती है।

रूट () विधि में कोड की तीन पंक्तियाँ RGBA_8888 से फ्लोट 4 से वेक्टर में डिकम्प्रेस करती हैं। दूसरी पंक्ति अंतर्निहित गणित फ़ंक्शन डॉट का उपयोग करती है, जो मोनोक्रोम चित्र प्राप्त करने के लिए आने वाले पिक्सेल के साथ मोनोक्रोम स्थिरांक के स्केलर उत्पाद की गणना करता है। ध्यान दें कि डॉट एक नियमित फ्लोट देता है, जिसे फ्लोट 3 को सौंपा जा सकता है, जो बस प्रत्येक घटक x, y और z के मान को कॉपी करता है। अंत में, हम मूल्यों को एक नियमित 32-बिट पिक्सेल में पैक करने के लिए फिर से अंतर्निहित टूल का उपयोग करते हैं। यह विधि ओवरलोडिंग का भी एक उदाहरण है, क्योंकि rsPackColorTo8888 के विभिन्न संस्करण हैं जो आरजीबी (फ्लोट 3) और आरजीबीए (फ्लोट 4) के रूप में डेटा स्वीकार करते हैं।

रूपांतरण करने के लिए फ़िल्टर () विधि को नियंत्रण कोड से बुलाया जाता है। यह बस प्रत्येक प्लेसमेंट तत्व पर एक गणना चलाता है। पहले पैरामीटर का मतलब है कि स्क्रिप्ट लॉन्च की गई है, अर्थात, रूट () विधि को प्रत्येक प्लेसमेंट तत्व के लिए कहा जाता है। दूसरा और तीसरा पैरामीटर इनपुट और आउटपुट डेटा प्लेसमेंट हैं। अंतिम पैरामीटर का उद्देश्य किसी भी उपयोगकर्ता डेटा को रूट () विधि से पारित करना है।

forEach डिवाइस पर होने पर कई प्रोसेसर पर चलेगा। भविष्य में, forEach संक्रमण बिंदु प्रदान करने में सक्षम होगा जहां नियंत्रण एक प्रोसेसर से दूसरे में जा सकता है। इस उदाहरण में, यह मानना ​​उचित होगा कि भविष्य में फ़िल्टर () सीपीयू पर निष्पादित किया जाएगा, और रूट () जीपीयू या डीएसपी पर।

मुझे उम्मीद है कि यह आपको रेंडरस्क्रिप्ट डिजाइन पर करीब से नज़र डालने का अवसर देता है और, एक सरल उदाहरण के साथ, यह कैसे काम करता है, से परिचित हो।

अनुवादक से: मुझे उन डेवलपर्स की कोई भी टिप्पणी सुनकर खुशी होगी, जिन्होंने किसी तरह इस तकनीक के साथ काम करना शुरू किया।