रेंडर स्क्रिप्ट

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

RenderScript कम्प्यूटेशनल इंटेंसिव चलाने के लिए एक फ़्रेमवर्क है Android पर बेहतर तरीके से टास्क पूरे करते हैं. इसे इस तरह से डिज़ाइन किया गया है कि डेटा-पैरलल कंप्यूटेशन की मदद से ऐसा किया जा सकता है. हालांकि, सीरियल वर्कलोड से भी फ़ायदा हो सकता है. कॉन्टेंट बनाने RenderScript रनटाइम, जैसे, मल्टी-कोर सीपीयू और जीपीयू जैसे डिवाइस से, डेवलपर को इन चीज़ों पर फ़ोकस करने में मदद मिलती है काम शेड्यूल करने के बजाय एल्गोरिदम को बता रहे हैं. RenderScript खास तौर पर यह सुविधा, इमेज प्रोसेसिंग और कंप्यूटेशनल ऐप्लिकेशन के लिए काम की है या कंप्यूटर विज़न.

Android 8.0 और उसके बाद के वर्शन पर चलने वाले डिवाइस, नीचे दिए गए RenderScript का इस्तेमाल करते हैं फ़्रेमवर्क और वेंडर एचएएल:

पहला डायग्राम. इंटरनल लिब्स से लिंक करने वाला वेंडर कोड.

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 लिब
  • 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 में नहीं हैं वेंडर कोड को लिंकर नेमस्पेस का इस्तेमाल करके, रनटाइम के दौरान लागू किया जाता है. (जानकारी के लिए, वीएनडीके डिज़ाइन देखें प्रज़ेंटेशन शामिल करें.)

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 की इन लाइब्रेरी पर इंटरनल डिपेंडेंसी है.

दूसरा डायग्राम. लिंकर के लिए नाम स्थान कॉन्फ़िगरेशन.

ड्राइवर लोड करें

सीपीयू फ़ॉलबैक पाथ

RS_CONTEXT_LOW_LATENCY बिट की मौजूदगी के आधार पर आरएस कॉन्टेक्स्ट बनाते समय, सीपीयू या जीपीयू पाथ चुना जाता है. जब सीपीयू पाथ चुना गया, libRS_internal.so (लागू करने का मुख्य तरीका आरएस फ़्रेमवर्क के मुताबिक)dlopen नेमस्पेस जहां आरएस लिब्स का प्लैटफ़ॉर्म वर्शन दिया गया है.

जब सीपीयू (CPU) फ़ॉलबैक पाथ लिया जाता है और इसके साथ एक RsContext ऑब्जेक्ट बनाया जाता है शून्य mVendorDriverName. libRSDriver.so है (इसके ज़रिए डिफ़ॉल्ट) dlopen होती है और ड्राइवर लिब, default नेमस्पेस, क्योंकि कॉलर (libRS_internal.so) default में भी लोड होता है नेमस्पेस.

तीसरी इमेज. सीपीयू फ़ॉलबैक पाथ.

जीपीयू पाथ

जीपीयू पाथ के लिए, 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 नेमस्पेस के खोज पाथ में है.

चौथी इमेज. जीपीयू फ़ॉलबैक पाथ.

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 प्रोजेक्ट है.

पांचवी इमेज. गुप्त कॉपी प्लगिन, Android 7.x और उससे पहले के वर्शन लोड हो रहे हैं.



छठी इमेज. गुप्त कॉपी प्लगिन, 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 बिट कोड का इस्तेमाल तीन चरणों में होता है:

स्टेज जानकारी
कंपाइल करें
  • bcc के लिए इनपुट बिटकोड (.bc) इसमें होना चाहिए LLVM 3.2 बिटकोड फ़ॉर्मैट और bcc पीछे होने चाहिए मौजूदा (लेगसी) ऐप्लिकेशन के साथ काम करता है.
  • हालांकि, .bc में मौजूद मेटा-डेटा में बदलाव हो सकता है (नया रनटाइम आ सकता है फ़ंक्शन, जैसे कि आवंटन सेटर ∓ गैटर, मैथ फ़ंक्शन वगैरह). हिस्सा रनटाइम फ़ंक्शन का एक हिस्सा libclcore.bc में होता है, जो उनका हिस्सा है लोग, LibRSDriver या वेंडर के समकक्ष में रहते हैं.
  • नए रनटाइम फ़ंक्शन या मेटा-डेटा में किए गए बदलावों को तोड़ने के लिए, बढ़ी हुई ज़रूरत होती है बिट कोड एपीआई लेवल तक पहुंच सकते हैं. वेंडर ड्राइवर इसका इस्तेमाल नहीं कर पाएंगे. एचएएल वर्शन को भी बढ़ाया जाना चाहिए.
  • वेंडर के खुद के कंपाइलर हो सकते हैं, लेकिन नतीजाें/ज़रूरी शर्तें ये कंपाइलर bcc के लिए भी लागू होते हैं.
लिंक
  • कंपाइल किए गए .o को वेंडर ड्राइवर से लिंक किया जाएगा, उदाहरण के लिए, libRSDriver_foo.so और libcompiler_rt.so. सीपीयू पाथ libRSDriver.so से लिंक होगा.
  • अगर .o को libRSDriver_foo से नया रनटाइम एपीआई चाहिए, तो काम कर सके, इसके लिए वेंडर ड्राइवर को अपडेट करना होगा.
  • कुछ वेंडर के खुद के लिंकर हो सकते हैं, लेकिन ld.mc भी उन पर लागू होते हैं.
लोड करना
  • libRSCpuRef शेयर किए गए ऑब्जेक्ट को लोड करता है. अगर कोई इस इंटरफ़ेस में बदलाव करते हैं, तो एक एचएएल वर्शन बंप की ज़रूरत है.
  • शेयर किए गए एक्सटेंशन को लोड करने के लिए, वेंडर libRSCpuRef का इस्तेमाल करेंगे आपत्ति है या खुद का इस्तेमाल कर सकता है.

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 बिटकोड को दो तरीकों से कंपाइल किया जा सकता है:

  1. /vendor/bin/ में वेंडर के हिसाब से खास तौर पर रेंडर होने वाले स्क्रिप्ट को शुरू करें (जीपीयू को कंपाइल करने का पसंदीदा तरीका). अन्य ड्राइवर मॉड्यूल की तरह, वेंडर कंपाइलर बाइनरी ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकती जो RenderScript libs की सूची जो वेंडर के लिए उपलब्ध होते हैं.
  2. सिस्टम की गुप्त कॉपी शुरू करें: वेंडर के दिए हुए /system/bin/bcc की मदद से bcc plugin; यह प्लगिन ऐसी सिस्टम लाइब्रेरी पर निर्भर नहीं हो सकता जो की सूची में नहीं है RenderScript लिब्स उपलब्ध करना ज़रूरी है.

अगर bcc plugin वेंडर को सीपीयू में रुकावट डालने की ज़रूरत पड़ती है कंपाइलेशन और libLLVM.so पर इसकी निर्भरता को आसानी से नहीं हटाया गया, वेंडर को bcc (और गैर-LL-NDK के सभी डिपेंडेंसी, जिनमें libLLVM.so, libbcc.so शामिल हैं) /vendor विभाजन.

इसके अलावा, वेंडर को ये बदलाव करने होंगे:

सातवीं इमेज. वेंडर ड्राइवर में बदलाव.

  1. libclcore.bc को /vendor पार्टीशन में कॉपी करें. यह पक्का करता है कि libclcore.bc, libLLVM.so, और libbcc.so सिंक में हैं.
  2. सेटिंग का इस्तेमाल करके, 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

लेगसी डिवाइस

लेगसी डिवाइस वे होते हैं जो नीचे दी गई शर्तें पूरी करते हैं:

  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 रनटाइम लागू हो जाता है सीपीयू पाथ पर फ़ॉलबैक.

रेंडर स्क्रिप्ट का इस्तेमाल बंद होने की वजह जानने के लिए, Android Developers देखें ब्लॉग: Android जीपीयू कंप्यूटिंग आगे जा रही है. इस रोक के लिए संसाधन की जानकारी में ये चीज़ें शामिल हैं: