आधुनिक GPU: वे "बुद्धिमान" कैसे हैं?


11

3 डी प्रोग्रामिंग (ओपनजीएल या डायरेक्टएक्स) और संबंधित ग्राफिक्स पाइपलाइनों पर कई संसाधन उपलब्ध हैं, लेकिन मैं सोच रहा हूं कि आधुनिक जीपीयू पर उन्हें किस स्तर पर लागू किया गया है।

अब तक मैं यह पता लगाने में सक्षम रहा हूं कि बहुत ही विशेष परिधि से एक चाल चली है जो ग्राफिक्स पाइपलाइन के विभिन्न चरणों को एक अधिक सामान्य दृष्टिकोण पर लागू करती है। यह परिवर्तन 3 डी एपीआई पर आंशिक रूप से प्रोग्राम करने योग्य शेड के रूप में परिलक्षित हुआ है। अधिकांश ट्रांजिस्टर बड़े पैमाने पर समानांतर SIMD इकाइयों के लिए समर्पित लगते हैं जो वास्तविक shader निर्देशों को निष्पादित करते हैं।

लेकिन बाकी ग्राफिक्स पाइपलाइन के बारे में क्या? क्या यह अभी भी हार्डवेयर में लागू है?

क्या एक आधुनिक GPU (Nvidia Fermi लगता है) मूल रूप से "बेवकूफ" SIMD सरणियों का एक सेट है जो सीपीयू और विभिन्न कैश से निर्देशों और डेटा के साथ खिलाया जाता है, और सभी वास्तविक तर्क जो उन ग्राफिक्स ग्राफ़ को मैप करते हैं जो ग्राफिक्स ड्राइवर में होते हैं। ?

या क्या GPU में कहीं न कहीं कुछ नियंत्रित करने वाली इकाइयाँ हैं जो आने वाले उच्च-स्तरीय निर्देश और डेटा स्ट्रीम (संकलित शेडर प्रोग्राम, वर्टेक्स डेटा और विशेषताएँ, और बनावट) का वास्तविक SIMD निर्देशों में अनुवाद करती हैं और सिंक्रनाइज़ेशन, मेमोरी आवंटन आदि का ध्यान रखती हैं?

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

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

जवाबों:


8

अब तक मैं यह पता लगाने में सक्षम रहा हूं कि बहुत ही विशेष परिधि से एक चाल चली है जो ग्राफिक्स पाइपलाइन के विभिन्न चरणों को एक अधिक सामान्य दृष्टिकोण पर लागू करती है। यह परिवर्तन 3 डी एपीआई पर आंशिक रूप से प्रोग्राम करने योग्य शेड के रूप में परिलक्षित हुआ है। अधिकांश ट्रांजिस्टर बड़े पैमाने पर समानांतर SIMD इकाइयों के लिए समर्पित लगते हैं जो वास्तविक shader निर्देशों को निष्पादित करते हैं।

सही बात। मूल रूप से, पुराने जीपीयू पर अपेक्षाकृत बड़े फीचर के आकार के कारण, बुनियादी प्रकाश व्यवस्था, एंटीलियासिंग, बनावट मैपिंग, ज्यामिति, आदि जैसी चीजों को कुशलता से लागू करने का एकमात्र तरीका एक "निश्चित फ़ंक्शन" पाइपलाइन का उपयोग करना था। उन्होंने प्रदर्शन के लिए लचीलेपन का त्याग किया क्योंकि उनके पास पर्याप्त चिप घनत्व नहीं था जो कि वर्तमान GPUs की तरह अधिक सामान्य व्यापक समानांतर SIMD वास्तुकला का उपयोग करके इसे लागू करने में सक्षम हो।

क्या एक आधुनिक GPU (Nvidia Fermi लगता है) मूल रूप से "बेवकूफ" SIMD सरणियों का एक सेट है जो सीपीयू और विभिन्न कैश से निर्देशों और डेटा के साथ खिलाया जाता है, और सभी वास्तविक तर्क जो उन ग्राफिक्स ग्राफ़ को मैप करते हैं जो ग्राफिक्स ड्राइवर में होते हैं। ?

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

यह सच है, सामान्य तौर पर, वर्तमान GPU आर्किटेक्चर जैसे कि Nvidia Fermi और AMD दक्षिणी द्वीप समूह, अधिकांश भाग के लिए, बड़े पैमाने पर समानांतर CPUs हैं जहां उनके पास एक कस्टम निर्देश सेट है, और प्रत्येक व्यक्ति "कोर" बेहद कमजोर है, लेकिन वहां कोर की एक पूरी बहुत (कभी-कभी कई हजार)। लेकिन वहाँ अभी भी ग्राफिक्स-विशिष्ट हार्डवेयर है:

  • हार्डवेयर वीडियो डिकोडिंग अक्सर, बड़े हिस्से में, निश्चित फ़ंक्शन चिप्स का उपयोग करके किया जाता है। यह विशेष रूप से सच है जब DRM (डिजिटल प्रतिबंध प्रबंधन) शामिल है। कभी-कभी "हार्डवेयर" वीडियो डिकोडिंग का वास्तव में निर्देशों का एक फर्मवेयर-निर्देशित सेट होता है, जो केवल SIMD कोर के लिए नियमित पुराने कार्यों के रूप में परोसा जाता है। यह वास्तव में निर्भर करता है।

  • बहुत कम कम्प्यूट-विशिष्ट एनवीडिया बोर्ड (टेस्ला) के अपवाद के साथ, लगभग सभी "जेनेरिक SIMD" ग्राफिक्स कार्ड में वीडियो आउटपुट के लिए समर्पित हार्डवेयर की एक पूरी सरणी होती है। वीडियो आउटपुट रेंडरिंग के समान नहीं है; फिक्स्ड फ़ंक्शन आउटपुट तत्वों में LVDS / TMDS / HDMI / DisplayPort codecs, HDCP और यहां तक ​​कि ऑडियो प्रोसेसिंग (मूल रूप से थोड़ा DSP) शामिल हैं, क्योंकि एचडीएमआई ऑडियो का समर्थन करता है।

  • "ग्राफिक्स मेमोरी" अभी भी जीपीयू के साथ ऑन-बोर्ड संग्रहीत है, ताकि उन्हें सिस्टम रैम को हिट करने के लिए गंदी और अपेक्षाकृत उच्च विलंबता PCIe बस का पता लगाने की ज़रूरत न पड़े, जो स्वयं धीमी है और अधिक महंगी की तुलना में अधिक समय तक जवाब देती है: उच्च गुणवत्ता, तेज ग्राफिक्स मेमोरी (जैसे GDDR5) जो छोटी क्षमताओं में आती है लेकिन सिस्टम मेमोरी की तुलना में उच्च गति है। ग्राफिक्स मेमोरी में सामान को स्टोर करने की प्रक्रिया और इसे वहां से GPU या CPU में पुनर्प्राप्त करने की प्रक्रिया अभी भी एक बहुत ही निश्चित फ़ंक्शन ऑपरेशन है। कुछ GPU में "IOMMU" का अपना प्रकार है, लेकिन यह मेमोरी मैनेजमेंट यूनिट CPU से अलग (अलग) है। यह सच नहीं है, हालांकि, हाल ही में इंटेल जीपीयू ने अपने प्रोसेसर (सैंडी और आइवी ब्रिज) में एकीकृत किया, जहां मेमोरी आर्किटेक्चर लगभग पूरी तरह से "सुसंगत" है। सिस्टम मेमोरी) और ग्राफिक्स मेमोरी से पढ़ता है सीपीयू के लिए उतना ही सस्ता है जितना कि वे GPU के लिए हैं।

या क्या GPU में कहीं न कहीं कुछ नियंत्रित करने वाली इकाइयाँ हैं जो आने वाले उच्च-स्तरीय निर्देश और डेटा स्ट्रीम (संकलित शेडर प्रोग्राम, वर्टेक्स डेटा और विशेषताएँ, और बनावट) का वास्तविक SIMD निर्देशों में अनुवाद करती हैं और सिंक्रनाइज़ेशन, मेमोरी आवंटन आदि का ध्यान रखती हैं?

SIMDs की "मूल" भाषा लगभग हमेशा सॉफ़्टवेयर में ड्राइवर द्वारा उत्पन्न होती है, और GPU के अपने फर्मवेयर द्वारा नहीं। यह DirectX 9 / OpenGL 2.x स्तर की विशेषताओं के लिए विशेष रूप से सच है। एचएलएसएल, जीएलएसएल या ओपनजीएल एआरबी शेडर असेंबलर जैसी उच्च स्तरीय भाषाओं में लिखे गए शेडर्स का अंततः ड्राइवर द्वारा, जीपीयू निर्देशों में कुछ रजिस्टरों पर धमाके करके और आवश्यक PCIe हुप्स को कंप्‍यूटर के बैच बफ़र पर भेजने और / या रेंडर करने के लिए किया जाता है। आदेशों।

हार्डवेयर टेसेलेशन (डायरेक्टएक्स 11 / ओपनजीएल 4.0) जैसी कुछ चीजें फिर से एक निश्चित-फ़ंक्शन तरीके से हार्डवेयर में धकेल दी जाती हैं, इसी तरह वे पुराने दिनों में लगभग सब कुछ करते थे। ऐसा इसलिए है क्योंकि, फिर से, प्रदर्शन की कमी के लिए यह आवश्यक है कि इन संगणनाओं को करने का सबसे कुशल तरीका फर्मवेयर या ड्राइवर "प्रोग्राम" करने के बजाय इसके लिए SIMDs करने के बजाय इसके लिए समर्पित सर्किटरी होना चाहिए।

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

AMD और Intel के पास अपने हालिया GPU के बारे में खुले में बहुत मजबूत प्रलेखन है, साथ ही लिनक्स के लिए पूरी तरह से खुले स्रोत ग्राफिक्स ड्राइवर हैं (मेसा और डायरेक्ट रेंडरिंग मैनेजर प्रोजेक्ट देखें)। यदि आप इन ड्राइवरों में से कुछ कोड को देखते हैं, तो आप हँसेंगे, क्योंकि ग्राफिक्स चालक लेखकों को वास्तव में "सॉफ्टवेयर" (लेकिन सॉफ्टवेयर कमांड का उपयोग करके वास्तविक प्रस्तुत करने के लिए विभिन्न आकृतियों या पैटर्न को खींचने जैसी चीजों की ज्यामिति को लागू करना होगा। प्रसंस्करण के लिए हार्डवेयर के लिए लेगवर्क), क्योंकि न तो GPU फर्मवेयर और न ही निश्चित फ़ंक्शन सामान अब इसे पूरी तरह से हार्डवेयर में संसाधित करने के लिए मौजूद है :) यह एक तरह से मज़ेदार है कि उन्हें नए पर OpenGL 1.x / 2.x का समर्थन करना है। हार्डवेयर।

विकास इस तरह से चला गया है:

  • बहुत पहले (वास्तविक समय 3 डी प्रतिपादन से पहले संभव माना जाता था): सीपीयू पर रे-ट्रेसिंग गैर-वास्तविक समय प्रतिपादन के लिए सामान्य थी। सरल ग्राफिक्स के लिए जैसे कि आप विंडोज के शुरुआती संस्करणों में देखते हैं, सीपीयू तेजी से तय किए गए हार्डवेयर के बिना सरल आकार (आयत, एक फ़ॉन्ट के चरित्र, छायांकन पैटर्न, आदि) खींचने के लिए पर्याप्त था, लेकिन यह बहुत जटिल सामान नहीं खींच सकता था।
  • बहुत पहले (ओपनजीएल 1.x): ठोस राज्य हार्डवेयर द्वारा लागू लगभग सब कुछ; "विद्युतीय" निश्चित कार्य बुनियादी कार्यों के लिए भी आदर्श थे
  • कुछ समय पहले (OpenGL 2.x): GPU को अधिक प्रोग्राम योग्य बनाने की दिशा में एक संक्रमण शुरू हो गया था। 5 साल पुराने हार्डवेयर पर "फ्रेगमेंट शेड्स" (उर्फ पिक्सेल शेड्स) लगभग सीपीयू की तरह मनमानी गणना कर सकता है , लेकिन यह आर्किटेक्चर द्वारा सीमित है, जो अभी भी ग्राफिक्स की ओर बहुत ज्यादा सक्षम है। इसलिए, OpenCL / DirectCompute इस हार्डवेयर पर उपलब्ध नहीं है।
  • हाल ही में (ओपनजीएल 3. एक्स): सामान्य प्रयोजन के जीपीयू के लिए संक्रमण ज्यादातर पूरा हो गया है, लेकिन वे निश्चित रूप से सीपीयू के बजाय बैचों में प्रस्तुत किए जा रहे डेटा के बड़े मैट्रिक्स (सोचते हैं रैखिक बीजगणित) से जुड़े वर्कलोड के लिए अनुकूलित हैं, जो कुशलता से काम कर सकते हैं बहुत छोटे डेटा के लंबे अनुक्रम (1 + 1, 2 * 4, 5 * 6 क्रम में, आदि) सामान्य उद्देश्य कंप्यूटिंग ओपनसीएल, CUDA, आदि के माध्यम से उपलब्ध है, लेकिन हार्डवेयर अभी भी एक पूर्ण "SIMD कॉपीरोसेसर" पर नहीं है क्योंकि (ए) आपको अभी भी GPU-कार्यक्षमता प्राप्त करने के लिए हार्डवेयर-विशिष्ट रजिस्टरों को हथौड़ा करना होगा; (b) PCI VR बस ओवरहेड के कारण GPU VRAM से पढ़ना बहुत धीमा है (GPU से पढ़ना बहुत बढ़िया आर्किटेक्चर पर अनुकूलित नहीं है); (c) मेमोरी और कैश आर्किटेक्चर CPU के साथ सुसंगत नहीं है; अभी भी बहुत सारी विरासत नियत फंक्शन हार्डवेयर आस-पास बिछे हुए हैं।
  • वर्तमान (ओपनजीएल 4.x): विरासत तय किए गए फंक्शन हार्डवेयर से बहुत कुछ मिल गया। GPU में सुधार हुआ विलंबता कुछ हद तक पढ़ें। IOMMUs VRAM और सिस्टम मेमोरी के बीच एक (अनुवादित) हार्डवेयर-असिस्टेड मैपिंग की अनुमति देता है। फिक्स्ड फ़ंक्शन के तत्वों को वापस लाते हुए, हार्डवेयर टेसेलेशन भी पेश किया।
  • भविष्य ( HSA)): GPU मूल रूप से एक सह-प्रोसेसर है। यह सभी और पूरी तरह से सीपीयू और सीपीयू और सीपीयू के बीच सीपीयू के साथ पूरी तरह से एकीकृत है, यहां तक ​​कि पीसीआई बस पर समर्पित जीपीयू के लिए भी। पूरी तरह से सुसंगत स्मृति वास्तुकला - "mi memoria es su memoria" (मेरी स्मृति आपकी स्मृति है)। यूजरस्पेस प्रोग्राम "वीआरएएम" से पढ़ सकते हैं, जैसे कि वे सिस्टम मेमोरी से पढ़ते हैं, जिसमें ड्राइवर शिम नहीं है, और हार्डवेयर इसकी देखभाल करता है। आपके पास "सीरियल" प्रसंस्करण के लिए सीपीयू है (ऐसा करें, फिर ऐसा करें, फिर ऐसा करें, फिर करें) डेटा की मामूली मात्रा के लिए, और GPU "समानांतर" प्रसंस्करण के लिए (इस ऑपरेशन को इस विशाल डेटासेट पर निष्पादित करें और इसे विभाजित करें आप कैसे फिट होते हैं)। बोर्ड जिस GPU पर बैठता है उसमें अभी भी ROP, HDMI कोडेक आदि हो सकते हैं, लेकिन यह आउटपुट डिस्प्ले आउटपुट के लिए आवश्यक है,

आपका अंतिम बिंदु बहुत अच्छा है, और यह सिर्फ OpenGL1.x / 2.x प्रकार की चीजों से अधिक पर भी लागू होता है। GPUs में तर्क की अविश्वसनीय जटिलता के कारण, यह लगभग एक दिया है कि कहीं न कहीं कीड़े होंगे। आमतौर पर तर्क में अधिकांश कीड़े शारीरिक चिप बनने से पहले ही चिढ़ जाते हैं, लेकिन कुछ अजीब कोने-मामले हो सकते हैं जो अभी भी फसल कर सकते हैं। जब ऐसा होता है, तो ड्राइवरों को हार्डवेयर के बग्गी भाग को बायपास करने के लिए स्वयं ही इस सुविधा को लागू करना होगा। इस तरह की चीजें अक्सर होती हैं, जिससे आपको ड्राइवर अपडेट में सुविधा / प्रदर्शन में वृद्धि हो सकती है।
बेन रिचर्ड्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.