एएमडी एपीपी एसडीके: कंप्यूट एब्स्ट्रक्शन लेयर (सीएएल)

पहले भाग में, मैंने AMD इंटरमीडिएट लैंग्वेज (IL) तकनीक के बारे में बात की। यह लेख, जैसा कि आप शीर्षक से अनुमान लगा सकते हैं, दूसरे घटक के बारे में बात करेंगे: एएमडी कंप्यूट एब्स्ट्रेक्शन लेयर (सीएएल)। ये दो प्रौद्योगिकियां एक-दूसरे से अविभाज्य हैं: एक का उपयोग किए बिना दूसरे का उपयोग करना असंभव है। इसलिए, आगे की समझ के लिए, मेरा सुझाव है कि आप पहले भाग से खुद को परिचित करें।

मैं AMD GPU के साथ शीर्ष स्तर पर काम करने के मुख्य पहलुओं को उजागर करने की कोशिश करूंगा, मैं इस तकनीक की सीमाओं और इसके साथ काम करते समय संभावित समस्याओं का वर्णन करूंगा। बिल्ली के नीचे, कौन परवाह करता है।

शुरू करने के बजाय

जब मैं एएमडी जीपीयू के लिए प्रोग्रामिंग समझना शुरू कर रहा था, तो उन्होंने मुझसे पूछा कि मैं इसके लिए क्या उपयोग करता हूं। "अति कैल, " मैंने जवाब दिया। "हाँ, अति वास्तव में सीएएल है, " मेरा जवाब था।
सामान्य तौर पर, मुझे पता नहीं है कि संक्षिप्त नाम CAL का उच्चारण कैसे करें, लेकिन मैं इसे "O" के माध्यम से उच्चारण करता हूं ताकि लोगों को शर्मिंदा न करें।

संक्षिप्तता के लिए, हम कर्नेल द्वारा पहले भाग में वर्णित कार्यक्रम को दर्शाते हैं। कर्नेल से मेरा मतलब प्रोग्राम के स्रोत कोड और GPU पर लोड किए गए संकलित, बाइनरी कोड दोनों से होगा। मैं AMD CAL के माध्यम से GPU के साथ काम करने वाले किसी भी कार्यक्रम का पूरा पाठ नहीं दूंगा, लेकिन बस काम के मुख्य बिंदुओं के बारे में बात करता हूं:

• चालक आरंभीकरण
• सभी समर्थित GPU के बारे में जानकारी प्राप्त करना
• स्मृति आवंटन और प्रतिलिपि
• GPU पर कर्नेल को संकलित और लोड करना
• कर्नेल लॉन्च
• सीपीयू सिंक्रनाइज़ेशन

आरंभ करने के लिए, हमें AMD APP SDK से दो हेडर फाइलें चाहिए:

• cal.h - ड्राइवर के मुख्य कार्यों का वर्णन करता है, फ़ंक्शन "cal" (aticalrt.dll लाइब्रेरी) के साथ उपसर्ग किए गए हैं
• calcl.h - बाइनरी कोड में टेक्स्ट कर्नेल कंपाइलर के मूल कार्यों का वर्णन करता है, फ़ंक्शन "calcl" (aticalcl.dll लाइब्रेरी) के साथ उपसर्ग किए जाते हैं

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

अधिकांश फ़ंक्शन कॉल प्रकार का मान कैलरेसल्ट लौटाते हैं। कुल 11 रिटर्न कोड उपलब्ध हैं। हमारे लिए सबसे महत्वपूर्ण कोड CAL_RESULT_OK है, 0 के बराबर (कॉल के सफल समापन को इंगित करता है)।

तो चलिए चलते हैं।

चालक का आरम्भ

नियम नंबर 1: GPU के साथ काम शुरू करने से पहले, अपने हाथ धो लें निम्नलिखित कॉल के साथ ड्राइवर को इनिशियलाइज़ करें:

CALresult result = calInit(); 

नियम संख्या 2: GPU के साथ काम करने के बाद काम को सही ढंग से पूरा करने के लिए अपने आप को कुल्ला करना न भूलें। यह निम्नलिखित कॉल द्वारा किया जाता है:

 CALresult result = calShutdown(); 

इन दो कॉल को हमेशा जोड़ा जाना चाहिए। कार्यक्रम में उनमें से कई (ऐसे जोड़े कॉल) हो सकते हैं, लेकिन इन कॉलों के बाहर जीपीयू के साथ कभी भी काम न करें: यह व्यवहार एक हार्डवेयर अपवाद को प्राप्त कर सकता है ।

GPU सूचना प्राप्त करना

हमें समर्थित GPU की संख्या का पता चलता है (सिस्टम में AMD GPU की कुल संख्या से कम हो सकता है):

 unsigned int deviceCount = 0; CALresult result = calDeviceGetCount( &deviceCount ); 

इस लेख में मैं इंगित करूंगा कि GPU पहचानकर्ता का उपयोग कहां किया जाता है, लेकिन मैं पहचानकर्ता 0. के तहत GPU के साथ "काम" करूंगा। सामान्य तौर पर, यह पहचानकर्ता 0 से (डिवाइसकाउंट -1) का मान लेता है।

GPU के बारे में जानकारी प्राप्त करें:

 unsigned int deviceId = 0; //  GPU CALdeviceinfo deviceInfo; CALresult result = calDeviceGetInfo( &deviceInfo, deviceId ); CALdeviceattribs deviceAttribs; deviceAttribs.struct_size = sizeof( deviceAttribs ); CALresult result = calDeviceGetAttribs( &deviceAttribs, deviceId ); 

CALdeviceinfo संरचना में सबसे महत्वपूर्ण बात GPU चिप पहचानकर्ता है। इसे यहाँ डिवाइस कर्नेल ISA के रूप में जाना जाता है :

 typedef struct CALdeviceinfoRec { CALtarget target; /**< Device Kernel ISA */ CALuint maxResource1DWidth; /**< Maximum resource 1D width */ CALuint maxResource2DWidth; /**< Maximum resource 2D width */ CALuint maxResource2DHeight; /**< Maximum resource 2D height */ } CALdeviceinfo; 

संरचना के शेष क्षेत्र दो निर्देशांक में बनावट स्मृति के अधिकतम आकार का निर्धारण करते हैं, जो इस जीपीयू पर आवंटित किया जा सकता है।

GPU विशेषताओं के लिए जिम्मेदार CALdeviceattribs संरचना अधिक दिलचस्प है (मैं केवल कुछ संरचना फ़ील्ड दूंगा):

 typedef struct CALdeviceattribsRec { CALtarget target; /**< Asic identifier (  Device Kernel ISA) */ CALuint localRAM; /**<   GPU RAM   */ CALuint wavefrontSize; /**<  warp'a (      ) */ CALuint numberOfSIMD; /**<   */ CALboolean computeShader; /**<   Compute Shader */ CALuint pitch_alignment; /**<        calCreateRes */ /*   */ } CALdeviceattribs; 

नियम संख्या 3: CALdeviceattribs.pitch_alignment फ़ील्ड को मेमोरी तत्वों में मापा जाता है, न कि बाइट्स में। मेमोरी तत्व 8-, 16- या 32-बिट रजिस्टरों का 1-, 2- या 4-घटक वेक्टर है।

और अब मान लेते हैं कि CALdeviceinfo.target फ़ील्ड (CALdeviceattribs.target) के मानों को करीब से देख सकते हैं:

 /** Device Kernel ISA */ typedef enum CALtargetEnum { CAL_TARGET_600, /**< R600 GPU ISA */ CAL_TARGET_610, /**< RV610 GPU ISA */ CAL_TARGET_630, /**< RV630 GPU ISA */ CAL_TARGET_670, /**< RV670 GPU ISA */ CAL_TARGET_7XX, /**< R700 class GPU ISA */ CAL_TARGET_770, /**< RV770 GPU ISA */ CAL_TARGET_710, /**< RV710 GPU ISA */ CAL_TARGET_730, /**< RV730 GPU ISA */ CAL_TARGET_CYPRESS, /**< CYPRESS GPU ISA */ CAL_TARGET_JUNIPER, /**< JUNIPER GPU ISA */ CAL_TARGET_REDWOOD, /**< REDWOOD GPU ISA */ CAL_TARGET_CEDAR, /**< CEDAR GPU ISA */ CAL_TARGET_RESERVED0, CAL_TARGET_RESERVED1, CAL_TARGET_WRESTLER, /**< WRESTLER GPU ISA */ CAL_TARGET_CAYMAN, /**< CAYMAN GPU ISA */ CAL_TARGET_RESERVED2, CAL_TARGET_BARTS, /**< BARTS GPU ISA */ } CALtarget; 

यह पता चला है कि यह फ़ील्ड उस चिप को दर्शाता है जिस पर GPU बनाया गया है। इस प्रकार, यह पता लगाना असंभव है कि दुनिया में GPU को क्या कहा जाता है (उदाहरण के लिए, Radeon HD 3850) AMD CAL का उपयोग करके! यहाँ इस तरह की एक सुविधाजनक तकनीक है ... लेकिन यह देखना दिलचस्प था कि, उदाहरण के लिए, Radeon HD 5750 और Radeon HD 6750 वास्तव में एक ही वीडियो कार्ड हैं! वे केवल मेमोरी ऑपरेशन की आवृत्ति में (कुछ प्रतिशत के भीतर) भिन्न होते हैं।

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

आगे के काम के लिए, हमें एक डिवाइस डिस्क्रिप्टर (डिवाइस) बनाने की आवश्यकता है, जिसके साथ हम GPU के साथ बातचीत करेंगे:

 unsigned int deviceId = 0; //  GPU CALdevice device; CALresult result = calDeviceOpen( &device, deviceId ); CALcontext context; result = calCtxCreate( &context, device ); 

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

डिवाइस के साथ काम खत्म करने के बाद युग्मित कॉल के बारे में मत भूलना:

 calCtxDestroy( context ); calDeviceClose( device ); 

इस क्रम में कॉल जाना चाहिए, अन्यथा हमें एक हार्डवेयर अपवाद मिलता है ।

इसलिए, हमने इसके लिए डिवाइस और संदर्भ बनाया, अब हम शुरू कर सकते हैं

मेमोरी आवंटन

मेमोरी के साथ काम करने के लिए, आपको एक संसाधन आवंटित करने की आवश्यकता है। प्रलेखन के अनुसार, संसाधन स्थानीय मेमोरी (स्थानीय मेमोरी = स्ट्रीम प्रोसेसर मेमोरी) और रिमोट मेमोरी (रिमोट मेमोरी = सिस्टम मेमोरी) में स्थित हो सकता है। जैसा कि मैं इसे समझता हूं, रिमोट मेमोरी रैम से ज्यादा कुछ नहीं है, जबकि स्थानीय मेमोरी स्वयं GPU की मेमोरी है।

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

 CALresource resource; unsigned int memoryWidth; unsigned int memoryHight; CALformat memoryFormat; unsigned int flags; //      // 1D  CALresult result = calResAllocRemote1D( &resource, &device, 1, memoryWidth, memoryFormat, flags ); /*         GPU,    -     ,   -      (1   ) */ // 2D  CALresult result = calResAllocRemote2D( &resource, &device, 1, memoryWidth, memoryHeight, memoryFormat, flags ); //      // 1D  CALresult result = calResAllocLocal1D( &resource, device, memoryWidth, memoryFormat, flags ); /*  ,       ,       */ // 2D  CALresult result = calResAllocLocal2D( &resource, device, memoryWidth, memoryHeight, memoryFormat, flags ); 

आवंटित संसाधन की चौड़ाई और ऊंचाई को स्मृति तत्वों में मापा जाता है।
मेमोरी तत्व को मेमोरीफॉर्म पैरामीटर द्वारा वर्णित किया गया है:

 //  ,         /** Data format representation */ typedef enum CALformatEnum { CAL_FORMAT_UNORM_INT8_1, /**< 1 component, normalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNORM_INT8_4, /**< 4 component, normalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNORM_INT32_1, /**< 1 component, normalized unsigned 32-bit integer value per component */ CAL_FORMAT_UNORM_INT32_4, /**< 4 component, normalized unsigned 32-bit integer value per component */ CAL_FORMAT_SNORM_INT8_1, /**< 1 component, normalized signed 8-bit integer value per component */ CAL_FORMAT_SNORM_INT8_4, /**< 4 component, normalized signed 8-bit integer value per component */ CAL_FORMAT_SNORM_INT32_1, /**< 1 component, normalized signed 32-bit integer value per component */ CAL_FORMAT_SNORM_INT32_4, /**< 4 component, normalized signed 32-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT8_1, /**< 1 component, unnormalized unsigned 8-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT8_4, /**< 4 component, unnormalized unsigned 8-bit integer value per component */ CAL_FORMAT_SIGNED_INT8_1, /**< 1 component, unnormalized signed 8-bit integer value per component */ CAL_FORMAT_SIGNED_INT8_4, /**< 4 component, unnormalized signed 8-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT32_1, /**< 1 component, unnormalized unsigned 32-bit integer value per component */ CAL_FORMAT_UNSIGNED_INT32_4, /**< 4 component, unnormalized unsigned 32-bit integer value per component */ CAL_FORMAT_SIGNED_INT32_1, /**< 1 component, unnormalized signed 32-bit integer value per component */ CAL_FORMAT_SIGNED_INT32_4, /**< 4 component, unnormalized signed 32-bit integer value per component */ CAL_FORMAT_UNORM_SHORT_565, /**< 3 component, normalized 5-6-5 RGB image. */ CAL_FORMAT_UNORM_SHORT_555, /**< 4 component, normalized x-5-5-5 xRGB image */ CAL_FORMAT_UNORM_INT10_3, /**< 4 component, normalized x-10-10-10 xRGB */ CAL_FORMAT_FLOAT32_1, /**< A 1 component, 32-bit float value per component */ CAL_FORMAT_FLOAT32_4, /**< A 4 component, 32-bit float value per component */ CAL_FORMAT_FLOAT64_1, /**< A 1 component, 64-bit float value per component */ CAL_FORMAT_FLOAT64_2, /**< A 2 component, 64-bit float value per component */ } CALformat; 

यह अफ़सोस की बात है कि पुराने वीडियो कार्ड (एवरग्रीन नहीं) पर 64-बिट संचालन केवल प्रकार के डेटा के साथ किया जा सकता है ...

नियम संख्या 4: तत्व प्रारूप केवल उसी तरीके का वर्णन करता है जिस तरह से GPU इस तत्व में पड़े डेटा की व्याख्या करेगा। शारीरिक रूप से, एक तत्व हमेशा 16 बाइट्स मेमोरी में रहता है।

इसे समझा जा सकता है यदि हम याद रखें कि पहले भाग में हमने संसाधन का वर्णन इस प्रकार किया है:

 dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) 

और एएमडी आईएल भाषा विनिर्देश के अनुसार, fmtx-fmtw मूल्यों की आवश्यकता है। अर्थात्, निम्न कोड (कुछ इस तरह से 1-घटक वेक्टर प्रकार के तत्वों के साथ एक बनावट का वर्णन कर सकता है) गलत है:

 dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint) 

नियम संख्या 5: उन प्रकारों का निरीक्षण करें जिन्हें आप कर्नेल में घोषित करते हैं और संसाधन आवंटित करते समय। यदि वे मेल नहीं खाते हैं, तो आप संसाधन को कर्नेल से बाँध नहीं सकते।

नियम संख्या 6: निरंतर स्मृति के लिए, तत्व प्रकार हमेशा फ्लोट का प्रकार होना चाहिए।

ऐसा क्यों किया जाता है यह मेरे लिए स्पष्ट नहीं है, क्योंकि आप अभी भी पूर्णांक मानों को निरंतर मेमोरी (जो हम उदाहरण में करते हैं) से लोड कर सकते हैं।

मेमोरी आवंटित करते समय ज़रूरत पड़ने वाले झंडे के बारे में कुछ और शब्द:

 /** CAL resource allocation flags **/ typedef enum CALresallocflagsEnum { CAL_RESALLOC_GLOBAL_BUFFER = 1, /**< used for global import/export buffer */ CAL_RESALLOC_CACHEABLE = 2, /**< cacheable memory? */ } CALresallocflags; 

मैंने दूसरे झंडे के साथ कभी काम नहीं किया, जब यह फायदा देता है, मुझे नहीं पता। और खुद लेखकों की टिप्पणियों में प्रश्न चिह्न को देखते हुए, वे भी पता नहीं (मुस्कान) में हैं।
लेकिन पहले झंडे को एक वैश्विक बफर ("जी []") आवंटित करने की आवश्यकता है।

अब सिद्धांत को व्यवहार में लाएं। पिछले लेख में वर्णित उदाहरण को ध्यान में रखते हुए, हमने कर्नेल स्टार्टअप पैरामीटर भी निर्धारित किए हैं:

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    //    cb0 CALresource constantResource; CALresult result = calResAllocLocal1D( &constantResource, device, 1, CAL_FORMAT_FLOAT32_4, 0 ); //    i0 CALresource textureResource; result = calResAllocLocal2D( &textureResource, device, threads, blocks, CAL_FORMAT_UNSIGNED_INT32_4, 0 ); //    g[] CALresource globalResource; result = calResAllocLocal1D( &globalResource, device, threads * blocks, CAL_FORMAT_UNSIGNED_INT32_4, CAL_RESALLOC_GLOBAL_BUFFER ); 

संसाधनों की अब आवश्यकता नहीं होने के बाद, उन्हें मुक्त करने की आवश्यकता होगी:

 calResFree( constantResource ); calResFree( textureResource ); calResFree( globalResource ); 

स्मृति की प्रतिलिपि बनाएँ

स्मृति तक सीधी पहुँच प्राप्त करना

यदि GPU अपनी मेमोरी को मैप करने में मदद करता है (इसके मेमोरी एड्रेस को प्रोसेस एड्रेस स्पेस में मैप कर रहा है), तो हम इस मेमोरी को पॉइंटर प्राप्त कर सकते हैं, और फिर इसके साथ काम कर सकते हैं, जैसे कि कोई अन्य मेमोरी:

 unsigned int pitch; unsigned char* mappedPointer; CALresult result = calResMap( (CALvoid**)&mappedPointer, &pitch, resource, 0 ); //    ,   ,    

और हम मेमोरी के साथ काम खत्म करने के बाद, आपको सूचक को मुक्त करने की आवश्यकता है:

 CALresult result = calResUnmap( resource ); 

नियम संख्या 7: हमेशा याद रखें कि GPU मेमोरी के साथ काम करते समय आपको संरेखण पर विचार करने की आवश्यकता होती है। यह संरेखण चर पिच द्वारा विशेषता है।

नियम संख्या 8: पिच को तत्वों में मापा जाता है, बाइट्स में नहीं।

आपको इस संरेखण के बारे में जानने की आवश्यकता क्यों है? तथ्य यह है कि, रैम के विपरीत, GPU मेमोरी हमेशा एक निरंतर क्षेत्र नहीं है। यह विशेष रूप से सच है जब बनावट के साथ काम करते हैं। मैं उदाहरण समझाता हूं: यदि आप 100x100 तत्वों की बनावट के साथ काम करना चाहते हैं, और calResMap () फ़ंक्शन ने 200 का पिच मूल्य वापस कर दिया है, तो इसका मतलब है कि वास्तव में GPU 200x100 की बनावट के साथ काम करेगा, बस पहले 100 को प्रत्येक बनावट लाइन में ध्यान में रखा जाएगा। तत्वों।

पिच मूल्य के आधार पर GPU मेमोरी में प्रतिलिपि बनाई जा सकती है:

 unsigned int pitch; unsigned char* mappedPointer; unsigned char* dataBuffer; CALresult result = calResMap( (CALvoid**)&mappedPointer, &pitch, resource, 0 ); unsigned int width; unsigned int height; unsigned int elementSize = 16; if( pitch > width ) { for( uint index = 0; index < height; ++index ) { memcpy( mappedPointer + index * pitch * elementSize, dataBuffer + index * width * elementSize, width * elementSize ); } } else { memcpy( mappedPointer, dataBuffer, width * height * elementSize ); } 

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

 // w - word, 16  // wi.j - i- word, j-  // x -  [ w0.0 | w0.1 | x | x ][ w1.0 | w1.1 | x | x ][ x | x | x | x ][ x | x | x | x ] 

संसाधनों के बीच डेटा की प्रतिलिपि बनाएँ

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

 CALresource inputResource; CALresource outputResource; CALmem inputResourceMem; CALmem outputResourceMem; //     CALresult result = calCtxGetMem( &inputResourceMem, context, inputResource ); result = calCtxGetMem( &outputResourceMem, context, outputResource ); //   CALevent syncEvent; result = calMemCopy( &syncEvent, context, inputResourceMem, outputResourceMem, 0 ); //    ,   ,    //     while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

GPU पर कर्नेल को संकलित और लोड करना

"एक सुई में कोशे की मौत, एक अंडे में एक सुई, एक बतख में एक अंडा, एक बतख में एक बतख, एक छाती में एक खरगोश ..."

GPU पर कर्नेल को लोड करने की प्रक्रिया को निम्नानुसार वर्णित किया जा सकता है: स्रोत (txt) को किसी ऑब्जेक्ट (ऑब्जेक्ट) में संकलित किया जाता है, फिर एक या एक से अधिक ऑब्जेक्टर्स को एक इमेज (इमेज) में लिंक किया जाता है, जिसे बाद में GPU मॉड्यूल (मॉड्यूल) में लोड किया जाता है और पहले से ही आप प्राप्त कर सकते हैं मॉड्यूल कर्नेल प्रवेश बिंदु के लिए सूचक (यह सूचक हमें निष्पादन के लिए कर्नेल शुरू करने की अनुमति देता है)।

और अब, यह कैसे लागू किया जा रहा है:

 const char* kernel; //       // ,   GPU  unsigned int deviceId = 0; //  GPU CALdeviceinfo deviceInfo; CALresult result = calDeviceGetInfo( &deviceInfo, deviceId ); //   CALobject obj; result = calclCompile( &obj, CAL_LANGUAGE_IL, kernel, deviceInfo.target ); //     CALimage image; result = calclLink( &image, &obj, 1 ); //   -  ,  -   //     ,   result = calclFreeObject( obj ); //     CALmodule module; result = calModuleLoad( &module, context, image ); //      CALfunc function; result = calModuleGetEntry( &function, context, module, "main" ); 

नियम संख्या 9: कर्नेल में प्रवेश बिंदु हमेशा एक होता है, क्योंकि लिंक करने के बाद केवल एक फ़ंक्शन होता है - "मुख्य" फ़ंक्शन।

अर्थात, Nvidia CUDA के विपरीत, AMD CAL कोर में केवल एक वैश्विक फ़ंक्शन "मुख्य" हो सकता है।

जैसा कि आपने देखा होगा कि कंपाइलर केवल IL में लिखे सोर्स कोड को प्रोसेस कर सकता है।

मॉड्यूल में छवि को लोड करना इस तथ्य से समझाया गया है कि छवि को चयनित GPU संदर्भ में लोड करने की आवश्यकता है। इसलिए, वर्णित संकलन प्रक्रिया प्रत्येक जीपीयू के लिए किया जाना चाहिए (मामले के अलावा जब 2 एक ही जीपीयू हैं: यह एक बार संकलन और लिंक करने के लिए पर्याप्त है, लेकिन आपको अभी भी प्रत्येक कार्ड के लिए मॉड्यूल में छवि को लोड करना होगा)।

मैं कई ऑब्जेक्ट मालिकों को जोड़ने की संभावना पर ध्यान आकर्षित करना चाहता हूं। हो सकता है कि यह अवसर किसी के लिए उपयोगी हो। मेरी राय में, इसे एक ही सबफ़ंक्शन के विभिन्न कार्यान्वयनों के मामले में लागू किया जा सकता है: इन कार्यान्वयनों को अलग-अलग ऑब्जेक्ट्स में ले जाया जा सकता है, क्योंकि एएमडी आईएल में #ifdef जैसे प्रीप्रोसेसर निर्देश नहीं हैं।

GPU पर कर्नेल का निष्पादन पूरा होने के बाद, उपयुक्त संसाधनों को मुक्त करना आवश्यक होगा:

 CALresult result = calclFreeImage( image ); result = calModuleUnload( context, module ); 

कर्नेल लॉन्च

कर्नेल लॉन्च विकल्प सेट करना

इसलिए, हमारे पास संसाधन, पूर्ण मेमोरी और एक संकलित कर्नेल है। यह केवल संसाधनों को हमारे विशिष्ट कोर से बांधने और इसे चलाने के लिए बना हुआ है। ऐसा करने के लिए, आपको कर्नेल से इसके लॉन्च पैरामीटर प्राप्त करने की आवश्यकता है, और संसाधन को संदर्भ में मैप करें।

 const char* memoryName; //    ,       //      CALname kernelParameter; CALresult result = calModuleGetName( &kernelParameter, context, module, memoryName ); //     CALmem resourceMem; result = calCtxGetMem( &resourceMem, context, resource ); //         result = calCtxSetMem( context, kernelParameter, resourceMem ); 

और अब हम इसे अपने उदाहरण के हिस्से के रूप में करते हैं:

 CALname kernelParameter; CALmem resourceMem; //      CALresult result = calModuleGetName( &kernelParameter, context, module, "cb0" ); result = calCtxGetMem( &resourceMem, context, constantResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); //      result = calModuleGetName( &kernelParameter, context, module, "i0" ); result = calCtxGetMem( &resourceMem, context, textureResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); //      result = calModuleGetName( &kernelParameter, context, module, "g[]" ); result = calCtxGetMem( &resourceMem, context, globalResource ); result = calCtxSetMem( context, kernelParameter, resourceMem ); 

GPU पर कर्नेल के निष्पादन के पूरा होने के बाद, कर्नेल से संसाधनों को अनटाइट करना आवश्यक होगा। इसे इस तरह किया जा सकता है:

 CALname kernelParameter; //      CALresult result = calModuleGetName( &kernelParameter, context, module, "cb0" ); result = calCtxSetMem( context, kernelParameter, 0 ); //      result = calModuleGetName( &kernelParameter, context, module, "i0" ); result = calCtxSetMem( context, kernelParameter, 0 ); //      result = calModuleGetName( &kernelParameter, context, module, "g[]" ); result = calCtxSetMem( context, kernelParameter, 0 ); 

अब कर्नेल को पता है कि डेटा कहां मिलेगा। यह छोटे के लिए मामला है:

कर्नेल लॉन्च

जैसा कि आपको याद है, पहले भाग में मैंने PS और CS शेड्स का उल्लेख किया था। आप यह जान सकते हैं कि क्या उत्तरार्द्ध GPU विशेषताओं द्वारा समर्थित है (ऊपर देखें)।

पुनश्च लॉन्च:

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    CALdomain domain; domain.x = 0; domain.y = 0; domain.width = threads; domain.height = blocks; CALevent syncEvent; CALresult result = calCtxRunProgram( &syncEvent, context, function, &domain ); while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

यहां, फ़ंक्शन कर्नेल प्रविष्टि बिंदु है जो हमें GPU पर कर्नेल को लोड करने के चरण में मिला है (ऊपर "GPU पर कर्नेल को संकलित और लोड करना" देखें)।

नियम संख्या 10: PS को धागे के मूल्य का पता नहीं है, इसे मेमोरी के माध्यम से प्रसारित किया जाना चाहिए (हमारे उदाहरण में, यह निरंतर मेमोरी के माध्यम से किया जाता है)।

सीएस लॉन्च:

 unsigned int blocks = 4; //  4  unsigned int threads = 64; //  64    CALprogramGrid programGrid; programGrid.func = function; programGrid.flags = 0; programGrid.gridBlock.width = threads; programGrid.gridBlock.height = 1; programGrid.gridBlock.depth = 1; programGrid.gridSize.width = blocks; programGrid.gridSize.height = 1; programGrid.gridSize.depth = 1; CALevent syncEvent; CALresult result = calCtxRunProgramGrid( &syncEvent, context, &programGrid ); while( calCtxIsEventDone( context, syncEvent ) == CAL_RESULT_PENDING ); 

नियम संख्या 11: थ्रेड्स का मान कर्नेल के स्रोत कोड में टूटे हुए मूल्य के अनुरूप होना चाहिए। कर्नेल को किसी भी स्थिति में लॉन्च किया जाएगा, हालाँकि, आप या तो मेमोरी की सीमा से परे जा सकते हैं (कर्नेल में घोषित किए गए कम थ्रेड की लॉन्चिंग), या सभी इनपुट डेटा संसाधित नहीं होंगे (कर्नेल में घोषित किए गए से अधिक थ्रेड का लॉन्च)।

हो गया! कर्नेल शुरू हो गया है, और अगर सब कुछ ठीक हो गया है, तो संसाधित डेटा आउटपुट मेमोरी ("जी []") में है। यह केवल उन्हें कॉपी करने के लिए बना हुआ है (ऊपर "मेमोरी को कॉपी करना" अनुभाग देखें)।

उपयोगी विशेषताएं

यह केवल कुछ कार्यों का उल्लेख करने के लिए बनी हुई है जो रोजमर्रा की जिंदगी में उपयोगी हो सकती हैं।

 CALresult result; //     CALdevicestatus status; result = calDeviceGetStatus( &status, device ); //      GPU  result = calCtxFlush( context ); //       ( ) CALfunc function; CALfuncInfo functionInfo; result = calModuleGetFuncInfo( &functionInfo, context, module, function ); /*      ,       (     ,      ) */ //        aticalrt.dll const char* errorString = calGetErrorString(); //        aticalcl.dll () const char* errorString = calclGetErrorString(); 

क्रॉस-थ्रेड सिंक्रनाइज़ेशन

एनवीडिया क्यूडा के विपरीत, यदि आप विभिन्न थ्रेड्स से जीपीयू के साथ काम कर रहे हैं तो आपको संदर्भ के साथ अतिरिक्त क्रियाएं करने की आवश्यकता नहीं है। लेकिन अभी भी कुछ सीमाएं हैं।

नियम संख्या 12: CAL संकलक के सभी कार्य थ्रेड-सुरक्षित नहीं हैं । एक आवेदन के भीतर, एक समय में केवल एक धागा संकलक के साथ काम कर सकता है।

नियम 13: मुख्य सीएएल पुस्तकालय के सभी कार्य जो एक विशिष्ट संदर्भ / उपकरण विवरणक (संदर्भ / उपकरण) के साथ काम करते हैं, थ्रेड-सुरक्षित हैं। अन्य सभी कार्य थ्रेड सुरक्षित नहीं हैं ।

नियम संख्या 14: एक समय में केवल एक आवेदन धागा एक विशिष्ट संदर्भ के साथ काम कर सकता है।

निष्कर्ष

मैंने सबसे सुलभ तरीके से एएमडी सीएएल और एएमडी आईएल प्रौद्योगिकियों का वर्णन करने की कोशिश की , ताकि कोई भी स्क्रैच से लगभग एएमडी जीपीयू के लिए एक सरल आवेदन लिख सके। मुख्य बात यह है कि हमेशा एक सुनहरा नियम याद रखें: RTFM!

आशा है कि आपको पढना दिलचस्प लगा होगा

परिचित के लिए लिंक

• एएमडी त्वरित समानांतर एसडीके
• AMD गणना अमूर्त परत (CAL)
• AMD मध्यवर्ती भाषा (IL)