2012-01-13 15 views
6

के साथ चिकना चल रहा है क्या आपने एक परिस्थिति का अनुभव किया है, जहां दृश्य स्टूडियो से निष्पादित होने पर सी ++ ओपनगल एप्लिकेशन तेजी से चल रहा है और चिकना चल रहा है? जब सामान्य रूप से डीबगर के बिना निष्पादित किया जाता है, तो मुझे कम फ्रेमरेट मिलता है, 80 के बजाय 50, और एक अजीब लग रहा है, जहां एफपीएस हर 20-30 वें फ्रेम के बारे में 25 फ्रेम/सेकंड तक डाइविंग कर रहा है। क्या इसे ठीक करने का कोई तरीका है?सी ++/ओपनजीएल अनुप्रयोग डीबगर संलग्न

संपादित करें: इसके अलावा हम कई डिस्प्ले सूचियां (glNewList के साथ बनाई गई) का उपयोग कर रहे हैं। और प्रदर्शन सूचियों की संख्या में वृद्धि लग रहा है लग रहा है।

संपादित करें: समस्या पृष्ठ त्रुटियों के कारण होती है। SetProcessWorkingSetSizeEx() के साथ काम कर रहे प्रक्रिया समायोजित करने में मदद नहीं करता है।

संपादित: कुछ बड़े मॉडलों समस्या procexp-उपयोगिता के GPU-स्मृति के उपयोग के साथ का पता आसानी से है के साथ। प्रति फ्रेम कई glCallList-call हैं जब मेमोरी उपयोग बहुत अस्थिर है। कोई नई ज्यामिति नहीं जोड़ा गया है, कोई बनावट लोड नहीं हुई है, लेकिन जीपीयू-मेमोरी-आवंटन + -20 एमबाइट्स में उतार-चढ़ाव करता है। थोड़ी देर के बाद यह और भी बदतर हो जाता है, और एक बार में 150 एमबी की तरह कुछ आवंटित कर सकता है।

+0

क्या आप पूर्ण स्क्रीन चला रहे हैं, डीबगर में पूर्ण स्क्रीन में नहीं बना रहे हैं? इससे वी-सिंक सक्षम हो जाएगा। – stonemetal

+0

पूर्णस्क्रीन नहीं है, लेकिन अधिकतम। दोनों मामलों में वी-सिंक अक्षम होना चाहिए। कभी-कभी मुझे 100 से अधिक एफपीएस-दर मिलती है, और अभी भी लगी हुई है। – AareP

+0

आपको प्रोसेस एक्सप्लोरर जैसे कुछ का उपयोग करना चाहिए ताकि यह देखने के लिए कि दोनों डीएलएल दोनों मामलों में लोड हो जाएं और यदि डीएलएल को differenc पथ – PeterT

उत्तर

0

शायद यह धागा या प्रक्रिया प्राथमिकता है। डीबगर उत्तरदायी है यह सुनिश्चित करने के लिए विजुअल स्टूडियो आपकी प्रक्रिया को थोड़ा अधिक प्राथमिकता के साथ लॉन्च कर सकता है। अपने ऐप्लिकेशन के कोड में SetPriorityClass() उपयोग करके देखें:

SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS); 

वर्ग 'सामान्य से सिर्फ यह' सामान्य 'वर्ग के साथ सब कुछ से आगे लेकर जाता है। जैसा कि प्रलेखन कहता है, सुपर उच्च प्राथमिकता पर थप्पड़ न लगाएं या आप सिस्टम के शेड्यूलर को खराब कर सकते हैं।

60 एफपीएस पर चल रहे एक ऐप में आपको केवल फ्रेम बनाने के लिए 16 मिमी मिलते हैं (80 एफपीएस पर कम!) - यदि इसमें अधिक समय लगता है तो आप फ्रेम को छोड़ दें जो फ्रेमरेट में एक छोटी डुबकी पैदा कर सकता है। यदि आपके ऐप की अन्य प्राथमिकताओं के समान प्राथमिकता है, तो अपेक्षाकृत संभावना है कि एक और ऐप अस्थायी रूप से कुछ कार्य के लिए सीपीयू चुरा सकता है और आप कुछ फ्रेम छोड़ देते हैं या कम से कम अपनी 16 एमएस विंडो को मौजूदा फ्रेम के लिए याद करते हैं। विचार प्राथमिकता को थोड़ा बढ़ा रहा है इसका मतलब है कि विंडोज आपके ऐप पर अक्सर वापस आ जाता है, इसलिए यह कई फ्रेम नहीं छोड़ता है।

+0

उचित लगता है, लेकिन डीबग/रिलीज़ संस्करणों के बीच प्रदर्शन अंतर के साथ आपके उत्तर का क्या संबंध है? –

+0

मदद नहीं की। दृश्य स्टूडियो से अलग से निष्पादित करते समय एफपीएस दर अभी भी "अस्थिर" है।बीटीडब्ल्यू मैं हमेशा रिलीज संस्करण का उपयोग कर रहा हूं, लेकिन दृश्य स्टूडियो या सामान्य रूप से निष्पादित करता हूं। – AareP

+0

SetProcessPriorityBoost भी बदलना मदद नहीं करता है। – AareP

3

मेरा मानना ​​है कि जो कुछ आप देख रहे हैं वह कुछ पृष्ठों को लॉक करने वाला डीबगर है ताकि उन्हें डीबगर के तुरंत बाद पहुंचने के लिए स्वैप नहीं किया जा सके। यह प्रक्रिया स्विचिंग के समय ओएस के लिए कुछ चेतावनियां लाता है और सामान्य रूप से, पुन: अनुमोदित नहीं होता है।

शायद आप मुझे यह कहना नहीं सुनेंगे, लेकिन इसे ठीक करने का कोई अच्छा तरीका नहीं है, भले ही आप ऐसा करते हों।

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

2

क्या आपके पास किसी भी मौके से एनवीडिया ग्राफिक्स कार्ड है? डीवीगर से जुड़े होने पर एनवीडिया ओपनजीएल एक अलग कार्यान्वयन का उपयोग करता प्रतीत होता है। मेरे लिए, गैर-डीबगर संस्करण कुछ स्थितियों में 1 एमबी/सेकेंड तक मेमोरी लीक कर रहा है जहां मैं फ्रंट बफर पर आकर्षित करता हूं और प्रत्येक फ्रेम को ग्लक्लेयर नहीं कहता हूं। डीबगर संस्करण बिल्कुल ठीक है।

मुझे नहीं पता कि इसे आवंटित करने की आवश्यकता क्यों है और (कभी-कभी) उस दृश्य के लिए इतनी मेमोरी को हटा दिया जाता है जो बदल नहीं रहा है।

और मैं प्रदर्शन सूचियों का उपयोग नहीं कर रहा हूं।

+0

धन्यवाद! मैं पुष्टि करता हूं कि कुछ स्थितियों के तहत रिलीज और डीबग संस्करणों के बीच एनवीडिया ओपनजीएल ड्राइवरों के पास पर्याप्त प्रदर्शन अंतर (x100) है। मेरे पास एक ओपनजीएल प्रोजेक्ट था जो स्किन किए गए एनिमेशन का इस्तेमाल करता था और यह दो अलग-अलग एनवीडिया आधारित विंडोज मशीनों पर .4 एफपीएस पर चलाएगा। हालांकि यह परियोजना एएमडी मशीनों पर या मेरे मैकबुक के एनवीडिया हार्डवेयर पर लगभग 30 एफपीएस पर चलती है। हालांकि विंडोज़/एनवीडिया मशीनों पर अगर मैंने यूनिटी के प्रोफाइलर विंडो के साथ प्रोजेक्ट चलाया तो यह ओपनजीएल डीबग टूल के माध्यम से स्टैंडअलोन चलाएगा, और अगर मैं 30 एफपीएस पर भी चलाऊंगा तो यह खुल जाएगा। –

+0

@RiazRizvi मुझे वर्तमान में इसी तरह के मुद्दों का सामना करना पड़ रहा है और यह सोच रहा था कि आप किस ओपनजीएल डीबग टूल का उपयोग कर रहे थे? – ShinNoNoir

+0

यह थोड़ी देर पहले था, लेकिन मुझे लगता है कि यह यह मुफ्त था https://www.opengl.org/sdk/tools/gDEBugger/। मेरा निष्कर्ष यह था कि डिबग के लिए बनाया गया विंडो का ओपनजीएल डीएलएल, डिबग टूल के माध्यम से प्रोजेक्ट चलाने के बाद, ओपनजीएल ड्राइवरों के डीबग संस्करणों को लोड करने के कारण, स्किन किए गए एनिमेशन के लिए रिलीज़ संस्करण से बेहतर प्रदर्शन करता है। फिर भी यह दो साल पहले था - यकीन नहीं है कि यह अभी भी मामला है। –

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