2011-03-09 8 views
19

यह विषय, किसी भी अनुकूलन समस्या के साथ, बहुत अधिक हिट हो जाता है, लेकिन मुझे वह नहीं मिला जो मुझे लगता है (मुझे लगता है)।ओपनजीएल निम्न-स्तरीय प्रदर्शन प्रश्न

बहुत सारे ट्यूटोरियल, और यहां तक ​​कि SO प्रश्नों में समान युक्तियां हैं; आम तौर पर कवर:

  • उपयोग जीएल चेहरे को मारने (ओपन समारोह, नहीं दृश्य तर्क)
  • केवल 1 GPU (projectionModelView संयोजन) के लिए मैट्रिक्स भेजने के लिए, इसलिए मॉडल प्रति एक बार प्रति शिखर से एमवीपी गणना को कम करने (जैसा कि इसे होना चाहिए)।
  • उपयोग interleaved कोने
  • के रूप में कई के रूप में संभव जीएल कहता है, बैच को कम से कम जहां उपयुक्त हो

और संभवतः कुछ/कई अन्य। मैं (जिज्ञासा के कारण) कई वर्टेक्स बफर का उपयोग कर अपने आवेदन में 28 मिलियन त्रिकोण प्रस्तुत करता हूं। मैंने उपरोक्त सभी तकनीकों (मेरे ज्ञान के सर्वोत्तम) की कोशिश की है, और लगभग कोई प्रदर्शन परिवर्तन प्राप्त नहीं हुआ है।

जबकि मुझे अपने कार्यान्वयन में लगभग 40 एफपीएस प्राप्त हो रहा है, जो कि किसी भी तरह से समस्याग्रस्त नहीं है, मैं अभी भी उत्सुक हूं कि ये अनुकूलन 'टिप्स' वास्तव में उपयोग में आते हैं?

मेरा सीपीयू प्रतिपादन के दौरान 20-50% के आसपास आ रहा है, इसलिए मान लें मैं प्रदर्शन बढ़ाने के लिए जीपीयू बाध्य हूं।

नोट: मैं, पल

क्रॉस Game Development

उत्तर

25

प्वाइंट 1 स्पष्ट है पर तैनात पर gDEBugger में देख रहा हूँ के रूप में है बचाता भरने दर। यदि किसी ऑब्जेक्ट के बैकसाइड के प्राइमेटिव पहले संसाधित हो जाते हैं तो यह उन चेहरों को छोड़ देगा। हालांकि आधुनिक जीपीयू काफी अच्छी तरह से ओवरराइड सहन करते हैं। मैं एक बार (GeForce8800 GTX) महत्वपूर्ण प्रदर्शन हिट से पहले 20% ओवरड्रा मापा गया। लेकिन इस रिजर्व को ऑक्लुजन कूलिंग, मिश्रित ज्यामिति के प्रतिपादन और जैसे चीजों के लिए सहेजना बेहतर है।

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

प्वाइंट 3 कैश दक्षता के बारे में सब कुछ है। एक साथ जुड़े डेटा को कैश लाइन में फिट होना चाहिए।

प्वाइंट 4 कैश को तोड़ने वाले राज्य परिवर्तनों को रोकने के बारे में है। लेकिन यह दृढ़ता से निर्भर करता है कि जीएल कॉल का मतलब क्या है। बदलना वर्दी सस्ता है। एक बनावट स्विचिंग महंगा है। इसका कारण यह है कि एक वर्दी एक रजिस्टर में बैठती है, न कि स्मृति के कुछ टुकड़े जो कैश किए जाते हैं। एक शेडर को स्विच करना महंगा है, क्योंकि अलग-अलग शेडर्स अलग-अलग रनटाइम व्यवहार प्रदर्शित करते हैं, इस प्रकार पाइपलाइन निष्पादन की भविष्यवाणी को मिटाते हैं, स्मृति (और इस प्रकार) कैश एक्सेस पैटर्न को बदलते हैं और इसी तरह।

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

+0

बहुत अच्छा! धन्यवाद। –

+1

बहुत अच्छा जवाब। एक प्रश्न हालांकि, 2 बिंदु के प्रति आपकी प्रतिक्रिया में, मैं थोड़ा उलझन में हूं। मैं शेडर के अंदर "मॉडल * प्रोजेक्शन * व्यू" रखने के बीच अंतर की तुलना कर रहा था (वर्दी चर के रूप में, मॉडल मॉडल प्रत्येक बार मॉडल परिवर्तन करता है); बनाम एक वर्दी मैट्रिक्स वैरिएबल (मॉडलव्यूप्रोजेक्शन) प्रति मॉडल अपडेट किया गया है, जिसे प्रति चरम के बजाय सीपीयू द्वारा गणना की जाती है (एक बार)। निश्चित रूप से यह कई गणनाओं को बचाएगा? – dcousens

+3

@ डैनियल: आप आमतौर पर शेडर में एमवीपी मैट्रिक्स की गणना नहीं करते हैं। आप क्या करते हैं पहले गणना modelview_position = एमवी * vertex_position, और फिर clip_position = पी * modelview_position गणना कर रहा है। इसके पीछे तर्क यह है कि कुछ एल्गोरिदम के लिए आपको पूरी तरह से प्रोजेक्शन प्रक्रिया के अंतिम परिणाम न केवल मॉडलव्यू को परिवर्तित वर्टेक्स स्थिति की आवश्यकता होती है। इसके अलावा वर्टेक्स मानक केवल एमवी के व्यस्त हस्तांतरण द्वारा परिवर्तित होते हैं, पूर्ण एमवीपी^टी^-1 नहीं, इसलिए यह एक और कारण है: यदि आप अच्छी रोशनी को लागू करना चाहते हैं तो आपको उन परिवर्तनित मानदंडों की आवश्यकता है। – datenwolf

1

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

+0

वैसे मुझे लगता है कि इसे ओपनजीएल के लिए विशिष्ट कम अनुकूलन, और ग्राफिक्स प्रोग्रामिंग के लिए अच्छी (और प्रदर्शन पुरस्कृत) आदतों के साथ अधिक बारीकी से देखा जा सकता है। – dcousens

+0

वर्तमान हार्डवेयर त्वरित ग्राफिक्स पुस्तकालयों के इष्टतम उपयोग के लिए अंगूठे के कुछ सामान्य नियम होंगे: राज्य को अक्सर मत बदलें और बैच बैच बैच। ऑप्टिमाइज़ेशन के नियम हार्डवेयर की विभिन्न पीढ़ियों पर पत्थर में सेट नहीं हैं और आज क्या सच है पिछले सभी हार्डवेयर के बारे में सच नहीं था और भविष्य के हार्डवेयर के बारे में सच नहीं हो सकता है। हमेशा कैश और आपके द्वारा काम किए जा रहे हार्डवेयर की सीमाओं और ताकत की सराहना करें। – Luther

+0

जो ज्ञान मैंने सुना है वह यह है कि आपके विशिष्ट हार्डवेयर को अनुकूलित करना मूर्खतापूर्ण गेम है, क्योंकि व्यवहार हार्डवेयर पीढ़ियों या ड्राइवर संस्करणों के बीच भी मूल रूप से बदल सकता है। आप एपीआई के लिए अनुकूलन से बेहतर हैं (इस मामले में, न्यूनतम राज्य परिवर्तन जैसा कहा गया है) और हार्डवेयर को पकड़ने दें जहां आप अब अनुकूलित नहीं कर सकते हैं। – Jherico

3
  1. हाँ
  2. ड्राइवर (यह जानता है कि वे वर्दी हैं, इसलिए ड्रा कॉल के दौरान परिवर्तन नहीं होगा) आप के लिए इन मैट्रिक्स गठजोड़ कर सकते हैं के रूप में कोई मतलब नहीं है।
  3. हाँ
  4. केवल यदि आप सीपीयू बाध्य

हैं जहां वास्तव में अपने टोंटी है पहली बात आप को पता है की जरूरत है। जीपीयू एक जवाब नहीं है, क्योंकि यह एक जटिल प्रणाली है। वास्तविक समस्या इनमें से हो सकता है:

  • छायांकर्ता प्रोसेसिंग (शीर्ष/टुकड़ा/ज्यामिति)
  • भरण दर
  • ड्रा कॉल संख्या
  • GPU < -> VMEM (जो जहां इंटरलिविंग और छोटे बनावट मदद)
  • प्रणाली बस (कुछ डेटा हर फ्रेम स्ट्रीमिंग?)

आप परीक्षण की एक श्रृंखला प्रदर्शन करने के लिए समर्थक देखने की जरूरत blem। उदाहरण के लिए, यह देखने के लिए कि क्या यह एक भरने की दर समस्या है (या एमएसएए राशि बढ़ाएं) सब कुछ एक बड़े एफबीओ में खींचें। या ड्रॉ कॉल अधिभार समस्याओं को देखने के लिए सब कुछ दो बार खींचें।

+0

क्या आप थोड़ा और बता सकते हैं कि आप क्यों कहते हैं कि बैचिंग केवल तभी की जानी चाहिए जब ऐप सीपीयू बाध्य हो? – ashishsony

+0

(मूल उत्तर 2.5 साल पहले दिया गया था, इसलिए मैं याद कर रहा हूं कि मैं क्या सोच रहा था ...)। जीपीयू पक्ष पर एक कॉल और इसके 2 आधे के बीच थोड़ा अंतर होता है। यह चालक पक्ष पर कॉल की तैयारी है जो हिट लेता है, जो सीपीयू पर किया जाता है। – kvark

3

बस 2kents को @kvark और @datenwolf उत्तरों में जोड़ने के लिए, मैं यह कहना चाहूंगा कि, जब आप जिन बिंदुओं का उल्लेख करते हैं वे 'मूल' जीपीयू प्रदर्शन युक्तियाँ हैं, अधिक शामिल अनुकूलन बहुत ही आवेदन निर्भर है।

आपके ज्यामिति-भारी परीक्षण मामले में, आप पहले ही 28 मिलियन त्रिकोण * 40 एफपीएस = 1120 मिलियन त्रिकोण प्रति सेकेंड फेंक रहे हैं - यह पहले से ही काफी है: अधिकांश (सभी नहीं, एएसपी फर्मी) जीपीयू में एक है त्रिकोण सेटअप प्रति जीपीयू घड़ी चक्र के 1 त्रिकोण का प्रदर्शन। इसका मतलब है कि 800 एमएचजेड पर चलने वाला एक जीपीयू कहता है, प्रति सेकंड 800 मिलियन से अधिक त्रिकोणों को संसाधित नहीं कर सकता है; यह एक पिक्सेल ड्राइंग के बिना भी। एनवीडिया फर्मि प्रति घड़ी चक्र 4 त्रिकोणों को संसाधित कर सकता है।

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

एक और बात यह है कि छोटे त्रिकोणों को भरने में चोट लगती है क्योंकि रास्टराइज़र पिक्सेल के वर्ग ब्लॉक पर पैरारलल प्रोसेसिंग करते हैं; http://www.geeks3d.com/20101201/amd-graphics-blog-tessellation-for-all/ देखें।

+0

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

संबंधित मुद्दे