यहाँ बहुत से उत्तर वास्तव में बहुत अच्छे हैं। लेकिन ओपनजीएल और डायरेक्ट 3 डी (डी 3 डी) मुद्दे को संभवतः संबोधित किया जाना चाहिए। और यह आवश्यक है ... एक इतिहास सबक।
और इससे पहले कि हम शुरू करें, मैं OpenGL के बारे में कहीं ज्यादा जानता हूं जितना कि मैं Direct3D के बारे में करता हूं । मैंने अपने जीवन में कभी भी डी 3 डी कोड की एक पंक्ति नहीं लिखी है, और मैंने ओपनजीएल पर ट्यूटोरियल लिखा है। तो मैं जो कहने वाला हूं वह पूर्वाग्रह का सवाल नहीं है। यह केवल इतिहास की बात है।
संघर्ष का जन्म
एक दिन, 90 के दशक की शुरुआत में, Microsoft ने चारों ओर देखा। उन्होंने एसएनईएस और सेगा जेनेसिस को जबरदस्त देखा, बहुत सारे एक्शन गेम और ऐसे चल रहे थे। और उन्होंने डॉस को देखा । डेवलपर्स डीओएस गेम को सांत्वना खेलों की तरह कोडित करते हैं: धातु के लिए प्रत्यक्ष। हालांकि, कंसोल के विपरीत, जहां एक डेवलपर जिसने एसएनईएस गेम बनाया था, वह जानता था कि उपयोगकर्ता के पास क्या हार्डवेयर होगा, डॉस डेवलपर्स को कई संभावित कॉन्फ़िगरेशन के लिए लिखना होगा। और यह बजाय यह लगता है कठिन है।
और माइक्रोसॉफ्ट के पास एक बड़ी समस्या थी: विंडोज। देखें, Windows DOS के विपरीत हार्डवेयर का मालिक होना चाहता था, जो डेवलपर्स को बहुत कुछ करने देता है। अनुप्रयोगों के बीच सहयोग करने के लिए हार्डवेयर का स्वामित्व आवश्यक है। सहयोग वास्तव में क्या खेल डेवलपर्स से नफरत है क्योंकि यह कीमती हार्डवेयर संसाधनों को लेता है जो वे भयानक होने के लिए उपयोग कर सकते हैं।
विंडोज पर गेम के विकास को बढ़ावा देने के लिए, Microsoft को एक समान एपीआई की आवश्यकता थी जो निम्न-स्तर का था, इसे धीमा किए बिना विंडोज पर चला गया, और अधिकांश सभी क्रॉस-हार्डवेयर । सभी ग्राफिक्स, ध्वनि और इनपुट हार्डवेयर के लिए एक एकल एपीआई।
इस प्रकार, DirectX का जन्म हुआ।
3 डी त्वरक कुछ महीनों बाद पैदा हुए थे। और माइक्रोसॉफ्ट मुसीबत के एक स्थान पर भाग गया। देखें, डायरेक्टड्रॉ, डायरेक्टएक्स के ग्राफिक्स घटक, केवल 2 डी ग्राफिक्स से निपटा गया: ग्राफिक्स मेमोरी आवंटित करना और मेमोरी के विभिन्न आवंटित वर्गों के बीच बिट-ब्लिट्स करना।
इसलिए Microsoft ने थोड़ा सा मिडलवेयर खरीदा और इसे Direct3D वर्जन 3 में रखा। इसे सार्वभौमिक रूप से संशोधित किया गया था । और अच्छे कारण के साथ; डी 3 डी वी 3 कोड को देखना वाचा के आर्क में घूरने जैसा है।
आईडी सॉफ्टवेयर में ओल्ड जॉन कार्मैक ने उस कूड़ेदान पर एक नज़र डाली और कहा, "पेंच!" और एक और एपीआई की ओर लिखने का फैसला किया: ओपनजीएल।
देखें, कई प्रमुख-जानवरों का एक और हिस्सा जो माइक्रोसॉफ्ट विंडोज के लिए ओएनजीएल कार्यान्वयन पर एसजीआई के साथ काम करने में व्यस्त था। यहाँ विचार ठेठ जीएल अनुप्रयोगों के डेवलपर्स को अदालत में था: वर्कस्टेशन ऐप। सीएडी उपकरण, मॉडलिंग, उस तरह की चीज। खेल उनके दिमाग की सबसे दूर की चीज थे। यह मुख्य रूप से एक विंडोज़ एनटी चीज़ थी, लेकिन माइक्रोसॉफ्ट ने इसे Win95 में भी जोड़ने का फैसला किया।
विंडोज के लिए वर्कस्टेशन डेवलपर्स को लुभाने के एक तरीके के रूप में, माइक्रोसॉफ्ट ने इन नए 3 डी ग्राफिक्स कार्ड तक पहुंच के साथ उन्हें रिश्वत देने की कोशिश करने का फैसला किया। Microsoft ने इंस्टाल करने योग्य क्लाइंट ड्राइवर प्रोटोकॉल लागू किया: एक ग्राफिक्स कार्ड निर्माता Microsoft के सॉफ़्टवेयर OpenGL कार्यान्वयन को हार्डवेयर-आधारित के साथ ओवरराइड कर सकता है। यदि कोई उपलब्ध था तो कोड स्वचालित रूप से एक हार्डवेयर OpenGL कार्यान्वयन का उपयोग कर सकता है।
शुरुआती दिनों में, उपभोक्ता-स्तरीय वीडियोकॉर्ड के पास OpenGL के लिए समर्थन नहीं था। यह अपने SGI कार्य केंद्र पर खुले (GLQuake) क्वेक को पोर्ट करने से कार्मैक को रोक नहीं पाया। जैसा कि हम GLQuake readme से पढ़ सकते हैं:
सैद्धांतिक रूप से, किसी भी अनुरूप OpenGL पर ग्लोकेक चलेगा जो बनावट ऑब्जेक्ट एक्सटेंशन का समर्थन करता है, लेकिन जब तक कि यह बहुत शक्तिशाली हार्डवेयर नहीं है जो हर चीज की जरूरत को तेज करता है, गेम प्ले स्वीकार्य नहीं होगा। यदि इसे किसी सॉफ्टवेयर इम्यूलेशन रास्तों से गुजरना पड़ता है, तो प्रदर्शन की संभावना एक फ्रेम प्रति सेकंड के तहत होगी।
इस समय (मार्च '97), एकमात्र मानक ओपेंगल हार्डवेयर जो चमक को यथोचित रूप से निभा सकता है, एक इंटरग्राफ रियलिज़्म है, जो एक बहुत महंगा कार्ड है। 3Dlabs अपने प्रदर्शन में काफी सुधार कर रहा है, लेकिन उपलब्ध ड्राइवरों के साथ यह अभी भी खेलने के लिए पर्याप्त नहीं है। ग्लिंट और पेर्मेडिया बोर्ड के कुछ वर्तमान 3 डीलेब ड्राइवर भी पूर्ण स्क्रीन रन से बाहर निकलते समय एनटी को क्रैश कर सकते हैं, इसलिए मैं 3Dlabs हार्डवेयर पर ग्लॉक को चलाने की सलाह नहीं देता।
3dfx ने एक opengl32.dll प्रदान किया है जो हर चीज़ की ज़रूरतों को लागू करता है, लेकिन यह पूर्ण opengl कार्यान्वयन नहीं है। अन्य ओपेंगल एप्लिकेशन इसके साथ काम करने की बहुत संभावना नहीं है, इसलिए इसे मूल रूप से एक "ग्लैक्वे ड्राइवर" मानते हैं।
यह मिनीजीएल ड्राइवरों का जन्म था। ये पूर्ण रूप से OpenGL कार्यान्वयन में विकसित हुए, क्योंकि हार्डवेयर काफी शक्तिशाली हो गया, ताकि हार्डवेयर में अधिकांश OpenGL कार्यक्षमता कार्यान्वित की जा सके। एनवीडिया एक पूर्ण OpenGL कार्यान्वयन की पेशकश करने वाला पहला था। कई अन्य विक्रेताओं ने संघर्ष किया, जो एक कारण है कि डेवलपर्स डायरेक्ट 3 डी को पसंद करते हैं: वे हार्डवेयर की एक विस्तृत श्रृंखला पर संगत थे। आखिरकार केवल एनवीडिया और एटीआई (अब एएमडी) ही रहे, और दोनों में एक अच्छा ओपनजीएल कार्यान्वयन था।
ओपनग्लास आरोही
इस प्रकार चरण निर्धारित होता है: Direct3D बनाम OpenGL। यह वास्तव में एक अद्भुत कहानी है, यह देखते हुए कि डी 3 डी वी 3 कितना बुरा था।
OpenGL आर्किटेक्चरल रिव्यू बोर्ड (ARB) OpenGL को बनाए रखने के लिए जिम्मेदार संगठन है। वे कई एक्सटेंशन जारी करते हैं, एक्सटेंशन रिपॉजिटरी बनाए रखते हैं और एपीआई के नए संस्करण बनाते हैं। एआरबी कई ग्राफिक्स उद्योग के खिलाड़ियों के साथ-साथ कुछ ओएस निर्माताओं से बनी एक समिति है। Apple और Microsoft कई बार ARB के सदस्य रहे हैं।
Voodoo2 के साथ 3Dfx आता है। यह पहला हार्डवेयर है जो मल्टीटेक्स्टिंग कर सकता है, जो कि कुछ ऐसा है जो OpenGL पहले नहीं कर सकता था। जबकि 3Dfx OpenGL, NVIDIA, अगले मल्टीटेक्स्चर ग्राफिक्स चिप (TNT1) के निर्माताओं के खिलाफ था, उसे बहुत पसंद आया। इसलिए ARB ने एक एक्सटेंशन जारी किया: GL_ARB_multitexture, जो मल्टीटेक्स्चर तक पहुंच की अनुमति देगा।
इस बीच, Direct3D v5 बाहर आता है। अब, डी 3 डी एक वास्तविक एपीआई बन गया है , इसके बजाय एक बिल्ली उल्टी कर सकती है। समस्या? कोई बहुरूपिया नहीं।
उफ़।
अब, यह लगभग उतना ही नहीं होगा जितना इसे होना चाहिए, क्योंकि लोग मल्टीटेक्स्टिंग का ज्यादा इस्तेमाल नहीं करते हैं। प्रत्यक्ष नहीं। बहुप्रचारित चोट के प्रदर्शन को काफी कम कर दिया है, और कई मामलों में यह बहु-पासिंग की तुलना में इसके लायक नहीं था। और निश्चित रूप से, गेम डेवलपर्स को यह सुनिश्चित करना पसंद है कि उनके गेम पुराने हार्डवेयर पर काम करते हैं, जिसमें मल्टीटेक्स्चरिंग नहीं था, इसलिए कई गेम इसके बिना भेज दिए गए।
इस प्रकार डी 3 डी को एक प्रतिपूर्ति दी गई।
समय गुजरता है और NVIDIA GeForce 256 (GeForce GT-250; बहुत पहले GeForce नहीं) को चित्रित करता है, अगले दो वर्षों के लिए ग्राफिक्स कार्ड में बहुत अधिक समाप्त होने वाली प्रतियोगिता। मुख्य विक्रय बिंदु हार्डवेयर में वर्टेक्स ट्रांसफॉर्म और लाइटिंग (T & L) करने की क्षमता है। इतना ही नहीं, एनवीआईडीआईएल ओपनगैल को इतना पसंद करता था कि उनका टीएंडएल इंजन प्रभावी रूप से ओपनजीएल था । लगभग शाब्दिक रूप से; जैसा कि मैं समझता हूं, उनके कुछ रजिस्टर वास्तव में ओपनजीएल एन्यूमरेटर्स को सीधे मूल्यों के रूप में लेते हैं।
Direct3D v6 बाहर आता है। Multitexture at last but ... कोई हार्डवेयर T & L नहीं। OpenGL में हमेशा T & L पाइपलाइन थी, जबकि 256 से पहले इसे सॉफ्टवेयर में लागू किया गया था। इसलिए NVIDIA के लिए अपने सॉफ़्टवेयर कार्यान्वयन को केवल हार्डवेयर समाधान में परिवर्तित करना बहुत आसान था। यह D3D v7 तक नहीं होगा जब तक कि D3D के पास आखिरकार हार्डवेयर T & L सपोर्ट न हो।
डॉन ऑफ शेड्स, ट्विलाइट ऑफ ओपनगेल
फिर, GeForce 3 बाहर आया। और एक ही समय में बहुत सारी चीजें हुईं।
Microsoft ने तय किया था कि वे फिर से देर नहीं करेंगे। इसलिए बजाय यह देखने के कि एनवीआईडीआईए क्या कर रहा था और फिर इस तथ्य के बाद इसकी नकल करते हुए, उन्होंने उनके पास जाने और उनसे बात करने की आश्चर्यजनक स्थिति ले ली। और फिर उन्हें प्यार हो गया और साथ में थोड़ा सांत्वना मिली।
बाद में एक गड़बड़ तलाक हुआ। लेकिन वह दूसरी बार है।
पीसी के लिए इसका मतलब यह था कि GeForce 3 D3D v8 के साथ एक साथ निकला था। और यह देखना मुश्किल नहीं है कि GeForce 3 ने D3D 8 के शेड्स को कैसे प्रभावित किया। Shader Model 1.0 के पिक्सेल शेड्स NVIDIA के हार्डवेयर के लिए बेहद विशिष्ट थे । एनवीआईडीआईए के हार्डवेयर को अमूर्त करने का कोई प्रयास नहीं किया गया था; SM 1.0 जो GeForce 3 किया था, वह बस था।
जब ATI ने Radeon 8500 के साथ प्रदर्शन ग्राफिक्स कार्ड की दौड़ में कूदना शुरू किया, तो एक समस्या थी। 8500 की पिक्सेल प्रसंस्करण पाइपलाइन एनवीआईडीआईए के सामान से अधिक शक्तिशाली थी। इसलिए Microsoft ने Shader Model 1.1 जारी किया, जो मूल रूप से "जो भी 8500 करता है।"
यह D3D की ओर से विफलता की तरह लग सकता है। लेकिन विफलता और सफलता डिग्री के मामले हैं। और एपिक -लैंड में महाकाव्य की विफलता हो रही थी।
NVIDIA ने ओपनजीएल को पसंद किया, इसलिए जब GeForce 3 हिट हुआ, तो उन्होंने ओपनजीएल एक्सटेंशन का एक स्लीव जारी किया। मालिकाना OpenGL एक्सटेंशन: केवल NVIDIA। स्वाभाविक रूप से, जब 8500 दिखा, तो यह उनमें से किसी का भी उपयोग नहीं कर सका।
देखें, कम से कम डी 3 डी 8 भूमि में, आप अपने एसएम 1.0 शेड्स को एटीआई हार्डवेयर पर चला सकते हैं। ज़रूर, आपको 8500 की ठंडक का लाभ उठाने के लिए नए शेड्स लिखने थे, लेकिन कम से कम आपके कोड ने काम किया ।
आदेश के shaders रखने के लिए किसी भी ओपन में Radeon 8500 पर तरह, अति ओपन एक्सटेंशन के एक नंबर लिखना पड़ा। मालिकाना OpenGL एक्सटेंशन: ATI- केवल। तो आप एक NVIDIA codepath और एक अति कोडपैथ की जरूरत है, बस सब पर shaders है ।
अब, आप पूछ सकते हैं कि, "OpenGL ARB कहाँ था, जिसका काम OpenGL को चालू रखना था?" जहां कई समितियां अक्सर समाप्त हो जाती हैं: मूर्ख होना।
देखें, मैंने ऊपर ARB_multitexture का उल्लेख किया है क्योंकि यह इस सब में गहराई से कारक है। एआरबी लग रहा था (बाहरी व्यक्ति के दृष्टिकोण से) पूरी तरह से shaders के विचार से बचना चाहते हैं। उन्हें लगा कि अगर वे फिक्स्ड-फंक्शन पाइपलाइन पर पर्याप्त कॉन्फ़िगरेशन को थप्पड़ मारते हैं, तो वे एक shader पाइपलाइन की क्षमता के बराबर हो सकते हैं।
इसलिए ARB ने एक्सटेंशन के बाद एक्सटेंशन जारी किया। शब्द "बुनावट_नव" के साथ हर विस्तार अभी तक इस उम्र बढ़ने के डिजाइन को पैच करने का एक और प्रयास था। रजिस्ट्री की जाँच करें: ARB और EXT एक्सटेंशन के बीच, इनमें से आठ एक्सटेंशन किए गए थे। कई को OpenGL कोर संस्करणों में पदोन्नत किया गया था।
Microsoft इस समय ARB का एक हिस्सा था; वे D3D 9 हिट समय के आसपास छोड़ दिया। इसलिए यह पूरी तरह से संभव है कि वे किसी तरह से ओपनजीएल को तोड़फोड़ करने के लिए काम कर रहे थे। मुझे व्यक्तिगत रूप से इस सिद्धांत पर दो कारणों से संदेह है। एक, उन्हें ऐसा करने के लिए अन्य एआरबी सदस्यों से मदद लेनी होगी, क्योंकि प्रत्येक सदस्य को केवल एक वोट मिलता है। और सबसे महत्वपूर्ण बात, एआरबी को चीजों को पेंच करने के लिए माइक्रोसॉफ्ट की मदद की आवश्यकता नहीं थी। हम इसके और सबूत देखेंगे।
आखिरकार एआरबी और एवीआई (दोनों सक्रिय सदस्यों) से खतरे में पड़ने वाले एआरबी ने आखिरकार वास्तविक विधानसभा-शैली के शेड प्रदान करने के लिए अपने सिर को लंबे समय तक बाहर खींच लिया।
कुछ बेवकूफ भी चाहिए?
हार्डवेयर टी एंड एल। कुछ ओपनगेल पहले था । खैर, यह दिलचस्प है। हार्डवेयर टी एंड एल से अधिकतम संभव प्रदर्शन प्राप्त करने के लिए, आपको GPU पर अपने शीर्ष डेटा को संग्रहीत करने की आवश्यकता है। आखिरकार, यह GPU है जो वास्तव में आपके शीर्ष डेटा का उपयोग करना चाहता है।
डी 3 डी वी 7 में, माइक्रोसॉफ्ट ने वर्टेक्स बफर की अवधारणा पेश की। इन्हें वर्टिकल डेटा स्टोर करने के लिए GPU मेमोरी के स्वैट्स आवंटित किए जाते हैं।
जानना चाहते हैं कि ओपनजीएल को इसके बराबर कब मिला? ओह, NVIDIA, सभी चीजों का प्रेमी होने के नाते OpenGL (इसलिए जब तक वे मालिकाना NVIDIA एक्सटेंशन हैं), GeForce 256 पहली हिट होने पर शीर्ष सरणी रेंज एक्सटेंशन जारी किया। लेकिन एआरबी ने कब समान कार्यक्षमता प्रदान करने का निर्णय लिया?
दो साल बाद । यह वे शीर्ष और टुकड़ा shaders (D3D भाषा में पिक्सेल) को मंजूरी देने के बाद किया गया था । GPU स्मृति में वर्टेक्स डेटा संग्रहीत करने के लिए क्रॉस-प्लेटफ़ॉर्म समाधान विकसित करने में ARB को कितना समय लगा। फिर से, कुछ ऐसा जो हार्डवेयर T & L को अधिकतम प्रदर्शन प्राप्त करने की आवश्यकता है।
एक भाषा सभी को बर्बाद करने के लिए
तो, OpenGL विकास पर्यावरण एक समय के लिए खंडित था। कोई क्रॉस-हार्डवेयर शेड्स नहीं, कोई क्रॉस-हार्डवेयर GPU वर्टेक्स स्टोरेज नहीं है, जबकि डी 3 डी उपयोगकर्ताओं ने दोनों का आनंद लिया। क्या यह खराब हो सकता है?
आप ... आप ऐसा कह सकते हैं। 3 डी लैब्स दर्ज करें ।
वे कौन हैं, आप पूछ सकते हैं? वे एक ख़राब कंपनी हैं, जिन्हें मैं ओपनगेल का सच्चा हत्यारा मानता हूँ। निश्चित रूप से, एआरबी की सामान्य अशुद्धता ने ओपनजीएल को असुरक्षित बना दिया जब उसे डी 3 डी का मालिक होना चाहिए था। लेकिन 3 डी लैब्स शायद ओपनगेल के वर्तमान बाजार राज्य के लिए मेरे दिमाग का एकमात्र सबसे बड़ा कारण है। संभवतः वे ऐसा करने के लिए क्या कर सकते थे?
उन्होंने ओपनजीएल शेडिंग लैंग्वेज डिजाइन की।
देखें, 3D लैब्स एक मरने वाली कंपनी थी। वर्कस्टेशन मार्केट पर एनवीआईडीआईए के बढ़ते दबाव से उनके महंगे जीपीयू हाशिए पर जा रहे थे। और NVIDIA के विपरीत, 3 डी लैब्स की मुख्यधारा के बाजार में कोई उपस्थिति नहीं थी; यदि NVIDIA जीता, तो वे मर गए।
जो उन्होंने किया।
इसलिए, एक ऐसी दुनिया में प्रासंगिक बने रहने के लिए जो अपने उत्पादों को नहीं चाहती थी, 3 डी लैब्स ने गेम डेवलपर कॉन्फ्रेंस में कुछ ऐसी चीजों के लिए प्रस्तुतिकरण दिखाया जो उन्होंने "ओपनजीएल 2.0" कहा था। यह OpenGL API का पूर्ण, स्क्रैच रीराइट से होगा। और यह समझ में आता है; एक था बहुत समय में ओपन के एपीआई में cruft के (ध्यान दें: कि cruft अभी भी मौजूद है)। बस बनावट और लोडिंग के काम को कैसे देखें; यह अर्ध-रहस्यमय है।
उनके प्रस्ताव का एक हिस्सा छायांकन भाषा था। सहज रूप में। हालांकि, वर्तमान क्रॉस-प्लेटफॉर्म एआरबी एक्सटेंशन के विपरीत, उनकी छायांकन भाषा "उच्च-स्तरीय" थी (छायांकन भाषा के लिए सी उच्च स्तर है। हां, वास्तव में)।
अब, Microsoft अपनी उच्च-स्तरीय छायांकन भाषा पर काम कर रहा था। जिसे वे सभी Microsoft की सामूहिक कल्पना में कहते हैं ... उच्च स्तरीय छायांकन भाषा (HLSL)। लेकिन उनका भाषाओं के लिए मौलिक रूप से अलग दृष्टिकोण था।
3D लैब्स की shader भाषा के साथ सबसे बड़ा मुद्दा यह था कि यह बिल्ट-इन थी। देखें, एचएलएसएल माइक्रोसॉफ्ट द्वारा परिभाषित एक भाषा थी। उन्होंने इसके लिए एक कंपाइलर जारी किया, और इसने Shader Model 2.0 (या बाद में shader मॉडल) असेंबली कोड तैयार किया, जिसे आप D3D में फीड करेंगे। डी 3 डी वी 9 दिनों में, एचएलएसएल को सीधे डी 3 डी द्वारा स्पर्श नहीं किया गया था। यह एक अच्छा अमूर्त था, लेकिन यह पूरी तरह से वैकल्पिक था। और एक डेवलपर को हमेशा कंपाइलर के पीछे जाने और अधिकतम प्रदर्शन के लिए आउटपुट को ट्वीक करने का अवसर मिला।
3 डी लैब्स भाषा में कोई भी नहीं था । आपने ड्राइवर को सी-लाइक भाषा दी, और उसने एक शेडर का निर्माण किया। कहानी का अंत। असेम्बली शेडर नहीं, कुछ ऐसा नहीं जिसे आप कुछ और खिलाएं। वास्तविक ओपनग्ल वस्तु एक शेडर का प्रतिनिधित्व करती है।
इसका मतलब यह है कि OpenGL उपयोगकर्ता उन डेवलपर्स की योनि के लिए खुले थे, जो केवल असेंबली जैसी भाषाओं को संकलित करने का काम कर रहे थे। संकलक कीड़े नवगठित OpenGL छायांकन भाषा (GLSL) में बड़े पैमाने पर भाग गए। क्या बुरा है, अगर आप कई प्लेटफार्मों पर सही तरीके से संकलित करने के लिए एक shader प्राप्त करने में कामयाब रहे (कोई मतलब नहीं है), तो आप अभी भी दिन के ऑप्टिमाइज़र के अधीन थे । जो उतने इष्टतम नहीं थे जितना वे हो सकते हैं।
जबकि GLSL में यह सबसे बड़ा दोष था, यह एकमात्र दोष नहीं था। द्वारा अब तक ।
डी 3 डी में, और ओपनजीएल में पुरानी विधानसभा भाषाओं में, आप शीर्ष और टुकड़ा (पिक्सेल) शेड्स को मिला सकते हैं और मैच कर सकते हैं। जब तक वे एक ही इंटरफ़ेस के साथ संचार करते हैं, तब तक आप किसी भी संगत टुकड़ा shader के साथ किसी भी शीर्ष shader का उपयोग कर सकते हैं। और असंगति के स्तर भी थे जिन्हें वे स्वीकार कर सकते थे; एक शीर्ष shader एक उत्पादन लिख सकता है कि टुकड़ा shader पढ़ा नहीं था। इत्यादि।
GLSL में से कोई भी नहीं था। 3 डी लैब्स को एक "प्रोग्राम ऑब्जेक्ट" कहा जाता है, जिसमें वर्टेक्स और टुकड़ा शेड्स एक साथ जुड़े हुए थे। इसलिए यदि आप वर्टेक्स और टुकड़ा कार्यक्रम साझा करना चाहते हैं, तो आपको कई प्रोग्राम ऑब्जेक्ट बनाने होंगे। और इससे दूसरी सबसे बड़ी समस्या खड़ी हो गई।
देखें, 3 डी लैब्स ने सोचा कि वे चतुर थे। वे CSL / C ++ पर GLSL के संकलन मॉडल पर आधारित हैं। आप एक .c या .cpp लेते हैं और उसे एक ऑब्जेक्ट फ़ाइल में संकलित करते हैं। फिर आप एक या एक से अधिक ऑब्जेक्ट फ़ाइलें लेते हैं और उन्हें एक प्रोग्राम में लिंक करते हैं। तो यह है कि GLSL कैसे संकलित करता है: आप अपने shader (वर्टेक्स या टुकड़ा) को shader ऑब्जेक्ट में संकलित करते हैं। फिर आप उन शेडर ऑब्जेक्ट्स को एक प्रोग्राम ऑब्जेक्ट में डालते हैं, और उन्हें एक साथ जोड़कर अपना वास्तविक प्रोग्राम बनाते हैं।
हालांकि इसने "लाइब्रेरी" शेड्स जैसे संभावित शांत विचारों की अनुमति दी, जिसमें अतिरिक्त कोड थे जो मुख्य शेड्स कह सकते थे, व्यवहार में इसका मतलब यह था कि शेड्स दो बार संकलित किए गए थे । एक बार संकलन चरण में और एक बार लिंकिंग चरण में। विशेष रूप से NVIDIA के संकलक को मूल रूप से दो बार संकलन चलाने के लिए जाना जाता था। इसने किसी प्रकार का ऑब्जेक्ट कोड मध्यस्थ नहीं बनाया; यह सिर्फ एक बार संकलित किया और उत्तर को फेंक दिया, फिर लिंक समय पर फिर से संकलित किया।
तो भले ही आप अपने वर्टेक्स शैडर को दो अलग-अलग टुकड़े शेड से जोड़ना चाहते हैं, आपको डी 3 डी की तुलना में बहुत अधिक संकलन करना होगा। विशेष रूप से चूंकि सी-जैसी भाषा का संकलन सभी ऑफ़लाइन किया गया था , न कि कार्यक्रम के निष्पादन की शुरुआत में।
GLSL के साथ अन्य मुद्दे थे। शायद 3 डी लैब्स पर दोष लगाना गलत लगता है, क्योंकि एआरबी ने आखिरकार भाषा को मंजूरी दी और शामिल किया (लेकिन उनकी "ओपनजीएल 2.0" पहल का और कुछ नहीं)। लेकिन यह उनका विचार था।
और यहाँ वास्तव में दुखद हिस्सा है: 3 डी लैब्स सही था (ज्यादातर)। GLSL एक वेक्टर-आधारित छायांकन भाषा नहीं है जिस तरह HLSL उस समय थी। ऐसा इसलिए था क्योंकि 3 डी लैब्स का हार्डवेयर अदिश हार्डवेयर (आधुनिक एनवीआईडीआईए हार्डवेयर के समान) था, लेकिन वे अंततः उसी दिशा में सही थे, जब कई हार्डवेयर निर्माता अपने हार्डवेयर के साथ गए थे।
वे "उच्च-स्तरीय" भाषा के लिए एक संकलन-ऑनलाइन मॉडल के साथ जाने के लिए सही थे। डी 3 डी ने भी अंततः उस पर स्विच किया।
समस्या यह थी कि 3 डी लैब्स गलत समय पर सही थे । और भविष्य को बहुत जल्दी बुलाने की कोशिश में, भविष्य के प्रमाण होने की कोशिश में, उन्होंने वर्तमान को एक तरफ कर दिया । यह लगता है कि कैसे OpenGL हमेशा टी एंड एल कार्यक्षमता के लिए संभावना थी। सिवाय इसके कि OpenGL की T & L पाइपलाइन अभी भी हार्डवेयर T & L से पहले उपयोगी थी , जबकि GLSL एक दायित्व था, इससे पहले कि दुनिया इसे पकड़ लेती।
जीएलएसएल अब एक अच्छी भाषा है । लेकिन समय के लिए? यह बहुत घटिया था। और ओपनजीएल को इसके लिए नुकसान उठाना पड़ा।
पतन की ओर इशारा एपोथोसिस
जबकि मैं यह कहता हूं कि 3 डी लैब्स ने घातक प्रहार किया, यह एआरबी ही था जो ताबूत में आखिरी कील चलाएगा।
यह एक ऐसी कहानी है जिसके बारे में आपने सुना होगा। OpenGL 2.1 के समय तक, OpenGL एक समस्या में चल रहा था। इसमें बहुत सारी विरासत cruft थी। API अब उपयोग करना आसान नहीं था। चीजों को करने के 5 तरीके थे, और कोई भी विचार जो सबसे तेज था। आप सरल ट्यूटोरियल के साथ ओपनजीएल "सीख" सकते हैं, लेकिन आपने वास्तव में ओपनजीएल एपीआई नहीं सीखा है जो आपको वास्तविक प्रदर्शन और चित्रमय शक्ति प्रदान करता है।
इसलिए एआरबी ने ओपनजीएल के एक और पुन: आविष्कार का प्रयास करने का फैसला किया। यह 3 डी लैब्स के "ओपनजीएल 2.0" के समान था, लेकिन बेहतर था क्योंकि एआरबी इसके पीछे था। उन्होंने इसे "लोंग्स पीक" कहा।
एपीआई को बेहतर बनाने के लिए कुछ समय लेने के बारे में क्या बुरा है? यह बुरा था क्योंकि Microsoft ने खुद को असुरक्षित छोड़ दिया था। देखें, यह विस्टा स्विचओवर के समय था।
विस्टा के साथ, माइक्रोसॉफ्ट ने डिस्प्ले ड्राइवरों में कुछ बहुत जरूरी बदलाव लाने का फैसला किया। उन्होंने ग्राफिक्स मेमोरी वर्चुअलाइजेशन और कई अन्य चीजों के लिए ड्राइवरों को ओएस के लिए प्रस्तुत करने के लिए मजबूर किया।
जबकि कोई इस के गुणों पर बहस कर सकता है या क्या यह वास्तव में संभव था, तथ्य यह है: माइक्रोसॉफ्ट ने डी 3 डी 10 को केवल विस्टा (और ऊपर) माना। यहां तक कि अगर आपके पास हार्डवेयर था जो डी 3 डी 10 में सक्षम था , तो आप विस्टा को चलाने के बिना डी 3 डी 10 एप्लिकेशन भी नहीं चला सकते थे।
आपको यह भी याद होगा कि विस्टा ... उम, चलो बस यह कहना है कि यह अच्छी तरह से काम नहीं किया। तो तुम एक घटिया प्रदर्शन ओएस, एक नए API कि केवल कि ओएस पर चलता था, और हार्डवेयर के एक ताजा पीढ़ी था कि जरूरत है कि एपीआई और ओएस से अधिक पिछली पीढ़ी की तुलना में तेजी हो कुछ भी करने को।
हालांकि, डेवलपर्स OpenGL के माध्यम से डी 3 डी 10-क्लास सुविधाओं का उपयोग कर सकते हैं। ठीक है, अगर ARB Longs पीक पर काम करने में व्यस्त नहीं थे।
मूल रूप से, एआरबी ने एपीआई को बेहतर बनाने के लिए एक अच्छा साल और डेढ़ से दो साल के काम का खर्च किया। जब तक ओपनजीएल 3.0 वास्तव में बाहर आया था, तब तक विस्टा को गोद लिया गया था, Win7 उनके पीछे विस्टा लगाने के लिए कोने के आसपास था, और ज्यादातर गेम डेवलपर्स ने वैसे भी डी 3 डी -10 वर्ग सुविधाओं के बारे में परवाह नहीं की। सब के बाद, डी 3 डी 10 हार्डवेयर ने डी 3 डी 9 अनुप्रयोगों को ठीक से चलाया। और पीसी-टू-कंसोल पोर्ट्स (या पीसी डेवलपर्स जंपिंग शिप टू जंपिंग कन्सोल डेवलेपमेंट। अपनी पिक लें) के उदय के साथ, डेवलपर्स को डी 3 डी 10 क्लास फीचर्स की आवश्यकता नहीं थी।
अब, अगर डेवलपर्स ने WinGLP मशीनों पर OpenGL के माध्यम से उन सुविधाओं तक पहुंच प्राप्त की थी, तो OpenGL विकास को हाथ में एक बहुत जरूरी शॉट मिल सकता है। लेकिन एआरबी ने अपना मौका गंवा दिया। और क्या आप सबसे खराब हिस्सा जानना चाहते हैं?
दो कीमती साल बिताने के बावजूद एपीआई को खरोंच से पुनर्निर्माण करने का प्रयास ... वे अभी भी विफल रहे और बस यथास्थिति में वापस आ गए (एक पदावनत तंत्र को छोड़कर)।
इसलिए न केवल एआरबी ने अवसर की एक महत्वपूर्ण खिड़की को याद किया, उन्होंने उस कार्य को भी पूरा नहीं किया जिसने उन्हें उस अवसर को याद किया। चारों ओर बहुत ज्यादा महाकाव्य असफल।
और यह OpenGL बनाम Direct3D की कहानी है। छूटे हुए अवसरों, घोर मूर्खता, दृढ़ इच्छाशक्ति और सरल मूर्खता की एक कहानी।