OpenCL में मेमोरी आवंटन की विशेषताएं

परिचय

नमस्कार प्रिय पाठकों।

इस पोस्ट में मैं OpenCL वस्तुओं के लिए स्मृति आवंटन की सुविधाओं पर विचार करने का प्रयास करूंगा।

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

साझा मेमोरी सीपीयू और जीपीयू के साथ सिस्टम के लिए मेमोरी आवंटन की विशेषताओं पर इस पोस्ट में चर्चा की जाएगी। हम छवि मेमोरी प्रकारों का उपयोग छोड़ देंगे और सबसे सामान्य प्रकार के बफर पर ध्यान केंद्रित करेंगे। मानक के रूप में, हम संस्करण 1.1 को सबसे आम मानेंगे। शुरुआत में हम एक लघु सैद्धांतिक पाठ्यक्रम आयोजित करेंगे, और फिर कुछ उदाहरणों पर विचार करेंगे।

सिद्धांत

मेमोरी को ClCreateBuffer API फ़ंक्शन को कॉल करके आवंटित किया गया है। सिंटैक्स निम्नानुसार है:

cl_mem clCreateBuffer ( cl_context context, cl_mem_flags flags, size_t size, void *host_ptr, cl_int *errcode_ret) 

हम मुख्य रूप से उन झंडों में रुचि रखते हैं जो इस बात के लिए जिम्मेदार हैं कि स्मृति को कैसे आवंटित किया जाएगा। निम्न मान मान्य हैं:

 CL_MEM_READ_WRITE CL_MEM_WRITE_ONLY, CL_MEM_READ_ONLY 

सबसे आसान विकल्प। मेमोरी को OpenCL डिवाइस साइड पर रीड-राइट / राइट-ओनली / रीड-ओनली मोड में आवंटित किया जाएगा।

 CL_MEM_ALLOC_HOST_PTR 

ऑब्जेक्ट के लिए मेमोरी होस्ट की मेमोरी से आवंटित की जाएगी - अर्थात, मुख्य मेमोरी से। यह ध्वज साझा सीपीयू और जीपीयू मेमोरी वाले सिस्टम के लिए रुचि रखता है।

 CL_MEM_USE_HOST_PTR 

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

 CL_MEM_COPY_HOST_PTR 

इस ध्वज का अर्थ है कि वस्तु बनाते समय, निर्दिष्ट पते से एक एनालॉग मेम्ची का उत्पादन किया जाएगा।

अभ्यास

चलिए यह जानने की कोशिश करते हैं कि मेमोरी ऑल्टमेंट का कौन सा विकल्प बेहतर है, असतत ग्राफिक्स कार्ड के पारंपरिक मामले के लिए "मेमोरी ऑन बोर्ड" और जिसमें GPU रैम से मेमोरी का उपयोग करता है। निम्नलिखित कंप्यूटरों को परीक्षण प्रणालियों के रूप में चित्रित किया जाएगा:

• असतत-चिप सिस्टम: Intel Core i5 4200U, 4Gb DDR31600Mhz, Radeon 8670M 128bit GDDR3 1800Mhz
• एकीकृत वीडियो चिप के साथ सिस्टम: AMD A6700, 8Gb DDR31800Mhx, Radeon 7660D 128bit

दोनों मामलों में ऑपरेटिंग सिस्टम विंडोज 7 SP1 है, विकास का वातावरण विजुअल स्टूडियो 2013 एक्सप्रेस + एएमडी एपीपी एसडीके 2.9 है।
एक परीक्षण भार के रूप में, हम 65 केबी से 65 एमबी तक - विभिन्न आकारों की स्मृति वस्तुओं को पढ़ेंगे / लिखेंगे और नक्शा / मानचित्रण करेंगे।

दो बार सोचने के बिना, चलो चार्ट पर चलते हैं। सभी मामलों में, फरसीसा अक्ष बाइट्स में मेमोरी की मात्रा को दर्शाता है, ऑर्डिनेट अक्ष - माइक्रोसेकंड में ऑपरेशन को पूरा करने का समय। असतत मेमोरी वाला वीडियो कार्ड ग्राफ के नाम पर "असतत GPU" के रूप में चिह्नित किया गया है, सीपीयू के साथ साझा मेमोरी वाले वीडियो कार्ड को "एकीकृत GPU" के रूप में चिह्नित किया गया है।

असतत ग्राफिक्स कार्ड

यह ग्राफ डेटा ट्रांसफर टाइम और वॉल्यूम के बीच एक रैखिक संबंध दिखाता है। एडाप्टर अपनी स्वयं की मेमोरी का उपयोग करता है, इसलिए परिणाम स्थिर हैं।


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



रेखांकन GPU मेमोरी से आवंटित बफर के मैपिंग / अनमैपिंग को चित्रित करता है। मैपिंग डिवाइस के एड्रेस स्पेस से होस्ट के स्पेस में मेमोरी के टुकड़े को मैप करने की एक प्रक्रिया है। अनमैपिंग करना रिवर्स प्रक्रिया है। चूंकि ये पता स्थान अपनी स्वयं की मेमोरी के साथ जीपीयू के लिए शारीरिक रूप से भिन्न हैं, यही कारण है कि अस्थायी बफ़र्स को पढ़ना / लिखना प्रदर्शन के लिए होता है।



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

एकीकृत ग्राफिक्स कार्ड

Host'a और Device'a के बीच साझा की गई मेमोरी के मामले में, परिणामों का बिखराव अधिक मजबूत है। यह साझा मेमोरी और नियंत्रक पर बढ़े हुए लोड का उपयोग करने की आवश्यकता द्वारा आसानी से समझाया गया है।



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



हालाँकि, यदि आप GPU मेमोरी से किसी ऑब्जेक्ट के लिए मेमोरी आवंटित करते हैं, तो ऑब्जेक्ट के वॉल्यूम पर रनटाइम की निर्भरता परिणामों के बढ़े हुए बिखराव के लिए समायोजित असतत ग्राफिक्स कार्ड का उपयोग करते समय देखी गई समान होगी।



फिर, यदि होस्ट द्वारा आवंटित मेमोरी का उपयोग किया जाता है, तो हमें बफर के आकार से स्वतंत्र, लगभग शून्य संचालन निष्पादन समय मिलता है।

निष्कर्ष

यह प्रयोग के दौरान पहचाने जाने वाले निम्नलिखित पैटर्न को ध्यान देने योग्य है:

• असतत मेमोरी के साथ वीडियो कार्ड का उपयोग कम बिखराव के साथ परिणाम देता है। यह साझा मेमोरी के उपयोग के कारण है। साझा मेमोरी का उपयोग, इसके विपरीत, संकेतकों के एक बड़े बिखराव की ओर जाता है।
• दोनों मामलों में, USE_HOST_PTR ध्वज का उपयोग असमान परिणामों में वृद्धि करता है।

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

मैपिंग तकनीक का उपयोग दोनों मामलों में किया जा सकता है। साझा मेमोरी के साथ एक प्रणाली पर, यह उपरोक्त फायदे देता है, एक असतत ग्राफिक्स कार्ड के साथ एक प्रणाली पर, यह केवल क्लासिक रीड / राइट सर्किट के समान रैखिक समय में काम करता है।