Direct3D बनाम ओपनजीएल: टकराव का इतिहास

आज तक, इंटरनेट पर इस बारे में बहस चल रही है कि कौन सा ग्राफिक्स एपीआई बेहतर है: डायरेक्ट 3 डी या ओपनजीएल? अपनी धार्मिक प्रकृति के बावजूद, इस तरह की मौखिक लड़ाई हार्डवेयर-त्वरित ग्राफिक्स के विकास की अच्छी ऐतिहासिक समीक्षाओं के रूप में उपयोगी परिणाम लाती है।



इस पोस्ट का उद्देश्य इतिहास में इनमें से किसी एक का अनुवाद करना है।सवाल के जवाब में जेसन एल। मैककसन ने लिखा "गेम डेवलपर्स विंडोज को क्यों पसंद करते हैं।" इस पाठ में प्रश्न का उत्तर देने की संभावना नहीं है, लेकिन वह विकास के इतिहास और दो सबसे लोकप्रिय ग्राफिकल एपीआई के टकराव को बहुत रंगीन और काफी विस्तृत तरीके से बताता है, इसलिए मैंने अनुवाद में लेखक के मार्कअप को बरकरार रखा। पाठ 2011 के मध्य में लिखा गया था और डायरेक्ट 3 डी के आगमन से कुछ समय पहले और लेखन के समय तक शुरू हुआ। मूल पाठ के लेखक एक अनुभवी गेम डेवलपर, स्टैकऑवरफ्लो में एक सक्रिय भागीदार और आधुनिक 3 डी ग्राफिक्स प्रोग्रामिंग पर एक व्यापक पाठ्यपुस्तक के निर्माता हैं । तो चलिए मंजिल जेसन को देते हैं।

प्रस्तावना

शुरू करने से पहले, मैं कहना चाहूंगा कि मैं Open3 के बारे में Direct3D के बारे में अधिक जानता हूं। अपने जीवन में मैंने डी 3 डी में कोड की एक भी पंक्ति नहीं लिखी है, लेकिन मैंने ओपनजीएल मैनुअल लिखा है। लेकिन मैं जिस बारे में बात करना चाहता हूं वह पूर्वाग्रह की बात नहीं है, बल्कि इतिहास की है।

संघर्ष का जन्म

एक बार, 90 के दशक की शुरुआत में, Microsoft ने चारों ओर देखा। उन्होंने देखा कि एसएनईएस और सेगा जेनेसिस बहुत शांत हैं, आप बहुत सारे एक्शन गेम और यह सब खेल सकते हैं। और उन्होंने डॉस को देखा। डेवलपर्स ने डॉसोवस्की गेम्स को कंसोल के रूप में लिखा: लोहे के करीब। हालांकि, कंसोल के विपरीत, जहां डेवलपर जानता था कि उपयोगकर्ता किस तरह का हार्डवेयर होगा, डॉस डेवलपर्स को कई कॉन्फ़िगरेशन के तहत लिखने के लिए मजबूर किया गया था। और यह जितना लगता है उससे कहीं अधिक जटिल है।

लेकिन Microsoft को एक बड़ी समस्या थी: विंडोज। आप देखते हैं, विंडोज डॉस के विपरीत पूरी तरह से हार्डवेयर का मालिक बनना चाहता था, जो डेवलपर्स को कुछ भी करने की अनुमति देता था। अनुप्रयोगों के बीच बातचीत के लिए लोहे का कब्ज़ा आवश्यक है। लेकिन इस तरह की बातचीत बिल्कुल वैसी ही है जैसी वे नफरत करते हैं।खेल डेवलपर्स क्योंकि यह कीमती संसाधनों की खपत करता है जो वे सभी प्रकार की ठंडी चीजों के लिए उपयोग कर सकते हैं।

विंडोज पर गेम के विकास को बढ़ावा देने के लिए, Microsoft को एक समान एपीआई की आवश्यकता थी जो निम्न-स्तर का हो, प्रदर्शन की हानि के बिना विंडोज पर काम करेगा, और विभिन्न हार्डवेयर के साथ संगत होगा । ग्राफिक्स, ध्वनि और इनपुट उपकरणों के लिए एक एकल एपीआई।

तो DirectX का जन्म हुआ।

3 डी त्वरक कुछ महीनों बाद दिखाई दिए। और Microsoft मुश्किल में पड़ गया। तथ्य यह है कि डायरेक्टएक्स का एक ग्राफिक घटक डायरेक्टड्रॉव केवल 2 डी ग्राफिक्स के साथ काम करता है: इसने ग्राफिक्स मेमोरी आवंटित की और मेमोरी के विभिन्न क्षेत्रों के बीच तेजी से बिट संचालन किया।

इसलिए, Microsoft ने कुछ तृतीय-पक्ष सॉफ़्टवेयर खरीदा और इसे Direct3D संस्करण 3 में बदल दिया। उन्हें डांटा गयाबिल्कुल सब कुछ। और एक कारण था: डी 3 डी 3 पर कोड पढ़ना एक विलुप्त प्राचीन सभ्यता की लिखित भाषा के डिकोडिंग की तरह लग रहा था।

आईडी सॉफ्टवेयर में बूढ़े आदमी जॉन कार्मैक ने इस अपमान को देखा, कहा "हाँ यह गया ...", और एक और एपीआई का उपयोग करके लिखने का फैसला किया: ओपनजीएल।

हालाँकि, इस भ्रामक कहानी का दूसरा पक्ष यह था कि माइक्रोसॉफ्ट ने विंडोज के लिए ओएनजीसी को लागू करने के लिए एसजीआई के साथ काम किया। कार्यस्थानों के लिए विशिष्ट जीएल-अनुप्रयोगों के डेवलपर्स को आकर्षित करने के लिए यह विचार था: सीएडी, मॉडलिंग सिस्टम और पसंद। खेल आखिरी चीज थे जो उन्होंने सोचा था। यह मुख्य रूप से विंडोज़ एनटी से संबंधित है, लेकिन माइक्रोसॉफ्ट ने ओपन 95 को विंडोज 95 के साथ भी जोड़ने का फैसला किया।

विंडोज पर वर्कस्टेशन के लिए सॉफ्टवेयर के डेवलपर्स को लुभाने के लिए, माइक्रोसॉफ्ट ने उन्हें नए 3 डी त्वरक के उपयोग के साथ रिश्वत देने का फैसला किया। उन्होंने स्थापित क्लाइंट ड्राइवरों के लिए एक प्रोटोकॉल लागू किया: एक ग्राफिक्स कार्ड Microsoft के OpenGL सॉफ़्टवेयर को उनके हार्डवेयर कार्यान्वयन के साथ बदल सकता है। यदि कोड उपलब्ध था तो कोड स्वचालित रूप से हार्डवेयर OpenGL का उपयोग करता था।

हालांकि, उन दिनों में उपभोक्ता ग्राफिक्स कार्ड में ओपनजीएल समर्थन नहीं था। इसने कार्मैक को एक एसजीआई वर्कस्टेशन पर क्वेक को ओपनजीएल में पोर्ट करने से नहीं रोका। GLQuake की रीडमी फ़ाइल में, आप निम्नलिखित पढ़ सकते हैं:

, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

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

ओपन के डॉन

इसलिए, प्रतिभागियों को परिभाषित किया गया है: ओपन 3 के खिलाफ डायरेक्ट 3 डी। यह वास्तव में एक अद्भुत कहानी है, यह देखते हुए कि डी 3 डी वी 3 कितना बुरा था।

OpenGL आर्किटेक्चरल रिव्यू बोर्ड (ARB) OpenGL को बनाए रखने और विकसित करने के लिए जिम्मेदार संगठन है। वे कई एक्सटेंशन जारी करते हैं, जिनमें एक्सटेंशन के साथ एक रिपॉजिटरी होती है, और एपीआई के नए संस्करण बनाते हैं। एआरबी कंप्यूटर ग्राफिक्स उद्योग और कुछ ओएस निर्माताओं में बड़ी संख्या में खिलाड़ियों से बनी एक समिति है। Apple और Microsoft भी अलग-अलग समय में ARB के सदस्य थे।

3DFx अपने Voodoo2 के साथ दृश्य में प्रवेश करता है। यह पहला वीडियो कार्ड है जो आपको मल्टीटेक्स्टिंग करने की अनुमति देता है, जो पहले ओपनजीएल में प्रदान नहीं किया गया था। जबकि 3Dfx को OpenGL का कड़ा विरोध किया गया था, मल्टीविटरिंग चिप (TNT1) के अगले निर्माता, NVidia, OpenGL के बारे में पागल था। तब ARB ने GL_ARB_multitexture एक्सटेंशन जारी किया, जिसने कई बनावटों तक पहुंच प्रदान की।

इस बीच, Direct3D v5 प्रकट होता है। अब डी 3 डी वास्तव में एक एपीआई बन गया है , न कि किसी प्रकार का बकवास। क्या समस्या है? मल्टीटेक्स्चर के अभाव में।

उफ़।

लेकिन इससे ऐसी असुविधा नहीं हुई क्योंकि यह वितरित कर सकता था, क्योंकि लगभग कोई भी कई बनावट का उपयोग नहीं करता था। मल्टीटेक्स्टुरिंग लगभग प्रदर्शन को नुकसान नहीं पहुंचाता है, और कई मामलों में अंतर मल्टी-पास की पृष्ठभूमि के खिलाफ अदृश्य है। और निश्चित रूप से, गेम डेवलपर्स अपने गेम के बहुत शौकीन हैं जो पुराने हार्डवेयर पर आत्मविश्वास से काम कर रहे हैं, जिसमें कई बनावट के लिए समर्थन नहीं था, इसलिए कई गेम इसके बिना जारी किए गए थे।

डी 3 डी ने राहत की सांस ली।

समय बीत गया, और एनवीडिया ने GeForce 256 (बहुत पहले GeForce GT-250 के साथ भ्रमित नहीं होना) को रोल आउट किया, अगले दो वर्षों के लिए ग्राफिक्स कार्ड बाजार में संघर्ष को रोक दिया। इस बोर्ड का मुख्य प्रतिस्पर्धी लाभ हार्डवेयर में वर्टिकल और लाइटिंग (ट्रांसफॉर्मेशन एंड लाइटिंग, टीएंडएल) का रूपांतरण करने की क्षमता थी। लेकिन यही सब कुछ नहीं है: NVIDIA ओपन इतना प्यार करता था कि उनके टी एंड एल इंजन वास्तव में किया गया ओपन। लगभग सचमुच! जैसा कि मैं इसे समझता हूं, उनके कुछ रजिस्टरों ने जीलेनम प्रकार के चर के सीधे संख्यात्मक मान प्राप्त किए ।

Direct3D v6 बाहर आता है। अंत में, कई टेक्सचरिंग समय पर पहुंचे ... लेकिन हार्डवेयर टीएंडएल के बिना। OpenGL हमेशाटी एंड एल पाइपलाइन थी, हालांकि GeForce 256 से पहले इसे सॉफ्टवेयर में लागू किया गया था। इसलिए, एनवीडिया के लिए, यह एक हार्डवेयर समाधान में सॉफ़्टवेयर कार्यान्वयन को रीमेक करने के लिए काफी सरल निकला। डी 3 डी में, हार्डवेयर टी एंड एल केवल सातवें संस्करण में दिखाई दिया।

द शेड ऑफ द शेडर एज, ओपनजीएल इन द डार्क

फिर आया GeForce 3. उसी समय, कई दिलचस्प चीजें हुईं।

Microsoft ने फैसला किया कि उन्हें अब देर नहीं होगी। इसलिए, यह देखने के बजाय कि एनवीडिया क्या करेगी और पहले से ही पोस्ट-फैक्टम के विकास को कॉपी करके, Microsoft ने एक अद्भुत निर्णय लिया: जाओ और बात करो। और वे प्यार में पड़ गए, और उन्हें एक संयुक्त थोड़ा सांत्वना मिली।

शोरगुल तलाक बाद में हुआ, लेकिन यह एक पूरी तरह से अलग कहानी है।

पीसी मार्केट के लिए, इसका मतलब यह था कि GeForce 3 एक साथ D3D v8 के साथ निकला था, और यह देखना आसान है कि GeForce 3 ने D3D v8 शेड्स को कैसे प्रभावित किया। Shader Model 1.0 का पिक्सेल शेड बहुत थाएनवीडिया उपकरण के लिए बहुत तेज। लोहे से अमूर्त एनवीडिया के लिए कुछ भी करने का एक भी प्रयास नहीं किया गया है। Shader Model 1.0 क्या GeForce 3 के लिए डिज़ाइन किया गया था।

जब ATI ने अपने Radeon 8500 के साथ ग्राफिक्स के प्रदर्शन की दौड़ में प्रवेश किया, तो एक समस्या थी। राडॉन 8500 पिक्सेल पाइपलाइन एनवीडिया की तुलना में अधिक शक्तिशाली निकला। इसलिए, माइक्रोसॉफ्ट ने शेडर मॉडल 1.1 जारी किया, जो मूल रूप से 8500

के लिए था। यह एक डी 3 डी हार की तरह लगता है, लेकिन सफलता और विफलता सापेक्ष शब्द हैं। वास्तव में, एक महाकाव्य विफलता OpenGL का इंतजार कर रही थी।

एनवीडिया को ओपनजीएल का बहुत शौक था, इसलिए GeForce 3 की रिहाई के बाद उन्होंने ओपनजीएल के लिए एक्सटेंशन का एक पूरा गुच्छा जारी किया। मालिकानाएक्सटेंशन जो केवल एनवीडिया पर काम करते थे। स्वाभाविक रूप से, जब 8500 बोर्ड दिखाई दिया, तो यह उनमें से किसी का भी उपयोग नहीं कर सका।

तो, डी 3 डी 8 पर, आप कम से कम एसएम 1.0 शेड्स चला सकते हैं। बेशक, 8500 की सभी शीतलता का उपयोग करने के लिए, मुझे नए शेड्स लिखने थे, लेकिन कोड ने कम से कम काम किया । OpenGL में Radeon 8500 पर कोई भी शेड

प्राप्त करने के लिए , ATI को OpenGL के लिए कई एक्सटेंशन विकसित करने थे। मालिकाना एक्सटेंशन जो केवल एटीआई पर काम करते थे। परिणामस्वरूप, ताकि डेवलपर्स यह घोषणा कर सकें कि उन्होंने अपने इंजन के लिए शेड को खराब कर दिया है, उन्हें एनवीडिया के लिए अलग कोड और एटीआई के लिए अलग कोड लिखना होगा।

आप पूछ सकते हैं: "और एआरबी कमेटी कहाँ थी जो ओपेनग्ल एफ़्लोत का समर्थन करे?" और वे थे जहां कई समितियां समाप्त हुईं: वे बैठ गए और बेवकूफ थे।

कृपया ध्यान दें, मैंने ऊपर ARB_multitexture का उल्लेख किया है क्योंकि यह विस्तार पूरी स्थिति में गहराई से शामिल है। यह एक बाहरी पर्यवेक्षक को लग रहा था कि एआरबी आम तौर पर शेड्स के विचार से बचना चाहता है। उन्होंने फैसला किया कि यदि वे एक निश्चित पाइपलाइन में पर्याप्त विन्यास को इंजेक्ट करते हैं, तो यह प्रोग्राम योग्य शेडर पाइपलाइन के साथ अपनी क्षमताओं में बराबर होगा।

ARB ने एक-एक करके एक्सटेंशन जारी किए। नाम में "बुनावट_नव" शब्दों के साथ प्रत्येक विस्तार इस उम्र बढ़ने के डिजाइन को पैच करने का एक प्रयास था। एक्सटेंशन की सूची देखें: आठ ऐसे एक्सटेंशन जारी किए गए हैंटुकड़े, और उनमें से कई कोर OpenGL कार्यक्षमता में अनुवाद किया गया है।

उस समय, Microsoft एआरबी का हिस्सा था, और इसे केवल डी 3 डी 9 के रिलीज के लिए छोड़ दिया, इसलिए शायद माइक्रोसॉफ्ट ने ओपनजीएल को किसी तरह से तोड़फोड़ किया। व्यक्तिगत रूप से, मुझे इस सिद्धांत पर दो कारणों से संदेह है। सबसे पहले, उन्हें समिति के अन्य सदस्यों के समर्थन को सुरक्षित करना होगा, क्योंकि प्रत्येक सदस्य के पास केवल एक वोट होता है। दूसरी बात, और इससे भी महत्वपूर्ण बात यह है कि समिति को सब कुछ खराब करने के लिए Microsoft की मदद की आवश्यकता नहीं थी, जिसके प्रमाण हम बाद में देखेंगे।

नतीजतन, एआरबी, एटीआई और एनवीडिया (दोनों सक्रिय प्रतिभागी) के दबाव में सबसे अधिक संभावना है, अंत में जाग गए और कोडांतरक शेड को मानक में पेश किया।

एक भी निराला कहानी चाहते हैं?

हार्डवेयर टी एंड एल। यह वही है जो OpenGL मूल रूप से था।। उच्चतम संभव हार्डवेयर T & L प्रदर्शन प्राप्त करने के लिए, आपको GPU पर शीर्ष डेटा संग्रहीत करने की आवश्यकता है। फिर भी, GPU वर्टेक्स डेटा का मुख्य उपभोक्ता है।

डी 3 डी वी 7 में, माइक्रोसॉफ्ट ने वर्टेक्स बफ़र्स की अवधारणा पेश की, जो जीपीयू में मेमोरी का हिस्सा आवंटित करते हैं और वर्टेक्स डेटा को वहां रखते हैं।

जानना चाहते हैं कि OpenGL में समकक्ष कार्यक्षमता कब दिखाई दी? हाँ, एनवीडिया, सबसे बड़े ओपनगेल प्रशंसक के रूप में, GeForce 256 के रिलीज के समय में GPU पर वर्टेक्स सरणियों को संग्रहीत करने के लिए अपना विस्तार जारी किया। लेकिन ARB ने कब इस तरह की कार्यक्षमता शुरू की?

दो साल बाद। इसके बाद थाकैसे यह अनुमोदित शीर्ष और खंड (डी 3 डी के संदर्भ में पिक्सेल) शेड्स। GPU मेमोरी में वर्टेक्स डेटा संग्रहीत करने के लिए क्रॉस-प्लेटफ़ॉर्म समाधान विकसित करने में ARB को इतना समय लगा। और यही हार्डवेयर T & L को अधिकतम प्रदर्शन प्राप्त करने की आवश्यकता है।

उन सभी को मारने के लिए एक भाषा

तो, OpenGL कुछ समय के लिए टूट गया है। GPU में कोई क्रॉस-प्लेटफॉर्म शेड और हार्डवेयर-स्वतंत्र वर्टेक्स स्टोरेज नहीं थे, जबकि डी 3 डी उपयोगकर्ताओं ने दोनों का आनंद लिया। क्या यह खराब हो सकता है?

आप कह सकते हैं कि यह हो सकता है। मिलिए: 3 डी लैब्स ।

तुम पूछते हो: वे कौन हैं? वे एक मृत कंपनी हैं जिसे मैं ओपनजीएल का असली हत्यारा मानता हूं। बेशक, समिति की सामान्य विफलता ने ओपनग्ल को कमजोर बना दिया था, जबकि इसे डीआरडी को आंसुओं से फाड़ना चाहिए था। लेकिन मेरी राय में, 3D लैब्स शायद OpenGL के वर्तमान बाजार की स्थिति का एकमात्र कारण है। उन्होंने इसके लिए क्या किया है?

उन्होंने ओपनजीएल के लिए एक shader भाषा विकसित की।

3D लैब्स एक मरने वाली कंपनी थी। एनवीडिया के लगातार बढ़ते दबाव से उनके महंगे जीपीयू को वर्कस्टेशन बाजार से बाहर निकाल दिया गया है। और एनवीडिया के विपरीत, 3 डी लैब्स को उपभोक्ता बाजार में पेश नहीं किया गया था; nVidia की जीत का मतलब होगा 3D लैब्स के लिए मौत।

आखिरकार क्या हुआ।

एक ऐसी दुनिया में अपने उत्पादों की ज़रूरत नहीं थी, 3 डी लैब्स ने गेम डेवलपर कॉन्फ्रेंस में दिखाया कि उन्होंने "ओपनजीएल 2.0।" यह एक OpenGL API था जिसे स्क्रैच से फिर से लिखा गया था। और यह समझ में आता है, क्योंकि उन दिनों में ओपनजीएल एपीआई कचरा से भरा हुआ था (जो, हालांकि, आज भी वहीं है)। कम से कम इस बात पर गौर करें कि बनावट का लोडिंग और बाइंडिंग कैसे किया जाता है।

उनके प्रस्ताव का एक भाग shader भाषा था। हाँ, वह है। हालाँकि, मौजूदा क्रॉस-प्लेटफ़ॉर्म एक्सटेंशन के विपरीत, उनकी शेडर भाषा "उच्च स्तर" थी (सी shader भाषा के लिए एक उच्च स्तर है)।

उसी समय, Microsoft अपनी स्वयं की shader भाषा पर काम कर रहा था। जिसे उन्होंने अपनी सभी सामूहिक कल्पनाओं सहित ... हाई लेवल शैडर लैंग्वेज (HLSL) कहा है। लेकिन भाषा के लिए उनका दृष्टिकोण मौलिक रूप से अलग था।

3D लैब्स के साथ सबसे बड़ी समस्या यह थी कि यह एम्बेड करने योग्य था। Microsoft ने पूरी तरह से अपनी भाषा निर्धारित की। उन्होंने एक संकलक जारी किया जो एसएम 2.0 शेड्स (या उच्चतर) के लिए कोडांतरक कोड उत्पन्न करता है, जो बदले में, डी 3 डी खिला सकता है। डी 3 डी वी 9 के दिनों में, एचएलएसएल ने डी 3 डी को सीधे नहीं छुआ। वह एक अच्छा लेकिन वैकल्पिक अमूर्त था। डेवलपर को हमेशा कंपाइलर निकास को लेने और अधिकतम प्रदर्शन के लिए इसे मोड़ने का अवसर मिला।

3D लैब्स ने इनमें से कोई भी नहीं किया। आप ड्राइवर को सी-लाइक भाषा देते हैं, और यह एक शेडर बनाता है। वह सब है। कोई कोडांतरक shader, कुछ भी नहीं है कि कुछ और को खिलाया जा सकता है। केवल एक OpenGL ऑब्जेक्ट एक शेडर का प्रतिनिधित्व करता है।

OpenGL उपयोगकर्ताओं के लिए, इसका मतलब है कि वे OpenGL डेवलपर्स की सनक के लिए प्रवण थे जिन्होंने अभी-अभी असेंबलर जैसी भाषाओं को संकलित करना सीखा था। OpenGL shader भाषा संकलक (GLSL) बग के बारे में उग्र रहा है। मामलों को बदतर बनाने के लिए, यदि आप अलग-अलग प्लेटफार्मों पर सही ढंग से संकलित करने के लिए shader प्राप्त करने में सक्षम थे (जो अपने आप में एक बड़ी उपलब्धि थी), तो यह अभी भी उन समय के ऑप्टिमाइज़र के अधीन था जो उतने इष्टतम नहीं थे जितना कि वे हो सकते हैं।

यह जीएसएसएल का एकमात्र बड़ा दोष नहीं था। इकलौते से दूर ।

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

GLSL में ऐसा कुछ नहीं था। 3 डी लैब्स "सॉफ़्टवेयर ऑब्जेक्ट" नामक कुछ बनाने के साथ शीर्ष और खंड के टुकड़े एक साथ जुड़े हुए थे। इसलिए, विभिन्न संयोजनों में कई शीर्ष और टुकड़ा शेड के संयुक्त उपयोग के लिए, कई प्रोग्राम ऑब्जेक्ट बनाना आवश्यक था। इससे दूसरी सबसे बड़ी समस्या पैदा हुई।

3 डी लैब्स ने सोचा कि वे सबसे चतुर थे। उन्होंने GLSL संकलन मॉडल के आधार के रूप में C / C ++ लिया। यह तब होता है जब आप एक सी-फाइल लेते हैं और इसे एक ऑब्जेक्ट फाइल में संकलित करते हैं, और फिर कई ऑब्जेक्ट फाइल लेते हैं और उन्हें एक प्रोग्राम में कंपोज करते हैं। यह कैसे GLSL संकलित करता है: पहले आप एक वर्टेक्स या टुकड़ा shader को shader ऑब्जेक्ट में संकलित करते हैं, फिर इन ऑब्जेक्ट्स को एक प्रोग्राम ऑब्जेक्ट में डालते हैं और अंत में एक प्रोग्राम बनाने के लिए एक साथ रख देते हैं।

सिद्धांत रूप में, इसने "लाइब्रेरी" जैसी ठंडी चीज़ों को दिखाने की अनुमति दी, जिनमें मुख्य shader द्वारा बुलाया कोड होता है। व्यवहार में, इसके परिणामस्वरूप शेड को दो बार संकलित किया गया: एक बार संकलन मंच पर और दूसरी बार संकलन मंच पर। विशेष रूप से, एनवीडिया से संकलक इसके लिए प्रसिद्ध था। इसने कोई मध्यवर्ती वस्तु कोड उत्पन्न नहीं किया; उन्होंने शुरुआत में संकलित किया, परिणाम को बाहर फेंक दिया और संकलन के स्तर पर फिर से संकलित किया।

इस प्रकार, दो अलग-अलग टुकड़े शेडों को वर्टेकर shader संलग्न करने के लिए, D3D की तुलना में बहुत अधिक संकलन करना आवश्यक था। विशेष रूप से यह देखते हुए कि पूरे संकलन को ऑफ़लाइन किया जाता है , और कार्यक्रम को सीधे निष्पादित करने से पहले नहीं।

जीएलएसएल की अन्य समस्याएं थीं। शायद 3 डी लैब्स पर सभी दोषों को दोष देना गलत होगा, क्योंकि अंत में एआरबी ने मंजूरी दे दी और ओपनजीएल में शेडर्स की भाषा को शामिल किया (लेकिन 3DLabs सुझावों से और कुछ नहीं)। हालांकि, मूल विचार अभी भी 3 डी लैब्स के लिए था।

और अब सबसे दुखद बात: 3 डी लैब्स सही थे (ज्यादातर)। GLSL उस समय HLSL की तरह एक वेक्टर भाषा नहीं है। ऐसा इसलिए हुआ क्योंकि 3D लैब्स का हार्डवेयर स्केलर (nVidia से आधुनिक हार्डवेयर की तरह) था, और वे उस दिशा को चुनने में पूरी तरह से सही थे जिसका बाद में कई उपकरण निर्माताओं ने अनुसरण किया।

वे "उच्च-स्तरीय" भाषा के संकलन मॉडल की पसंद के साथ सही थे। यहां तक ​​कि आखिरकार डी 3 डी भी इस पर आ गया।

समस्या यह है कि 3 डी लैब्स गलत समय पर सही थे । और भविष्य में समय से पहले आने के प्रयास में, भविष्य के लिए तैयार होने के प्रयास में, वे वर्तमान को अलग कर देते हैं। यह ओपनजीएल में टी एंड एल कार्यक्षमता की तरह दिखता है, जो हमेशा इसमें रहा है। ओपनजीएल टी एंड एल पाइपलाइन को छोड़कर उपयोगी थाऔर हार्डवेयर टीएंडएल के आगमन से पहले, GLSL एक बोझ था, इससे पहले कि बाकी दुनिया उसके साथ पकड़े।

GLSL अब एक अच्छी भाषा है । लेकिन उस समय क्या था? वह भयानक था। और ओपनजीएल को इससे नुकसान उठाना पड़ा।

एपोथोसिस के रास्ते पर

मैं इस दृष्टिकोण का समर्थन करता हूं कि 3 डी लैब्स ने ओपनजीएल को एक घातक झटका दिया, लेकिन ताबूत में आखिरी कील एआरबी द्वारा ही बनाई गई थी।

यह कहानी आपने सुनी होगी। OpenGL 2.1 के दिनों में, OpenGL की बड़ी समस्याएं थीं। उन्होंने संगतता का एक बड़ा भार उठाया । एपीआई अब उपयोग करने के लिए आसान नहीं था। एक चीज को पांच अलग-अलग तरीकों से किया जा सकता है और यह स्पष्ट नहीं है कि कौन सा तेज है। आप सरल ट्यूटोरियल्स के साथ "ओपन" सीख सकते हैं, लेकिन आपने ओपनगैल नहीं सीखा है जो सही ग्राफिक्स शक्ति और प्रदर्शन प्रदान करता है।

एआरबी ने ओपनजीएल का आविष्कार करने के लिए एक और प्रयास करने का फैसला किया। यह 3D लैब्स से “OpenGL 2.0” की तरह था, लेकिन बेहतर था क्योंकि ARB इस प्रयास के पीछे था। उन्होंने इसे "लोंग्स पीक" कहा।

एपीआई को बेहतर बनाने में थोड़ा समय बिताने के बारे में क्या बुरा है? बुरी खबर यह है कि Microsoft एक अनिश्चित स्थिति में है। यह समय था विस्टा में अपग्रेड करने का।

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

आप इस दृष्टिकोण के गुणों के बारे में लंबे समय तक बहस कर सकते हैं, और क्या यह संभव भी था, लेकिन तथ्य यह है: Microsoft ने केवल विस्टा और उच्चतर के लिए डी 3 डी 10 बनाया। यहां तक ​​कि एक डी 3 डी- संगत हार्डवेयर पर, विस्टा के बिना डी 3 डी एप्लिकेशन को चलाना असंभव था।

, … , . , , API, , , API , .

, D3D 10 OpenGL. , ARB Long Peaks.

एआरबी ने एपीआई को बेहतर बनाने पर काम करते हुए डेढ़ से दो साल का अच्छा समय बिताया। ओपनजीएल 3.0 जारी होने तक, विस्टा पर संक्रमण समाप्त हो गया था, विंडोज 7 रास्ते में था, और गेम डेवलपर्स को अब डी 3 डी 10 की कार्यक्षमता के बारे में परवाह नहीं थी। अंत में, डी 3 डी 10 के लिए उपकरण ने डीबीडी 9 पर अनुप्रयोगों के साथ पूरी तरह से काम किया। 9. पीसी से पोर्टिंग की गति में वृद्धि के साथ। कंसोल (या कंसोल मार्केट में पीसी डेवलपर्स के संक्रमण के साथ), डेवलपर्स ने डी 3 डी की कार्यक्षमता को कम और कम

किया । 10. अगर डेवलपर्स को विंडोज़ एक्सपी पर भी इस कार्यक्षमता तक पहुंच मिल सकती है, तो ओपनजीएल के विकास को जीवंतता का प्रभार मिल सकता है। लेकिन एआरबी इस मौके को चूक गया। क्या आप जानना चाहते हैं कि सबसे खराब क्या है?

एआरबी फेल हो गयायह करने की कोशिश कर दो कीमती साल खर्च करने के बावजूद खरोंच से एपीआई का आविष्कार करें। इसलिए, उन्होंने यथास्थिति को वापस लौटा दिया, कार्यक्षमता को अप्रचलित घोषित करने के लिए केवल एक तंत्र को जोड़ा।

नतीजतन, एआरबी न केवल प्रमुख अवसरों से चूक गया , बल्कि उस काम को करने में भी विफल रहा जिसने उन्हें इस चूक के लिए प्रेरित किया। यह सभी दिशाओं में एक महाकाव्य असफल था।

यह ओपनजीएल और डायरेक्ट 3 डी के बीच टकराव की कहानी है। छूटे हुए अवसरों की कहानी, सबसे बड़ी मूर्खता, जानबूझकर लापरवाही और प्रतिबंधात्मक गैरबराबरी।