OpenGL बनाम Direct3D टकराव का इतिहास

शुरू करने से पहले, मैं कहता हूँ: मैं OpenGL के बारे में Direct3D की तुलना में बहुत अधिक जानता हूँ। मैंने अपने जीवन में कभी भी डी 3 डी के लिए कोड की एक पंक्ति नहीं लिखी है, और मैंने ओपनजीएल ट्यूटोरियल लिखा है। तो जो मैं आपको यहां बताऊंगा वह पूर्वाग्रह की बात नहीं है। अब यह सिर्फ एक कहानी है।

संघर्ष का मूल

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

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

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

और इसलिए DirectX का जन्म हुआ।

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

और Microsoft ने कुछ मध्यवर्ती ड्राइवर खरीदे और Direct3D संस्करण को उसमें से 3 बना दिया। उसे हर किसी और हर जगह से डांटा गया। और ऐसे ही नहीं; कोड की एक झलक डरावनी याद दिलाने के लिए काफी थी।

आईडी सॉफ्टवेयर के पुराने जॉन कार्मैक ने इस कचरे को देखा, कहा: "टू हेल!", और एक और एपीआई के तहत लिखने का फैसला किया - ओपनजीएल।

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

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

सनराइज ओपन

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

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

फिर Voodoo2 के साथ 3Dfx आया। यह पहला मल्टीटेक्स्टुरिंग डिवाइस था जो ओपनजीएल पहले नहीं कर सकता था। हालांकि 3Dfx OpenGL मानक में बिल्कुल भी फिट नहीं था, लेकिन बाद के मल्टीटाफ्टिंग ग्राफिक्स चिप्स (TNT1) के डेवलपर, NVIDIA ने इस कार्यान्वयन पर एक नज़र डाली। ARB को एक एक्सटेंशन जारी करना पड़ा: GL_ARB_multitexture, जिसने मल्टीटेक्स्चर को एक्सेस दिया।

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

उफ़।

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

डी 3 डी इसके साथ दूर हो गया।

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

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

डॉन ऑफ शेड्स, ट्विलाइट ओपनजीएल

फिर GeForce 3 आया और एक ही समय में कई चीजें हुईं।

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

फिर एक दर्दनाक तलाक हो गया। लेकिन यह पूरी तरह से अलग कहानी है।

पीसी के लिए, इसका मतलब है कि GeForce 3 D3D v8 के साथ एक साथ निकला। और यह देखना आसान है कि आठ में GeForce 3 ने कितनी प्रभावित की। Shader Model 1 में पिक्सेल शेड्स बहुत ही मजबूती से NVIDIA हार्डवेयर से बंधे थे। NVIDIA के हार्डवेयर अमूर्त बिल्कुल नहीं था; SM 1.0 अनिवार्य रूप से GeForce 3 ने क्या किया था।

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

यह डी 3 डी की ओर से विफलता की तरह लग सकता है। लेकिन असफलता और सफलता एक सापेक्ष मामला है। ओपन विफलता शिविर में वास्तविक विफलता हुई।

NVIDIA ने ओपनजीएल को प्यार किया, इसलिए जब GeForce 3 बाहर आया, तो उन्होंने ओपनजीएल एक्सटेंशन किट जारी किया। केवल NVIDIA के लिए उपयुक्त प्रोप्राइटरी एक्सटेंशन। स्वाभाविक रूप से, जब 8500 बाहर आया, तो वह उनमें से किसी का भी उपयोग नहीं कर सका।

आप देखते हैं, डी 3 डी 8 में आप एटीआई हार्डवेयर पर कम से कम एसएम 1.0 शेड्स चला सकते हैं। स्वाभाविक रूप से, 8500 की अच्छाइयों का उपयोग करने के लिए आपको नए शेड लिखने होंगे, लेकिन आपके कोड ने कम से कम काम किया ।

ओपनजीएल में 8500 पर कम से कम कुछ शेड्स प्राप्त करने के लिए, एटीआई को कई ओएनजीएल एक्सटेंशन लिखने थे। केवल एटीआई के लिए उपयुक्त प्रोप्राइटरी एक्सटेंशन। तो, आपको कोड निष्पादन के दो तरीके लिखने थे, कम से कम कुछ शेड करने के लिए, NVIDIA और ATI के लिए।

अब आप शायद पूछेंगे: "OpenGL ARB क्या कर रहा था, जिसका काम OpenGL को अद्यतित रख रहा था?" हां, वही चीजें जो ज्यादातर समितियां करती हैं: बेवकूफ।

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

और एआरबी ने विस्तार के बाद विस्तार जारी करना शुरू कर दिया। प्रत्येक विस्तार, जिसके नाम पर "बुनावट_ेनव" मौजूद था, इस वृद्धावस्था के डिजाइन को पैच करने का एक और प्रयास था। रजिस्ट्री की जाँच करें: ARB और EXT एक्सटेंशन के बीच उनमें से पहले से ही आठ हैं। कई ओपनजीएल के प्रमुख संस्करणों में शामिल हैं।

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

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

अधिक मूर्खता देखना चाहते हैं?

हार्डवेयर टी एंड एल। जो पहले OpenGL में दिखाई दिया था । यहाँ क्या दिलचस्प है। हार्डवेयर T & L के अधिकतम प्रदर्शन को निचोड़ने के लिए, आपको डेटा को GPU में संग्रहीत करना होगा। आखिरकार, यह GPU में है कि उनका उपयोग किया जाता है।

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

जानना चाहते हैं कि OpenGL में आपका एनालॉग कब दिखाई दिया? ओह, NVIDIA, OpenGL से संबंधित हर चीज का प्रशंसक होने के नाते (जब तक यह लिखा जाता है कि यह NVIDIA का मालिकाना विस्तार है), उन्होंने GeForce 256 की पहली रिलीज के दौरान वर्टेक्स सरणियों के लिए एक्सटेंशन जारी किया। लेकिन ARB ने आधिकारिक तौर पर इस तरह की कार्यक्षमता प्रदान करने का फैसला कब किया?

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

एक भाषा सब कुछ नष्ट करने के लिए

इसलिए, ओपनजीएल का विकास खंडित हो गया है। कोई एकल शेड नहीं हैं, GPU में कोई एकल संग्रहण नहीं है, जब D3D उपयोगकर्ताओं ने पहले ही दोनों का आनंद लिया था। क्या यह खराब हो सकता है?

खैर ... आप ऐसा कह सकते हैं। मिलिए: 3 डी लैब्स

वे कौन हैं, आप पूछें? यह एक दिवालिया कंपनी है जिसे मैं ओपनजीएल के असली हत्यारे मानता हूं। स्वाभाविक रूप से, समग्र फ़्लैक्सिड एआरबी ने ओपनग्ल को कमजोर बना दिया था जब सभी मोर्चों पर डी 3 डी को हरा देना चाहिए था। लेकिन 3 डी लैब्स ओपनगेट की वर्तमान बाजार स्थिति का सबसे बड़ा कारण है। वे ऐसा क्या कर सकते थे?

उन्होंने OpenGL Shader Language विकसित की।

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

और इसलिए यह हुआ।

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

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

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

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

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

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

हालांकि यह GLSL की मुख्य समस्या थी, लेकिन केवल एक ही नहीं। केवल एक से दूर ।

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

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

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

यद्यपि इसने हमें कुछ संभावित शांत चीजें करने की अनुमति दी, जैसे कि मुख्य पुस्तकालयों द्वारा साझा किए गए अतिरिक्त कोड वाले शेड्स के "पुस्तकालय", व्यवहार में इसका मतलब था कि शेड्स दो बार संकलित किए गए थे। एक बार संकलन चरण में, एक बार लिंकिंग स्टेज पर। कोई मध्यवर्ती वस्तु कोड नहीं बनाया गया था; shader बस संकलित किया गया था, संकलन परिणाम को फेंक दिया गया था और संकलन को लिंक करने के दौरान दोहराया गया था।

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

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

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

वे "उच्च-स्तरीय" भाषाओं के लिए "संकलन-ऑनलाइन" मॉडल के साथ भी सही थे। डी 3 डी ने बाद में इसे भी बदल दिया।

समस्या यह थी कि 3 डी लैब्स गलत समय पर सही थे। और भविष्य को बहुत जल्दी कॉल करने की कोशिश में, यह भविष्यवाणी करने की कोशिश में, उन्होंने वर्तमान को अस्वीकार कर दिया। यह भी ऐसा है जैसे OpenGL में हमेशा T & L करने की क्षमता थी। इस तथ्य के अलावा कि OpenGL में T & L पाइपलाइन हार्डवेयर कार्यान्वयन से पहले भी उपयोगी थे, और GLSL दुनिया को स्वीकार करने के लिए तैयार होने से पहले सिर्फ एक बोझ था।

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

एपोथोसिस निकट आ रहा है

हालांकि मैं दावा करता हूं कि 3 डी लैब्स ने एक नश्वर झटका दिया था, यह एआरबी समिति थी जिसने ओपनगेल ताबूत के ढक्कन में आखिरी कील को हथौड़ा दिया था।

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

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

पुराने एपीआई को ठीक करने की कोशिश में क्या गलत था? बुरी खबर यह थी कि उस समय Microsoft कमजोर था। यह विस्टा का रिलीज़ समय था।

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

यद्यपि कोई संदेह कर सकता है कि क्या यह आवश्यक था, लेकिन तथ्य यह है: माइक्रोसॉफ्ट ने फैसला किया कि डी 3 डी 10 केवल विस्टा (और बाद के ओएस) के लिए होगा। यहां तक ​​कि अगर आपके पास डी 3 डी 10 के कार्यों को करने में सक्षम हार्डवेयर था, तो आप विस्टा शुरू किए बिना डी 3 डी 10 एप्लिकेशन को नहीं चला सकते थे।

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

हालांकि, डेवलपर्स OpenGL के माध्यम से डी 3 डी 10 स्तर की सुविधाओं का उपयोग कर सकते हैं। ठीक है, अगर वे एआरबी लेग्स पीक पर काम करने में इतने व्यस्त नहीं होते।

एपीआई को बेहतर बनाने के लिए एआरबी ने बड़े और डेढ़ से दो साल खर्च किए। जब ओपनजीएल 3.0 बाहर आया, तो विस्टा समय से बाहर चल रहा था, Win7 क्षितिज पर दिखाई दिया, और अधिकांश डेवलपर्स डी 3 डी -10 कार्यों में रुचि नहीं रखते थे। अंत में, हार्डवेयर जिसके लिए डी 3 डी 10 का इरादा था, डी 3 डी 9 के साथ आश्चर्यजनक रूप से काम किया गया था। और पीसी से सेट-टॉप बॉक्स (या पीसी-डेवलपर्स जो सेट-टॉप बॉक्स के लिए विकसित हो रहे थे) के बंदरगाहों के साथ, डी 3 डी 10 वर्ग के कार्यों का दावा नहीं किया गया था।

अगर डेवलपर्स के पास इन कार्यों तक पहले पहुंच थी, तो WinXP के साथ मशीनों पर OpenGL के माध्यम से, OpenGL विकास को एक बहुत आवश्यक आवेग प्राप्त होगा। लेकिन एआरबी यह मौका चूक गया। और आप जानते हैं कि सबसे खराब क्या है?

इस तथ्य के बावजूद कि दो मूल्यवान वर्षों को खरोंच से एपीआई विकसित करने पर खर्च किया गया था ... वे अभी भी असफल रहे और पिछले संस्करण में लौटने के लिए मजबूर हुए।

, ARB , , . .

OpenGL Direct3D. , , .