शीर्षक में प्रश्न का पूरा रूप इस पर विचार करें: चूंकि OpenCL भविष्य में गंभीर GPU प्रोग्रामिंग (अन्य डिवाइस प्रोग्रामिंग के बीच) के लिए सामान्य मानक हो सकता है, क्यों नहीं जब ओपनजीएल के लिए प्रोग्रामिंग - भविष्य के सबूत तरीके से - उपयोग करें ओपनसीएल पर सभी जीपीयू संचालन? इस तरह आप अपनी प्रोग्रामेटिक सीमाओं के बिना जीएलएसएल के फायदे प्राप्त करते हैं।ओपनसीएल होने पर जीएलएसएल का क्या मतलब है?
जीएलएसएल OpenGL Shading Language है। यह मूल रूप से ग्राफिक्स पाइपलाइन को नियंत्रित करने के लिए है।
दूसरी तरफ ओपनसीएल Open Computing Language है। यह ग्राफिक्स को नियंत्रित नहीं करता है, बल्कि गणना करता है।
दो तकनीकें विभिन्न क्षमताओं और कार्यक्षमता को लक्षित कर रही हैं।
कहा जा रहा है कि, आगे बढ़ते हुए, वे गणना के उद्देश्यों के लिए जीएलएसएल का उपयोग करने के बहुत कम कारण हो सकते हैं। हालांकि, आज के रूप में, अधिक विक्रेता पूरी तरह से ओपनसीएल की तुलना में जीएलएसएल का समर्थन करते हैं, इसलिए यह अभी भी गणना के उद्देश्यों के लिए उपयोगी है, भले ही यह सीमित है क्योंकि यह कम से कम अभी इसका मुख्य उद्देश्य नहीं है।
हां, मेरा मतलब है जीएलएसएल और ओपनसीएल लक्ष्य के उद्देश्यों के बिना, ओपनसीएल एक अधिक शक्तिशाली इंटरफ़ेस में जीएलएसएल के फायदे दे रहा है। क्या ऐसा कुछ है जो ओपनसीएल ऐसा नहीं कर सकता है कि जीएलएसएल करता है और क्या कुछ ओपनसीएल खराब तरीके से करेगा? –
@ लीला: शुद्ध कम्प्यूटेशनल उद्देश्यों के लिए, अभी, केवल वास्तविक लाभ (मेरे ज्ञान के लिए) तैनाती और विक्रेता समर्थन में से एक है - जीएलएसएल जंगली (इसलिए मेरा अंतिम अनुच्छेद) में बेहतर समर्थित है। अन्यथा, शुद्ध गणना के लिए, ओपनसीएल जीएलएसएल आईएमओ की तुलना में वास्तव में अच्छा है। –
ठीक है हाँ। मुझे उल्लेख किया गया था कि मैंने भविष्य में 'भविष्य-सबूत' पर जोर दिया होगा। इस प्रश्न का मुख्य विचार भविष्य के लिए प्रोग्रामिंग के आसपास केंद्रित है, जबकि अधिकांश संकेतों से पता चलता है कि ओपनसीएल मानक रूप से समर्थित मानक बन जाएगा। –
भविष्य में ओपनसीएल जीएलएसएल को प्रतिस्थापित करने में सक्षम हो सकता है। इस बीच ओपनजीएल इंटरऑप के साथ कम से कम कुछ महत्वपूर्ण मुद्दे हैं, कम से कम सबसे महत्वपूर्ण (एनवीडिया/एटीआई) कार्यान्वयन के साथ।
ओपनसीएल पूरी तरह से OpenGL को प्रतिस्थापित नहीं करेगा, हालांकि। जब रास्टर ग्राफिक्स की बात आती है तो ओपनजीएल एक बहुत कुछ करता है। ओपनसीएल में एकमात्र रास्टर ग्राफिक्स प्राइमेटिव बनावट/छवियां हैं और यह ग्राफिक्स को बिल्कुल प्रस्तुत नहीं कर सकता है।
"रेंडर नहीं कर सकता" से आपका क्या मतलब है? जहां तक मुझे पता है, आप फ्रेमबफर (स्क्रीन पर सामान प्रदर्शित करने) को छोड़कर ओपनसीएल के साथ सभी ओपनजीएल पाइपलाइन को कार्यान्वित कर सकते हैं। इसका मतलब यह नहीं है कि आप अभी भी एक बनावट में प्रस्तुत नहीं कर सकते हैं या शायद एक फ्रेमबफर आवंटित करने के लिए ओपनजीएल * केवल * का उपयोग कर सकते हैं जिसे ओपनसीएल में उपयोग किया जा सकता है। – Tronic
हां, आप ऐसा कर सकते हैं, लेकिन यह बहुत धीमी होगी। जीपीयू ने ब्लिटिंग, रास्टरराइजेशन, ब्लेंडिंग, टेस्सेलेशन और कई अन्य विशिष्ट ग्राफिक्स ऑपरेशंस के लिए हार्डवेयर को समर्पित और अत्यधिक अनुकूलित किया है। ओपनसीएल इस हार्डवेयर के लिए कोई समर्थन प्रदान नहीं करता है। वही तो मेरा मतलब था। – dietr
@dietr: मुझे यहाँ इको दें! सीएल/जीएल इंटरऑपरेबिलिटी समग्र प्रदर्शन को काफी नुकसान पहुंचा सकती है, खासकर जब ऑब्जेक्ट बफर की एक बड़ी संख्या (उदाहरण के लिए 100) को संभालने में। संदर्भ ओवरहेड बदल रहा है और बफर या पॉइंटर्स को बफर के ढांचे के लिए समर्थन की कमी सिर्फ मेरे ऐप्स को मार डालेगी, इस तरह से कि मैं अपने ओपनक्ल कोड को प्रतिस्थापित करने के लिए ज्यामिति शेडर के उपयोग पर गंभीरता से विचार कर रहा हूं। और खुद को मूर्ख मत बनाओ, ओपनक्ल द्वारा पूरे ओपनजीएल का एक पूर्ण प्रतिस्थापन एक संपूर्ण रिकोडिंग प्रक्रिया की आवश्यकता होगी जो न केवल वास्तविक होगा बल्कि लाभकारी भी होगा। इसके अलावा, यहां तक कि लोगों द्वारा भी कहा गया है, ओपनग्लू सिर्फ पाइपलाइन गणना से कहीं अधिक है। मैं कहूंगा कि यदि आप सीएल/जीएल इयरोपॉप का उपयोग करना चाहते हैं, तो यदि आप कर सकते हैं तो वर्टेक्स/ज्यामिति शेडर पर अपना कोड फिर से लिखने का प्रयास करें।
मुझे लगता है कि प्रदर्शन आपके द्वारा किए गए कार्यों पर निर्भर करता है, और कैसे। आम तौर पर आप सैकड़ों बफर साझा नहीं करेंगे, लेकिन अधिकतम पर केवल एक मुट्ठी भर। – dietr
जीएलएसएल एक "छायांकन भाषा" है। इसका उपयोग 3 डी प्रतिपादन के लिए किया जाता है और इसमें विशेष डेटाटाइप विशेष रूप से उस उद्देश्य के लिए उपयोगी होते हैं (उदाहरण के लिए लंबाई -4 वैक्टर और रैंक -4x4 मैट्रिस)। कशेरुक और टुकड़े के टुकड़े प्रतिपादन पाइपलाइन के अंदर एक अच्छी तरह से परिभाषित स्थान पर बैठते हैं, और वे स्वचालित रूप से इस पाइपलाइन के माध्यम से बहने वाले डेटा पर ट्रिगर होते हैं। शेडर्स को 3 डी पाइपलाइन के ट्रांज़ॉर्मेशन और प्रोजेक्शन मैट्रिस तक सीधे पहुंच है।
ओपनसीएल एक "गणना भाषा" है। यह विशेष रूप से 3 डी प्रतिपादन में देखे गए गणना कार्यों के लिए डिज़ाइन नहीं किया गया है, बल्कि सी ओपनसीएल का सबसेट है, जीएलएसएल (फ्लोट 4, फ्लोट 16) में वेक्टर और मैट्रिस के समान डेटा प्रकार हैं, लेकिन वे उपयोग करने के लिए कम विश्वसनीय हैं। इसके अलावा आपके पास ग्राफिक्स संदर्भ नहीं है (जो एक लाभ या हानि हो सकता है), और ओपनसीएल कर्नेल 3 डी प्रतिपादन पाइपलाइन के अंदर नहीं रहता है।
यदि आप 3 डी प्रतिपादन पाइपलाइन में प्लग किए गए गणना मॉड्यूल चाहते हैं और प्रतिपादन पाइपलाइन द्वारा ट्रिगर किए गए हैं, तो जीएलएसएल का उपयोग करें। यदि आप 3 डी प्रतिपादन पाइपलाइन के बाहर GPU पर सामान्य गणना चाहते हैं तो OpenCL का उपयोग करें।
इसका मतलब यह नहीं है कि ओपनसीएल का उपयोग 3 डी ग्राफिक्स को प्रस्तुत करने के लिए नहीं किया जा सकता है। यह।वास्तव में, आप ओपनसीएल में पूरी तरह से अपनी पाइपलाइन को कार्यान्वित कर सकते हैं, और फिर अपने ड्राइंग को फ्रेमबफर पर कॉपी कर सकते हैं। लेकिन अगर आप कुछ 3 डी ग्राफिक्स खींचना चाहते हैं, तो एसजीआई, एनवीडिया, इंटेल और एएमडी इंजीनियरों द्वारा किए गए सभी कामों को डुप्लिकेट करना शायद परेशानी के लायक नहीं है। फिर जीएलएसएल का उपयोग करना और शेडर को एक उपयोग में आसान और पूरी तरह से प्रदर्शनकारी ओपनजीएल पाइपलाइन में प्लग करना आसान है। बस विचार करें कि ओसा-स्रोत ओपनजीएल कार्यान्वयन मेसा लिखने के लिए यह एक प्रमुख उपक्रम था।
यह पूछने की तरह है कि "क्रोम होने पर सफारी का बिंदु क्या है?" : पी –
मुख्य बिंदु यह है कि ओपनसीएल जीएलएसएल का एक रूप नहीं है; यह प्रबंधन में समृद्ध और अधिक शक्तिशाली है। –
एक उचित सवाल है। +1 – LarsH