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

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

glGetError ()

जब आप OpenGL का गलत तरीके से उपयोग करते हैं (उदाहरण के लिए, जब आप एक बफर सेट करते हैं और इसे बांधना भूल जाते हैं), तो OpenGL नोटिस करेगा और दृश्यों के पीछे एक या अधिक कस्टम त्रुटि झंडे बनाएगा। हम glGetError() फ़ंक्शन को कॉल करके इन त्रुटियों को ट्रैक कर सकते हैं, जो बस त्रुटि झंडे सेट की जांच करता है और त्रुटियां होने पर त्रुटि मान लौटाता है।

 GLenum glGetError(); 

यह फ़ंक्शन एक त्रुटि ध्वज या कोई त्रुटि बिल्कुल नहीं देता है। वापसी मान सूची:

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

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

 glBindTexture(GL_TEXTURE_2D, tex); std::cout << glGetError() << std::endl; //  0 ( ) glTexImage2D(GL_TEXTURE_3D, 0, GL_RGB, 512, 512, 0, GL_RGB, GL_UNSIGNED_BYTE, data); std::cout << glGetError() << std::endl; //  1280 ( ) glGenTextures(-5, textures); std::cout << glGetError() << std::endl; //  1281 (  std::cout << glGetError() << std::endl; //  0 ( ) 

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

 GLenum glCheckError_(const char *file, int line) { GLenum errorCode; while ((errorCode = glGetError()) != GL_NO_ERROR) { std::string error; switch (errorCode) { case GL_INVALID_ENUM: error = "INVALID_ENUM"; break; case GL_INVALID_VALUE: error = "INVALID_VALUE"; break; case GL_INVALID_OPERATION: error = "INVALID_OPERATION"; break; case GL_STACK_OVERFLOW: error = "STACK_OVERFLOW"; break; case GL_STACK_UNDERFLOW: error = "STACK_UNDERFLOW"; break; case GL_OUT_OF_MEMORY: error = "OUT_OF_MEMORY"; break; case GL_INVALID_FRAMEBUFFER_OPERATION: error = "INVALID_FRAMEBUFFER_OPERATION"; break; } std::cout << error << " | " << file << " (" << line << ")" << std::endl; } return errorCode; } #define glCheckError() glCheckError_(__FILE__, __LINE__) 

यदि आप अधिक glCheckError कॉल करने का निर्णय लेते हैं, तो यह जानना उपयोगी होगा कि त्रुटि कहां हुई।

 glBindBuffer(GL_VERTEX_ARRAY, vbo); glCheckError(); 

निष्कर्ष:

एक महत्वपूर्ण बात बनी हुई है: GLEW में एक लंबा-चौड़ा बग है: glewInit() हमेशा GL_INVALID_ENUM ध्वज सेट करता है। इसे ठीक करने के लिए, केवल ध्वज को हटाने के लिए glGetError बाद glewInit को कॉल करें:

 glewInit(); glGetError(); 

glGetError ज्यादा मदद नहीं करता है, क्योंकि दी गई जानकारी अपेक्षाकृत सरल है, लेकिन यह अक्सर glGetError को पकड़ने या उस जगह को पकड़ने में मदद करता है जहां त्रुटि हुई थी। यह एक सरल लेकिन प्रभावी डिबगिंग टूल है।

डिबग आउटपुट

टूल कम प्रसिद्ध है, लेकिन glCheckError तुलना में अधिक उपयोगी है, OpenGL एक्सटेंशन "डिबग आउटपुट", जो OpenGL 4.3 कोर प्रोफाइल में शामिल था। इस एक्सटेंशन के साथ, OpenGL उपयोगकर्ता को त्रुटि के विवरण के साथ एक त्रुटि संदेश भेजेगा। यह एक्सटेंशन न केवल अधिक जानकारी प्रदान करता है, बल्कि आपको उन त्रुटियों को भी पकड़ने की अनुमति देता है जहां वे डीबगर का उपयोग करते हैं।

डीबग आउटपुट ओपन 4.3 संस्करण के साथ शुरू होने वाले ओपन में शामिल है, जिसका अर्थ है कि आप किसी भी मशीन पर यह कार्यक्षमता पाएंगे जो ओपन 5 4.3 और उच्चतर का समर्थन करता है। यदि यह संस्करण उपलब्ध नहीं है, तो आप ARB_debug_output और AMD_debug_output एक्सटेंशन की जांच कर सकते हैं। इस बात की भी असत्यापित जानकारी है कि डिबगिंग आउटपुट OS X पर समर्थित नहीं है (मूल के लेखक और अनुवादक ने परीक्षण नहीं किया है, कृपया त्रुटि सुधार तंत्र के माध्यम से मूल के लेखक को या मुझे निजी संदेशों में सूचित करें, यदि आपको इस तथ्य की पुष्टि या खंडन मिलता है; UPD: Jeka178RUS ने यह जाँच की है; तथ्य: बॉक्स से बाहर, डिबग आउटपुट काम नहीं करता है, उसने एक्सटेंशन के माध्यम से जांच नहीं की)।

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

GLFW में डिबग आउटपुट

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

 glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GL_TRUE); 

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

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

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

 GLint flags; glGetIntegerv(GL_CONTEXT_FLAGS, &flags); if (flags & GL_CONTEXT_FLAG_DEBUG_BIT) { //  } else { //   } 

डिबग आउटपुट कैसे काम करता है? हम OpenGL में एक संदेश हैंडलर को कॉलबैक फ़ंक्शन देते हैं (GLFW में कॉलबैक के समान) और इस फ़ंक्शन में हम OpenGL डेटा को संसाधित कर सकते हैं, जैसा कि हम चाहते हैं, हमारे मामले में कंसोल को उपयोगी त्रुटि संदेश भेजते हैं। इस फ़ंक्शन का प्रोटोटाइप:

 void APIENTRY glDebugOutput(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar *message, void *userParam); 

ध्यान दें कि कुछ ऑपरेटिंग सिस्टम पर अंतिम पैरामीटर का प्रकार const void* हो सकता है।
हमारे पास मौजूद बड़े डेटा सेट को देखते हुए, हम एक उपयोगी एरर प्रिंटिंग टूल बना सकते हैं, जैसा कि नीचे दिखाया गया है:

 void APIENTRY glDebugOutput(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar *message, void *userParam) { // ignore non-significant error/warning codes if(id == 131169 || id == 131185 || id == 131218 || id == 131204) return; std::cout << "---------------" << std::endl; std::cout << "Debug message (" << id << "): " << message << std::endl; switch (source) { case GL_DEBUG_SOURCE_API: std::cout << "Source: API"; break; case GL_DEBUG_SOURCE_WINDOW_SYSTEM: std::cout << "Source: Window System"; break; case GL_DEBUG_SOURCE_SHADER_COMPILER: std::cout << "Source: Shader Compiler"; break; case GL_DEBUG_SOURCE_THIRD_PARTY: std::cout << "Source: Third Party"; break; case GL_DEBUG_SOURCE_APPLICATION: std::cout << "Source: Application"; break; case GL_DEBUG_SOURCE_OTHER: std::cout << "Source: Other"; break; } std::cout << std::endl; switch (type) { case GL_DEBUG_TYPE_ERROR: std::cout << "Type: Error"; break; case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR: std::cout << "Type: Deprecated Behaviour"; break; case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR: std::cout << "Type: Undefined Behaviour"; break; case GL_DEBUG_TYPE_PORTABILITY: std::cout << "Type: Portability"; break; case GL_DEBUG_TYPE_PERFORMANCE: std::cout << "Type: Performance"; break; case GL_DEBUG_TYPE_MARKER: std::cout << "Type: Marker"; break; case GL_DEBUG_TYPE_PUSH_GROUP: std::cout << "Type: Push Group"; break; case GL_DEBUG_TYPE_POP_GROUP: std::cout << "Type: Pop Group"; break; case GL_DEBUG_TYPE_OTHER: std::cout << "Type: Other"; break; } std::cout << std::endl; switch (severity) { case GL_DEBUG_SEVERITY_HIGH: std::cout << "Severity: high"; break; case GL_DEBUG_SEVERITY_MEDIUM: std::cout << "Severity: medium"; break; case GL_DEBUG_SEVERITY_LOW: std::cout << "Severity: low"; break; case GL_DEBUG_SEVERITY_NOTIFICATION: std::cout << "Severity: notification"; break; } std::cout << std::endl; std::cout << std::endl; } 

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

 if (flags & GL_CONTEXT_FLAG_DEBUG_BIT) { glEnable(GL_DEBUG_OUTPUT); glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS); glDebugMessageCallback(glDebugOutput, nullptr); glDebugMessageControl(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, nullptr, GL_TRUE); } 

इसलिए हम OpenGL को बताते हैं कि हम डिबग आउटपुट सक्षम करना चाहते हैं। glEnable(GL_DEBUG_SYNCRHONOUS) को कॉल ओपनजीएल को बताता है कि हम एक त्रुटि संदेश चाहते हैं जब यह हुआ।

डिबग आउटपुट फ़िल्टरिंग

glDebugMessageControl फ़ंक्शन के साथ glDebugMessageControl आप उन त्रुटियों के प्रकारों का चयन कर सकते हैं जिन्हें आप प्राप्त करना चाहते हैं। हमारे मामले में, हमें सभी प्रकार की त्रुटियाँ मिलती हैं। यदि हम केवल OpenGL API त्रुटियों को चाहते थे, जैसे त्रुटि और महत्व स्तर उच्च, तो हम निम्नलिखित कोड लिखेंगे:

 glDebugMessageControl(GL_DEBUG_SOURCE_API, GL_DEBUG_TYPE_ERROR, GL_DEBUG_SEVERITY_HIGH, 0, nullptr, GL_TRUE); 

इस कॉन्फ़िगरेशन और डिबगिंग संदर्भ के साथ, हर गलत OpenGL कमांड बहुत सारी उपयोगी जानकारी भेजेगा:

कॉल स्टैक के माध्यम से त्रुटि के स्रोत का पता लगाएं

डिबगिंग आउटपुट के साथ एक और चाल यह है कि आप अपने कोड में त्रुटि के सटीक स्थान को आसानी से स्थापित कर सकते हैं। वांछित प्रकार की त्रुटि (या फ़ंक्शन की शुरुआत में यदि आप सभी त्रुटियों को पकड़ना चाहते हैं) पर DebugOutput फ़ंक्शन में एक ब्रेकपॉइंट सेट करके, डिबगर त्रुटि को पकड़ लेगा और आप यह पता लगाने के लिए कॉल स्टैक नेविगेट कर सकते हैं कि त्रुटि कहां हुई:

इसके लिए कुछ मैनुअल हस्तक्षेप की आवश्यकता होती है, लेकिन यदि आप मोटे तौर पर जानते हैं कि आप क्या देख रहे हैं, तो यह जल्दी से निर्धारित करने के लिए अविश्वसनीय रूप से उपयोगी है कि कौन सी कॉल त्रुटि का कारण बन रही है।

खुद की गलतियाँ

पढ़ने की त्रुटियों के साथ, हम उन्हें glDebugMessageInsert का उपयोग करके डिबग आउटपुट सिस्टम में भेज सकते हैं:

 glDebugMessageInsert(GL_DEBUG_SOURCE_APPLICATION, GL_DEBUG_TYPE_ERROR, 0, GL_DEBUG_SEVERITY_MEDIUM, -1, "error message here"); 

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

शेडर डीबग आउटपुट

जब यह GLSL की बात आती है, तो हमारे पास glGetError या डिबगर में चरणों में कोड के माध्यम से चलने की क्षमता जैसे कार्यों तक पहुंच नहीं है। जब आप एक काली स्क्रीन या पूरी तरह से गलत प्रदर्शन का सामना करते हैं, तो यह समझना बहुत मुश्किल हो सकता है कि क्या समस्या है, तो क्या हो सकता है। हां, संकलन त्रुटियां सिंटैक्स त्रुटियों की रिपोर्ट करती हैं, लेकिन सिमेंटिक त्रुटियों को पकड़ना वह गीत है।
एक shader के साथ क्या गलत है, यह पता लगाने के लिए आमतौर पर उपयोग किए जाने वाले तरीकों में से एक shader प्रोग्राम में सभी संबंधित चर को सीधे भेजने के लिए है, जो टुकड़े टुकड़े shader के आउटपुट चैनल के लिए है। रंगों के साथ सीधे उत्पादन चैनल में shader वेरिएबल्स को आउटपुट करके, हम आउटपुट पर चित्र की जांच करके दिलचस्प जानकारी प्राप्त कर सकते हैं। उदाहरण के लिए, हमें यह पता लगाने की आवश्यकता है कि क्या मॉडल के लिए मानदंड सही हैं। हम उन्हें (रूपांतरित या नहीं) शीर्ष से खंड टुकड़े में भेज सकते हैं, जहां हम मानदंडों को कुछ इस तरह प्राप्त करते हैं:
(नोट लेन: GLSL के लिए कोई सिंटैक्स हाइलाइटिंग क्यों नहीं है?)

 #version 330 core out vec4 FragColor; in vec3 Normal; [...] void main() { [...] FragColor.rgb = Normal; FragColor.a = 1.0f; } 

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

दृश्य परिणामों से, हम देख सकते हैं कि मानदंड सही हैं, क्योंकि सूट के दाईं ओर मुख्य रूप से लाल है (जिसका अर्थ है कि मानदंड मोटे तौर पर कुल्हाड़ी एक्स अक्ष की दिशा में दिखाते हैं) और सूट के सामने का भाग भी सकारात्मक z अक्ष (नीला) की दिशा में रंगीन है।

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

ओपन जीएलएसएल संदर्भ संकलक

प्रत्येक वीडियो ड्राइवर की अपनी क्विरक्स होती हैं। उदाहरण के लिए, NVIDIA ड्राइवर विनिर्देश की आवश्यकताओं को थोड़ा नरम करते हैं, और एएमडी चालक विनिर्देशों को बेहतर तरीके से पूरा करते हैं (जो बेहतर है, यह मुझे लगता है)। समस्या यह है कि एक मशीन पर चलने वाले शेड ड्राइवरों में अंतर के कारण दूसरे पर पैसा नहीं कमा सकते हैं।

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

इस कार्यक्रम के साथ, आप अपने शेडर्स को कार्यक्रम के 1 तर्क के रूप में पास करके परीक्षण कर सकते हैं। याद रखें कि कार्यक्रम एक्सटेंशन द्वारा शेडर के प्रकार को निर्धारित करता है:

• .vert : वर्टेक्स शेडर
• .frag : टुकड़े टुकड़े करना
• .geom : ज्यामितीय shader
• .tesc : .tesc नियंत्रित करने वाला शेडर
• .tese : .tese कंप्यूटिंग शेडर
• .comp : गणना करने वाला

कार्यक्रम चलाना आसान है:

 glslangValidator shader.vert 

ध्यान दें कि यदि कोई त्रुटि नहीं है, तो प्रोग्राम कुछ भी आउटपुट नहीं करेगा। एक टूटी हुई चोटी की छाया पर, आउटपुट जैसा दिखेगा:

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

फ्रेम बफर आउटपुट

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

ध्यान दें कि फ्रेम बफर की सामग्री, जैसा कि यहां बताया गया है, बनावट के साथ काम करते हैं, न कि ड्राइंग बफ़र्स में वस्तुओं के साथ

एक साधारण बनावट का उपयोग करके जो एक एकल बनावट को खींचता है, हम एक छोटे से फ़ंक्शन को लिख सकते हैं जो स्क्रीन के ऊपरी दाएं कोने में किसी भी बनावट को जल्दी से खींचता है:

 // vertex shader #version 330 core layout (location = 0) in vec2 position; layout (location = 1) in vec2 texCoords; out vec2 TexCoords; void main() { gl_Position = vec4(position, 0.0f, 1.0f); TexCoords = texCoords; } 

 //fragment shader #version 330 core out vec4 FragColor; in vec2 TexCoords; uniform sampler2D fboAttachment; void main() { FragColor = texture(fboAttachment, TexCoords); } 

 //main.cpp void DisplayFramebufferTexture(GLuint textureID) { if(!notInitialized) { // initialize shader and vao w/ NDC vertex coordinates at top-right of the screen [...] } glActiveTexture(GL_TEXTURE0); glUseProgram(shaderDisplayFBOOutput); glBindTexture(GL_TEXTURE_2D, textureID); glBindVertexArray(vaoDebugTexturedRect); glDrawArrays(GL_TRIANGLES, 0, 6); glBindVertexArray(0); glUseProgram(0); } int main() { [...] while (!glfwWindowShouldClose(window)) { [...] DisplayFramebufferTexture(fboAttachment0); glfwSwapBuffers(window); } } 

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

आप इस फ़ंक्शन का विस्तार भी कर सकते हैं ताकि यह 1 से अधिक बनावट प्रदान करे। यह फ्रेम बफ़र्स में किसी भी चीज़ से लगातार प्रतिक्रिया प्राप्त करने का एक त्वरित तरीका है।

बाहरी डिबगर प्रोग्राम

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

मैंने कई लोकप्रिय उपकरण सूचीबद्ध किए हैं। हर एक को आज़माएं और जो आपको सबसे अच्छा लगे उसे चुनें।

RenderDoc

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

CodeXL

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

मैंने कोडएक्सएल का अधिक उपयोग नहीं किया, क्योंकि रेंडरडॉक मुझे आसान लग रहा था, लेकिन मैंने इस सूची में कोडएक्सएल को शामिल किया क्योंकि यह एक बहुत विश्वसनीय उपकरण की तरह दिखता है और मुख्य रूप से GPU के सबसे बड़े निर्माताओं में से एक द्वारा विकसित किया गया है।

NVIDIA श्वेत

Nsight एक लोकप्रिय NUedia GPU डिबगिंग टूल है। यह न केवल दृश्य स्टूडियो और ग्रहण के लिए प्लग-इन है, बल्कि एक अलग एप्लिकेशन भी है। ग्राफिक डेवलपर्स के लिए Nsight प्लगइन एक बहुत ही उपयोगी चीज है क्योंकि यह GPU के उपयोग और GPU के फ्रेम-बाय-फ्रेम राज्य के बारे में बहुत सारे वास्तविक समय के आँकड़े एकत्र करता है।

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

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

, ( , VOGL APItrace ), , . , , () ( , ).

• ? — Reto Koradi.
• — Vallentin Source.

पुनश्च : हमारे पास तबादलों के समन्वय के लिए एक तार है । यदि आपको अनुवाद में मदद करने की गंभीर इच्छा है, तो आपका स्वागत है!