OpenGL सबसे निचले स्तर पर कैसे काम करता है? [बन्द है]

Question

मैं समझता हूं कि ओपनजीएल / डायरेक्टएक्स कार्यक्रमों को कैसे लिखना है, और मैं गणित और इसके पीछे के वैचारिक सामान को जानता हूं, लेकिन मैं उत्सुक हूं कि जीपीयू-सीपीयू संचार निम्न स्तर पर कैसे काम करता है।

मान लीजिए कि मुझे C में लिखा गया एक OpenGL प्रोग्राम मिला है जो एक त्रिकोण को प्रदर्शित करता है और कैमरा को 45 डिग्री से घुमाता है। जब मैं इस कार्यक्रम को संकलित करता हूं, तो क्या इसे ioctl-calls की एक श्रृंखला में बदल दिया जाएगा, और gpu ड्राइवर तब gpu को उपयुक्त कमांड भेजता है, जहां त्रिकोण को घुमाने और उपयुक्त रंग में उपयुक्त पिक्सेल सेट करने के सभी तर्क वायर्ड हैं में? या क्या प्रोग्राम को एक "gpu प्रोग्राम" में संकलित किया जाएगा जो gpu पर लोड किया गया है और रोटेशन आदि की गणना करता है? या कुछ और पूरी तरह से अलग?

संपादित करें : कुछ दिनों बाद मुझे यह लेख श्रृंखला मिली, जो मूल रूप से इस सवाल का जवाब देती है: http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part- 1 /

Comments

OpenGL विनिर्देश स्टेटमेंट जो क्लाइंट / सर्वर मोड में भेजे जाते हैं। OpenGL कार्यान्वयन द्वारा उपयोग किए जाने वाले विशिष्ट टेक्नोलोजी को निर्धारित करने के लिए विनिर्देश बहुत व्यापक है।

— लुका

Answer 1

इस सवाल का जवाब देना लगभग असंभव है क्योंकि ओपनजीएल केवल एक फ्रंट एंड एपीआई है, और जब तक एक कार्यान्वयन विनिर्देश का पालन करता है और परिणाम इसके अनुरूप होता है, इसे किसी भी तरह से किया जा सकता है।

सवाल यह हो सकता है: एक ओपनजीएल ड्राइवर न्यूनतम स्तर पर कैसे काम करता है। अब यह सामान्य रूप से जवाब देने के लिए फिर से असंभव है, क्योंकि एक ड्राइवर हार्डवेयर के कुछ टुकड़े के करीब है, जो फिर से चीजें कर सकता है, हालांकि डेवलपर ने इसे डिज़ाइन किया है।

तो सवाल यह होना चाहिए था: "यह ओपेन के दृश्यों और ग्राफिक्स सिस्टम के पीछे औसतन कैसे दिखता है?"। आइए नीचे से इसे देखें:

1. सबसे निचले स्तर पर कुछ ग्राफिक्स डिवाइस हैं। आजकल ये GPU हैं जो अपने ऑपरेशन को नियंत्रित करने वाले रजिस्टरों का एक सेट प्रदान करते हैं (जो कि वास्तव में डिवाइस पर निर्भर है) shaders के लिए कुछ प्रोग्राम मेमोरी, इनपुट डेटा के लिए बल्क मेमोरी (कोने, बनावट आदि) और बाकी हिस्सों के लिए एक I / O चैनल है। उस प्रणाली पर, जिस पर वह डेटा और कमांड स्ट्रीम भेजता / भेजती है।

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

3. फिर ड्राइवर पर निर्भर OpenGL क्लाइंट लाइब्रेरी / ड्राइवर है। विंडोज पर यह प्रॉक्सी द्वारा opengl32.dll के माध्यम से लोड हो जाता है, यूनिक्स सिस्टम पर यह दो स्थानों पर रहता है:

   • X11 GLX मॉड्यूल और ड्राइवर निर्भर GLX ड्राइवर
   • और /usr/lib/libGL.so में सीधे रेंडरिंग के लिए कुछ ड्राइवर पर निर्भर सामान हो सकते हैं

   MacOS X पर यह "OpenGL फ्रेमवर्क" होता है।

   यह वह हिस्सा है जो OpenGL कॉल का अनुवाद करता है कि आप इसे कैसे (2) में वर्णित ड्राइवर के हिस्से में ड्राइवर विशिष्ट कार्यों में कॉल करते हैं।

4. अंत में विंडोज में वास्तविक OpenGL API लाइब्रेरी, opengl32.dll, और Unix /usr/lib/libGL.so पर; यह ज्यादातर ओपनजीएल कार्यान्वयन के लिए उचित आदेशों को पूरा करता है।

वास्तविक संचार कैसे होता है इसका सामान्यीकरण नहीं किया जा सकता है:

यूनिक्स में 3 <-> 4 कनेक्शन सॉकेट्स के ऊपर भी हो सकते हैं (हाँ, यह हो सकता है, और यदि आप चाहते हैं तो नेटवर्क पर जा सकते हैं) या साझा मेमोरी के माध्यम से। विंडोज में इंटरफ़ेस लाइब्रेरी और ड्राइवर क्लाइंट दोनों को प्रोसेस एड्रेस स्पेस में लोड किया जाता है, इसलिए यह इतना संचार नहीं है लेकिन सरल फ़ंक्शन कॉल और चर / पॉइंटर पासिंग है। MacOS X में यह Windows के समान है, केवल यह कि OpenGL इंटरफ़ेस और ड्राइवर क्लाइंट के बीच कोई अलगाव नहीं है (यही कारण है कि MacOS X नए OpenGL संस्करणों के साथ रखने के लिए इतना धीमा है, इसे हमेशा नया वितरित करने के लिए पूर्ण ऑपरेटिंग सिस्टम अपग्रेड की आवश्यकता होती है ढांचा)।

कम्यूनिकेशन betwen 3 <-> 2 ioctl के माध्यम से जा सकते हैं, पढ़ सकते हैं / लिख सकते हैं, या कुछ मेमोरी को प्रोसेस एड्रेस स्पेस में मैप कर सकते हैं और जब भी उस मेमोरी में बदलाव होते हैं तो कुछ ड्राइवर कोड को ट्रिगर करने के लिए MMU को कॉन्फ़िगर किया जा सकता है। यह किसी भी ऑपरेटिंग सिस्टम पर काफी समान है क्योंकि आपको हमेशा कर्नेल / यूजरलैंड सीमा को पार करना पड़ता है: आखिरकार आप कुछ सिसली के माध्यम से जाते हैं।

सिस्टम और GPU के बीच संचार परिधीय बस और इसे परिभाषित करने वाली एक्सेस विधियों के माध्यम से होता है, इसलिए PCI, AGP, PCI-E, आदि, जो पोर्ट- I / O, मेमोरी मैप्ड I / O, DMA, IRQ के माध्यम से काम करते हैं।

Comments

यह विवरण संभवतः बहुत कम-स्तरीय है और बहुत कम ओपनगैलिक्स के साथ सामान्य है। यह कंप्यूटर में मौजूद किसी भी हार्डवेयर कंपोनेंट पर लागू होता है।

— v। शशेंको

@ v.shashenko: ठीक है, बिल्कुल। भले ही आप किस हार्डवेयर घटक से बात कर रहे हों, यह इस सामान्य योजना का अनुसरण करता है। लेकिन ओपनजीएल सॉफ्टवेयर का एक विशेष टुकड़ा नहीं है, यह सिर्फ एक विनिर्देश है और विनिर्देश के अनुरूप कुछ भी एक वैध कार्यान्वयन है। और क्योंकि अंत में एक OpenGL कार्यान्वयन एक GPU से बात कर रहा है, यह मोटे तौर पर उसी स्क्रिप्ट का पालन करेगा जिसके साथ API का सामना करने वाले हार्डवेयर कार्यान्वित किए जाते हैं। इससे अधिक विशिष्ट बनना असंभव है, क्योंकि " द वन " ओपेनग्ल कार्यान्वयन नहीं है। और हर कार्यान्वयन थोड़ा अलग है।

— डेटेनवुल्फ

@ v.shashenko: यदि आप अधिक विवरण चाहते हैं, तो आपको किसी विशेष कार्यान्वयन के बारे में पूछना होगा। उदाहरण के लिए, X11 + GLX + DRI → मेसा / AMDGPU → लिनक्स-केएमएस + डीआरएम (डायरेक्ट रेंडरिंग मैनेजर)। और इनमें से प्रत्येक घटक इतने सारे विवरणों के साथ एक जटिल जानवर है, कि आप प्रत्येक घटक कैसे काम करते हैं, इस पर विवरण के साथ किताबें भर सकते हैं। लेकिन यह लिनक्स-एएमडीजीपीयू कार्यान्वयन का वर्णन करेगा। लेकिन लिनक्स + एनवीडिया एक पूरी तरह से अलग जानवर है। और विंडोज पर फिर से अलग।

— डेटेनवॉल्फ

क्या आपको याद है कि हम कुछ दिन पहले तक चैट करते हैं, मैं सिर्फ यह जानना चाहता था कि मैं आपसे कुछ जानना चाहता हूं या नहीं।

— सूरज जैन

आपने उस दिन जो पढ़ाया था, उसने मेरी बहुत सारी शंकाओं को दूर किया, कुछ नया भी किया, लेकिन कुल मिलाकर अब मैं इसे एक जादू नहीं मानता कि हम स्क्रीन पर खिड़कियां और आइकन खींचते हैं।

— सूरज जैन

Answer 2

जब मैं इस कार्यक्रम को संकलित करता हूं, तो क्या इसे ioctl-calls की एक श्रृंखला में बदल दिया जाएगा, और gpu ड्राइवर तब gpu को उपयुक्त कमांड भेजता है, जहां त्रिकोण को घुमाने और उपयुक्त रंग में उपयुक्त पिक्सेल सेट करने के सभी तर्क वायर्ड हैं में? या क्या प्रोग्राम को एक "gpu प्रोग्राम" में संकलित किया जाएगा जो gpu पर लोड किया गया है और रोटेशन आदि की गणना करता है?

तुम दूर नहीं हो। आपका प्रोग्राम इंस्टॉल करने योग्य क्लाइंट ड्राइवर को कॉल करता है (जो वास्तव में ड्राइवर नहीं है, यह एक उपयोगकर्ता साझा लाइब्रेरी है)। कि कर्नेल चालक को डेटा पास करने के लिए ioctl या एक समान तंत्र का उपयोग करेगा।

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

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

Answer 3

आपका प्रोग्राम किसी विशेष GPU के लिए संकलित नहीं है; यह सिर्फ एक पुस्तकालय के खिलाफ गतिशील रूप से जुड़ा हुआ है जो OpenGL को लागू करेगा। वास्तविक कार्यान्वयन में शामिल हो सकते हैं ओपनजीएल कमांड को जीपीयू में भेजना, सॉफ्टवेयर फालबैक चलाना, शेड्स को कंपेयर करना और उन्हें जीपीयू में भेजना या यहां तक ​​कि ओपनर कमांड को शेडर कमबैक का उपयोग करना। ग्राफिक्स परिदृश्य काफी जटिल है। शुक्र है कि लिंकिंग आपको अधिकांश ड्राइवरों की जटिलता से प्रेरित करता है, जो ड्राइवर कार्यान्वयनकर्ताओं को उन तकनीकों का उपयोग करने के लिए स्वतंत्र छोड़ देता है जो वे फिट देखते हैं।

Answer 4

C / C ++ कंपाइलर / लिंकर्स बिल्कुल एक काम करते हैं: वे पाठ फ़ाइलों को सीपीयू पर चलने वाली मशीन-विशिष्ट ऑपकोड की श्रृंखला में परिवर्तित करते हैं। OpenGL और Direct3D सिर्फ C / C ++ API हैं; वे जादुई रूप से आपके C / C ++ कंपाइलर / लिंकर को GPU के लिए कंपाइलर / लिंकर में नहीं बदल सकते।

आपके द्वारा लिखे गए C / C ++ कोड की हर लाइन CPU पर निष्पादित की जाएगी। OpenGL / Direct3D को कॉल C / C ++ लाइब्रेरी में कॉल करेगा, स्टेटिक या डायनामिक जैसा कि मामला हो सकता है।

एक "gpu प्रोग्राम" खेलने पर आने वाला एकमात्र स्थान है यदि आपका कोड स्पष्ट रूप से शेड बनाता है। यही है, अगर आप OpenGL / D3D में एपीआई कॉल करते हैं जो कंपनों के संकलन और लिंकिंग का कारण बनता है। ऐसा करने के लिए, आप (रनटाइम पर, C / C ++ संकलन-समय पर) या तो स्ट्रिंग उत्पन्न करते हैं या लोड करते हैं जो कुछ शेडर भाषा में शेड्स का प्रतिनिधित्व करते हैं। फिर आप उन्हें shader संकलक के माध्यम से हटाते हैं, और उस API में एक ऑब्जेक्ट वापस प्राप्त करते हैं जो उस shader का प्रतिनिधित्व करता है। फिर आप किसी विशेष रेंडरिंग कमांड में एक या एक से अधिक शेड लगाते हैं। इनमें से प्रत्येक चरण आपके C / C ++ कोड की दिशा में स्पष्ट रूप से होता है, जैसा कि पहले सीपीयू में बताया गया है।

कई shader भाषाओं में C / C ++ का उपयोग किया जाता है - जैसे सिंटैक्स। लेकिन यह उन्हें C / C ++ के समकक्ष नहीं बनाता है।

Comments

मैं देर से ओपेंग्ल सीख रहा हूं और आश्चर्यचकित हूं कि मुझे इन सभी "शेडर प्रोग्राम" को कोड में देखा गया है जिन्हें मैं लिबरल स्ट्रिंग्स के रूप में देखता हूं। जैसा आपने कहा, वे रन टाइम पर संकलित हैं। कुछ Android opengl es कोड में मैंने कुछ उदाहरण देखे। फिर मैंने iphone के लिए कुछ कोड भी देखे। जाहिरा तौर पर iPhone में चार वेक्टर प्रोसेसर होते हैं जो iPhone के सीपीयू की तुलना में फ्लोटिंग पॉइंट गणित को बहुत तेजी से करने में सक्षम होते हैं - इसलिए आप मुख्य सीपीयू के बजाय उन प्रोसेसर का उपयोग करने के लिए चलाने के समय पर संकलित करने के लिए एएसएम को शाब्दिक तार के रूप में लिख सकते हैं।

— eggie5

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

— बेन वोइग्ट

@Ben Voigt: सच है, लेकिन अगर किसी ने आपको नहीं बताया, तो आप अंतर बताने में सक्षम नहीं होंगे।

— निकोल बोलस

यदि यह प्रश्न छिपे हुए विवरण के बारे में नहीं था, तो यह एक समझदार रवैया हो सकता है।

— बेन वोइगट