ओपनसीएल में सिम के अधिकांश को कैसे बनाया जाए?

Question

में optimization guide of Beignet, an open source implementation of OpenCL targeting Intel GPUs

कार्य समूह का आकार 16 से भी बड़ा हो सकता है और 16.

के गुणांक में होनी हैं जनरल पर दो संभावित SIMD गलियों 8 या 16 के रूप में SIMD गलियों बर्बाद नहीं करने के लिए करना चाहिए, हमें इस नियम का पालन करना होगा।

इसके अलावा Compute Architecture of Intel Processor Graphics Gen7.5 में उल्लेख किया है:

Gen7.5 आधारित उत्पादों के लिए, प्रत्येक यूरोपीय संघ (GRF) सामान्य प्रयोजन रजिस्टर फ़ाइल के 28 Kbytes के लिए कुल सात सूत्र है।

...

Gen7.5 गणना वास्तुकला पर, सबसे SPMD प्रोग्रामिंग मॉडल इस शैली कोड पीढ़ी और यूरोपीय संघ के प्रोसेसर निष्पादन को रोजगार। प्रभावी रूप से, प्रत्येक एसपीएमडी कर्नेल उदाहरण अपने स्वयं के सिम लेन के भीतर क्रमशः और स्वतंत्र रूप से निष्पादित होता प्रतीत होता है।

वास्तविकता में, प्रत्येक थ्रेड कर्नेल उदाहरणों की एक सिम-चौड़ाई संख्या को निष्पादित करता है> समवर्ती रूप से। इस प्रकार एक गणना गिरी का एक SIMD -16 संकलन के लिए , यह SIMD -16 x 7 धागे = 112 गिरी उदाहरणों एक भी यूरोपीय संघ पर समवर्ती क्रियान्वित होने के लिए संभव है। इसी प्रकार, सिम -32 x 7 धागे = 224 कर्नेल उदाहरण एक साथ ईयू पर समवर्ती रूप से निष्पादित करने के लिए।

अगर मैं इसे सही ढंग से समझते हैं, आदेश में एक यूरोपीय संघ पर 224 धागे को चलाने के लिए, एक उदाहरण के रूप में SIMD-16 x 7 threads = 112 kernel instances का उपयोग कर, कार्य समूह आकार 16. होने की जरूरत है तो फिर OpenCL संकलक एक 16 में 16 गिरी उदाहरणों गुना होगा लेन सिमड थ्रेड, और 7 कार्य समूहों पर यह 7 बार करें, और उन्हें एक ईयू पर चलाएं?

प्रश्न 1: क्या मैं यहां तक ​​सही हूं?

हालांकि OpenCL spec वेक्टर डेटा प्रकार भी प्रदान करते हैं। इसलिए यूरोपीय संघ में पारंपरिक सिम प्रोग्रामिंग (एनईओएन और एसएसई में) द्वारा सिम -16 कंप्यूटिंग संसाधनों का पूरा उपयोग करना संभव है।

प्रश्न 2: इस मामले में, वेक्टर -16 डेटा प्रकार उपयोग कर रहा है यदि पहले से ही इसलिए कम से कम-16-मद-प्रति-कार्य-समूह प्रतिबंध को हटा, SIMD -16 संसाधनों का स्पष्ट उपयोग करता है। क्या यह मामला है?

प्रश्न 3: तो सब से ऊपर एक सही है, तो कैसे दो दृष्टिकोण एक दूसरे के साथ तुलना: 1) 112 धागे 7 SIMD -16 धागे OpenCL संकलक द्वारा में गुना; 2) 7 मूल धागे वेक्टर -16 डेटा प्रकारों और सिम -16 परिचालनों का स्पष्ट रूप से उपयोग करने के लिए कोडित हैं?

Answer 1

1. लगभग। आप धारणाएं बना रहे हैं कि प्रति कार्य समूह में एक धागा है (इस संदर्भ में एनबी थ्रेड सीयूडीए "लहर" कहता है।इंटेल जीपीयू में एक कार्य आइटम एक जीपीयू थ्रेड का एक सिम चैनल है)। उपसमूहों के बिना, वर्कग्रुप आकार को बिल्कुल थ्रेड होने के लिए मजबूर करने का कोई तरीका नहीं है। उदाहरण के लिए, यदि आप 16 का डब्लूजीजी आकार चुनते हैं, तो कंपाइलर अभी भी सिमडी 8 संकलित करने के लिए स्वतंत्र है और इसे दो सिमडी 8 धागे के बीच फैलाता है। ध्यान रखें कि डब्ल्यूजी आकार ज्ञात होने से पहले संकलक सिम चौड़ाई चुनता है (clCompileProgramclEnqueueNDRange से पहले)। subgroups extension आपको सिम चौड़ाई को मजबूर करने की अनुमति दे सकता है, लेकिन निश्चित रूप से GEN7.5 पर लागू नहीं किया गया है।

2. ओपनसीएल वेक्टर प्रकार अंतर्निहित वेक्टरेशन के शीर्ष पर वैकल्पिक वैकल्पिक वेक्टरेशन चरण हैं जो पहले से ही स्वचालित रूप से होता है। उदाहरण के लिए आप float16 का उपयोग कर रहे थे। प्रत्येक कार्य आइटम प्रत्येक 16 फ्लोट्स प्रोसेसिंग करेगा, लेकिन संकलक अभी भी कम से कम SIMD8 संकलित करेगा। इसलिए प्रत्येक जीपीयू थ्रेड प्रसंस्करण (8 * 16) फ्लोट होगा (हालांकि समानांतर में)। यह थोड़ा अधिक हो सकता है। आदर्श रूप से हम स्पष्ट ओपनसीएल वेक्टर प्रकारों का उपयोग करके स्पष्ट रूप से हमारे सीएल को सदिश बनाना नहीं चाहते हैं। लेकिन यह कभी-कभी सहायक हो सकता है यदि कर्नेल पर्याप्त काम नहीं कर रहा है (कर्नेल जो बहुत कम हैं, खराब हो सकते हैं)। कहीं कहता है कि फ्लोट 4 अंगूठे का एक अच्छा नियम है।

3. मुझे लगता है कि आपका मतलब 112 काम आइटम था? देशी धागे से आप सीपीयू धागे या जीपीयू धागे का मतलब है?

   • यदि आप सीपीयू धागे का मतलब रखते हैं, तो GPUs के बारे में सामान्य तर्क लागू होते हैं। जीपीयू अच्छे होते हैं जब आपका प्रोग्राम ज्यादा अलग नहीं होता है (सभी उदाहरण समान पथ लेते हैं) और आप जीपीयू (अंकगणितीय घनत्व) से और उससे स्थानांतरित होने वाली लागत को कम करने के लिए पर्याप्त समय का उपयोग करते हैं।
   • यदि आप जीपीयू धागे (जीएन सिमडी 8 या सिमड 16 क्रिटर्स) का मतलब रखते हैं। इस समय GPU धागे को स्पष्ट रूप से प्रोग्राम करने के लिए कोई (सार्वजनिक रूप से दृश्यमान) तरीका नहीं है (EDITsubgroups extension (GEN7.5 पर उपलब्ध नहीं) देखें)। यदि आप सक्षम थे, तो यह असेंबली भाषा के लिए एक समान व्यापार होगा। नौकरी कठिन है, और संकलक कभी-कभी हम बेहतर काम कर सकते हैं, लेकिन जब आप किसी विशिष्ट समस्या को हल कर रहे हैं और बेहतर डोमेन ज्ञान प्राप्त कर रहे हैं, तो आप आम तौर पर पर्याप्त प्रोग्रामिंग प्रयास के साथ बेहतर कर सकते हैं (हार्डवेयर परिवर्तन और आपके चालाक कार्यक्रम की मान्यताओं तक अमान्य हो जाता है।)