GPU बहुत अच्छे हैं एक समानांतर कार्य। जो महान है ... यदि आप एक समानांतर कार्य चला रहे हैं।
खेल कम से कम समानांतर प्रकार के अनुप्रयोग के बारे में हैं । मुख्य गेम लूप के बारे में सोचें। एआई (चलो मान लें कि खिलाड़ी को एआई के विशेष मामले के रूप में संभाला जाता है) को भौतिकी द्वारा ज्ञात टकरावों का जवाब देने की आवश्यकता है। इसलिए, इसे बाद में चलाना होगा। या बहुत कम से कम, भौतिकी को भौतिकी प्रणाली की सीमा के भीतर एआई दिनचर्या को कॉल करने की आवश्यकता है (जो आमतौर पर कई कारणों से एक अच्छा विचार नहीं है)। भौतिकी के चलने तक ग्राफिक्स नहीं चल सकते, क्योंकि भौतिकी वह है जो वस्तुओं की स्थिति को अपडेट करती है। बेशक, एआई को रेंडर करने से पहले भी चलने की जरूरत है, क्योंकि एआई नई वस्तुओं को स्पॉन कर सकता है। एआई और खिलाड़ी नियंत्रण के बाद ध्वनियों को चलाने की आवश्यकता है
सामान्य तौर पर, खेल बहुत कम तरीकों से खुद को थ्रेड कर सकते हैं। ग्राफिक्स को एक धागे में बंद किया जा सकता है; गेम लूप ग्राफिक्स थ्रेड पर डेटा का एक गुच्छा हिला सकता है और कह सकता है: इसे रेंडर करें। यह कुछ बुनियादी प्रक्षेप कर सकता है, ताकि मुख्य गेम लूप को ग्राफिक्स के साथ तालमेल न रखना पड़े। ध्वनि एक और धागा है; गेम लूप कहता है "यह खेलें", और यह खेला जाता है।
उसके बाद, यह सब दर्दनाक होना शुरू हो जाता है। यदि आपके पास जटिल पथप्रदर्शक एल्गोरिदम हैं (जैसे कि आरटीएस के लिए), तो आप उन्हें थ्रेड कर सकते हैं। एल्गोरिदम को पूरा करने में कुछ फ्रेम लग सकते हैं, लेकिन वे कम से कम समवर्ती होंगे। इसके अलावा, यह बहुत कठिन है।
तो आप 4 धागे देख रहे हैं: खेल, ग्राफिक्स, ध्वनि, और संभवतः दीर्घकालिक एआई प्रसंस्करण। यह बहुत नहीं है। और यह जीपीयू के लिए लगभग पर्याप्त नहीं है, जिसमें एक ही बार में उड़ान के सैकड़ों धागे हो सकते हैं। यह GPU को उनका प्रदर्शन देता है: एक ही बार में उन सभी थ्रेड का उपयोग करने में सक्षम होना। और खेल बस ऐसा नहीं कर सकते।
अब, शायद आप कुछ कार्यों के लिए "विस्तृत" जाने में सक्षम हो सकते हैं। उदाहरण के लिए, AI आमतौर पर एक दूसरे से स्वतंत्र होते हैं। तो आप एक बार में कई दर्जन AI की प्रक्रिया कर सकते हैं। जब तक आपको वास्तव में उन्हें एक-दूसरे पर निर्भर बनाने की आवश्यकता नहीं है, तब तक के लिए ठीक है। तब तुम मुश्किल में हो। भौतिक वस्तुएं समान रूप से स्वतंत्र होती हैं ... जब तक कि उनके बीच कोई बाधा न हो और / या वे किसी चीज से टकरा जाएं। तब वे बहुत निर्भर हो जाते हैं।
इसके अलावा, वहाँ तथ्य यह है कि GPU बस उपयोगकर्ता इनपुट के लिए उपयोग नहीं है, जो मुझे लगता है कि खेल के लिए महत्वपूर्ण है। ताकि प्रदान किया जा सके। इसमें OS पर बात करने की कोई सीधी फ़ाइल या कोई वास्तविक तरीका भी नहीं है; इसलिए फिर से, इसे प्रदान करने के लिए किसी तरह का रास्ता बनाना होगा। ओह, और वह सब ध्वनि प्रसंस्करण? GPUs ध्वनियों का उत्सर्जन नहीं करते हैं। इसलिए उन लोगों को सीपीयू में वापस जाना होगा और फिर साउंड चिप के लिए बाहर जाना होगा।
ओह, और GPU के लिए कोडिंग भयानक है। सही होना मुश्किल है, और एक GPU आर्किटेक्चर के लिए "सही" क्या है, दूसरे के लिए बहुत गलत हो सकता है । और यह भी सिर्फ AMD से NVIDIA के लिए स्विचन नहीं है; यह GeForce 250 से GeForce 450 पर स्विच किया जा सकता है। यह बुनियादी वास्तुकला में एक बदलाव है। और यह आसानी से आपके कोड को अच्छी तरह से नहीं चला सकता है। सी ++ और यहां तक कि सी की अनुमति नहीं है; आपको मिलने वाला सबसे अच्छा ओपनसीएल है, जो सी की तरह है, लेकिन कुछ बारीकियों के बिना। पुनरावृत्ति की तरह । यह सही है: GPU पर कोई पुनरावृत्ति नहीं।
डिबगिंग? ओह, मुझे आशा है कि आपको अपनी IDE की डिबगिंग सुविधाएँ पसंद नहीं हैं, क्योंकि वे निश्चित रूप से उपलब्ध नहीं होंगे। यहां तक कि अगर आप GDB का उपयोग कर रहे, चुंबन कि अलविदा। आपको printfडिबगिंग का सहारा लेना होगा ... प्रतीक्षा करें, printfGPU पर कोई नहीं है। तो आपको मेमोरी स्थानों पर लिखना होगा और अपने सीपीयू स्टब प्रोग्राम को उन्हें वापस पढ़ना होगा।
यह सही है: मैनुअल डीबगिंग। उसके साथ अच्छा भाग्य।
इसके अलावा, उन सहायक पुस्तकालयों जो आप C / C ++ में उपयोग करते हैं? या शायद आप XNA और इसके बाद के संस्करण का उपयोग कर रहे हैं। जो कुछ भी। इससे कोई फर्क नहीं पड़ता, क्योंकि आप उनमें से किसी को भी GPU पर इस्तेमाल नहीं कर सकते । आपको खरोंच से सब कुछ कोड करना होगा। और यदि आपके पास पहले से मौजूद कोडबेस है, तो कठिन: उस कोड को फिर से लिखने के लिए समय।
तो हाँ। यह वास्तव में किसी भी प्रकार के खेल के लिए भयानक है। और यह भी काम नहीं करेगा, क्योंकि खेल अभी मदद के लिए पर्याप्त समानांतर नहीं हैं।