क्या मुझे वास्तव में ग्राफिक्स एपीआई का उपयोग करने की आवश्यकता है?

Question

3 डी गेम में हार्डवेयर त्वरण प्राप्त करने के लिए ग्राफिक्स एपीआई का उपयोग करना आवश्यक है? OpenGL, DirectX , CUDA, OpenCL जैसे ग्राफिक्स-कार्ड एपीआई पर निर्भरता से मुक्त होना किस हद तक संभव है?

क्या मैं अपने गेम के लिए अपना ग्राफिक्स एपीआई या लाइब्रेरी बना सकता हूं? यहां तक ​​कि अगर यह कठिन है, तो क्या सैद्धांतिक रूप से ग्राफिक्स ड्राइवर से संपर्क करना और GPU पर सब कुछ प्रस्तुत करना मेरे 3 डी एप्लिकेशन के लिए सैद्धांतिक रूप से संभव है ?

Comments

CUDA और OpenCL ग्राफिक्स API नहीं हैं।

— सोप

"स्वतंत्र रूप से ग्राफिक्स ड्राइवर से संपर्क करें" आपको हमेशा कुछ एपीआई की आवश्यकता होती है!

— जोसेफ

नहीं, आपको ग्राफिक्स के लिए एपीआई की आवश्यकता नहीं है, आप सीधे ड्राइवर तक पहुंच सकते हैं, यह वहां भी नहीं रुकता है, आप अपने खुद के ड्राइवर को सीधे हार्डवेयर से बात करने के लिए लिख सकते हैं यदि आप कभी भी ऐसा चाहते हैं। लेकिन आपका अगला प्रश्न बहुत अधिक महत्वपूर्ण है: "क्या मुझे ग्राफिक्स एपीआई का उपयोग करना चाहिए?", हां, हां आपको चाहिए।

— केविन

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

— केविन

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

— सैंडलफूट

Answer 1

मुझे लगता है कि बहुत सारे उत्तर एक महत्वपूर्ण बिंदु को याद करते हैं: आप ऐसे एप्लिकेशन लिख सकते हैं जो सीधे हार्डवेयर तक पहुंचते हैं, लेकिन आधुनिक ऑपरेटिंग सिस्टम पर नहीं । यह सिर्फ समय की समस्या नहीं है, लेकिन "आपके पास विकल्प नहीं है" समस्या है।

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

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

तो नहीं, आपका गेम सीधे हार्डवेयर का उपयोग नहीं कर सकता, जब तक कि आप केवल DOS जैसे असुरक्षित ऑपरेटिंग सिस्टम को लक्षित नहीं कर रहे हैं, और आधुनिक उपभोक्ता ऑपरेटिंग सिस्टम पर गेम के लिए आपका एकमात्र संभव विकल्प DirectX, OpenGL या जैसे सार्वजनिक API को लक्षित करना है Vulkan।

Comments

कुडोस, चर्चा के लिए अच्छा जोड़। आप हर दिन कुछ नया सीखते हैं।

— इंजीनियर

हार्डवेयर एक्सेस करने के लिए कर्नेल मॉड्यूल लिखने की आपकी पसंद को क्या प्रतिबंधित करता है? इसके अलावा, यदि आप एक एकल कार्ड (आपकी मशीन में एक) को लक्षित कर रहे हैं, तो संगतता समस्याएं दूर हो जाती हैं; हालाँकि यह अभी भी एक तुच्छ चीज़ से दूर है; लेकिन संभव के दायरे में, रिवर्स इंजीनियर ड्राइवरों को दिया गया; खासकर यदि आपके पास केवल एक सीमित गुंजाइश है कि आप कार्ड के साथ क्या करना चाहते हैं।

— जोएल बोसवेल्ड

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

— सीन मिडिलिचच

Answer 2

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

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

यह भी याद रखें कि सीपीयू प्रतिपादन अक्षम है और जीपीयू की तुलना में खराब प्रदर्शन से ग्रस्त है।

Comments

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

— क्रिस हेस

अच्छी बात है, @ क्रिसहैस ... को जोड़ने के लिए संपादित किया गया। कभी-कभी ऐसा माना जाता है कि ऐसी चीजें स्पष्ट हैं।

— अभियंता

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

— डेविड जेड

@DavidZ क्या आपने ड्राइवर लिखा है? क्या आपको पता है कि जब आपके पास ऐनक नहीं होती है, तब भी जटिल हार्डवेयर में क्या अंतर होता है, जब ड्राइवर को विकसित करने के लिए कार्ड के निर्माता द्वारा नियोजित इंजीनियरों को भी महीनों का समय लगता है? अब गुणा करें कि हालांकि कई आर्किटेक्चर को आपको समर्थन देना होगा। अगर मैं कहता हूं, "बिना उपकरण के एवरेस्ट पर चढ़ना असंभव है," बेशक एक मौका है जो आप कर सकते हैं, लेकिन यह वास्तव में एक मौका है ... तो कोई भी इस मुद्दे पर बहस क्यों करेगा?

— अभियंता

ओपी से पूछें कि वे इस बिंदु पर बहस क्यों करना चाहते हैं ;-) लेकिन विशेष रूप से संपादन के बाद, यह काफी स्पष्ट है कि वे क्या चाहते हैं।

— डेविड जेड

Answer 3

OpenGL या DirectX जैसे एपीआई आंशिक रूप से ऑपरेटिंग सिस्टम द्वारा लागू किए जाते हैं और आंशिक रूप से ग्राफिक ड्राइवर द्वारा ही लागू किए जाते हैं।

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

Answer 4

अपने पीसी को MS-DOS में बूट करें। फिर, पीसी गेम प्रोग्रामर एनसाइक्लोपीडिया की अपनी कॉपी का उपयोग करके , आप कार्ड के वीईएसए रजिस्टर और वीडियो मेमोरी में सीधे लिख सकते हैं । मेरे पास अभी भी कोड है जो मैंने 20 साल पहले लिखा था ऐसा करने के लिए और सॉफ्टवेयर में अल्पविकसित 3 डी प्रस्तुत करना।

वैकल्पिक रूप से, आप सिर्फ DirectX का उपयोग कर सकते हैं; यह वास्तव में पतली अमूर्त परत है, और आपको सीधे वीडियो बफ़र्स में लिखने और फिर उन्हें स्क्रीन पर स्वैप करने की सुविधा देता है।

अपने स्वयं के वीडियो हार्डवेयर के निर्माण का चरम दृष्टिकोण भी है ।

Answer 5

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

हालाँकि, इसका मतलब यह नहीं है कि आपको किसी विशेष एपीआई पर 100% निर्भर होना चाहिए। आप हमेशा अपनी खुद की अमूर्त परत को कोड कर सकते हैं, और फिर और अधिक विशिष्ट कार्यान्वयन (जैसे एक DirectX कार्यान्वयन, एक OpenGL कार्यान्वयन, ...) को अंदर और बाहर स्वैप कर सकते हैं।

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

Answer 6

संक्षेप में: सैद्धांतिक रूप से आप कर सकते हैं, लेकिन यह अक्षम्य है, और आपको कोई लाभ नहीं मिलेगा। एपीआई आज सीमाएं हर दिन कम हो गई हैं, आपके पास CUDA और OpenCL और शेड्स हैं। इसलिए पूर्ण नियंत्रण होना कोई समस्या नहीं है।

---

पूर्ण विवरण:

इसका उत्तर देना एक उबाऊ हाँ है । असली सवाल यह है कि क्यों ?

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

जीपीयू के साथ आपको "बेहतर" प्रदर्शन मिलता है, लेकिन बहुत सारी स्वतंत्रता खो देते हैं। ग्राफिक्स डेवलपर्स उस स्वतंत्रता को वापस पाने के लिए जोर दे रहे हैं। इसलिए, हर रोज अधिक अनुकूलन पाइपलाइन। आप ड्राइवरों को छूने के बिना CUDA / OpenCL और यहां तक ​​कि शेड्स का उपयोग करके लगभग कुछ भी कर सकते हैं।

Answer 7

आप हार्डवेयर से बात करना चाहते हैं। आपको हार्डवेयर से बात करने के तरीके का उपयोग करने की आवश्यकता है। यह तरीका हार्डवेयर का इंटरफ़ेस है। यही OpenGL, DirectX, CUDA, OpenCL और जो कुछ भी हैं।

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

Answer 8

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

एनवीआईडीआईए कार्ड्स के लिए, आपको ओपन सोर्स नोव्यू प्रोजेक्ट को देखना चाहिए । उनके पास यहां महान संसाधनों का संग्रह है ।

ग्राफिक्स कार्ड के अन्य ब्रांडों के लिए, आप इसी तरह की परियोजनाओं और प्रलेखन पा सकते हैं।

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

Answer 9

DirectX या OpenGl से छुटकारा पाना निर्भरता को दूर नहीं करेगा, यह उनमें से अधिक का परिचय देगा। अन्य उत्तरों में पहले से ही कई अच्छे बिंदु शामिल हैं, इसलिए ग्राफिक्स ग्राफिक्स से सीधे बात करना भी संभव नहीं है (कम से कम यह संभव नहीं है), लेकिन मेरा पहला जवाब होगा: यदि आपने वास्तव में एक पुस्तकालय लिखा है जो सभी सामान्य 3 डी को अमूर्त करता है ग्राफिक्स एक एकल एपीआई में प्रभावी ढंग से आप DirectX / OpenGl फिर से लिखा होगा। यदि आप एक गेम लिखने के लिए अपने कोड का उपयोग करने के लिए थे, तो आपने अपनी नई लाइब्रेरी को एक नई निर्भरता के रूप में जोड़ा होगा, जैसे कि अब आपके पास एक निर्भरता के रूप में DirectX / OpenGl है।

DirectX या OpenGl का उपयोग करके आपकी निर्भरता मूल रूप से कह रही है "यह कोड एक पुस्तकालय पर निर्भर करता है जो कोड प्रदान करता है जो बताता है कि विभिन्न ग्राफिक्स कार्ड पर कुछ कमांड कैसे चलाएं"। यदि आप इस तरह के पुस्तकालय के बिना गए थे, तो आप "इस कोड को ग्राफिक्स हार्डवेयर पर निर्भर करता है जो इस तरह से व्यवहार करता है जैसे कि हार्डवेयर जब मैं गेम का निर्माण करता था तब मौजूद होता है।"

OpenGl या DirectX जैसे अंश हार्डवेयर निर्माताओं को अपने स्वयं के (ड्राइवर) कोड प्रदान करने की अनुमति देते हैं जो एक सामान्य कोड आधार की ओर ले जाते हैं, इसलिए गेम को हार्डवेयर पर चलाने की अधिक संभावना होती है जो गेम लिखे जाने पर भी मौजूद नहीं थे।

Answer 10

सबसे पहले, CUDA और OpenCL ग्राफिक्स एपिस नहीं हैं। वे गणनात्मक एपिस हैं।

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

मैं समझता हूं कि आप सब कुछ स्वयं बनाना चाहते हैं और इंजन या किसी भी चीज का उपयोग नहीं करना चाहते हैं। लेकिन अपने खुद के ग्राफिक्स बनाने के लिए उपयोगकर्ता के लिए सिर्फ असुविधा पैदा होगी।

Answer 11

आप अपने खुद के ड्राइवर और एपीआई लिख सकते हैं, आपको रोकने के लिए कुछ भी नहीं है लेकिन आपकी क्षमता और ज्ञान का स्तर है। यदि कुछ और नहीं यह एक अच्छा सीखने का अनुभव होगा, तो वास्तविक समस्या यह है कि पिछले ग्राफिक अनुभव के बहुत सारे होने के बाद भी अगर आप एक महान प्रोग्रामर हैं, तो आप शायद उस नुकसान में होंगे जो आपको करने की आवश्यकता है ... या यहां तक ​​कि आरंभ करना।

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