25

As far as I know there are no tools that allows you to steps through code in a shader (also, in that case you would have to be able to select just a pixel/vertex you want to "debug", the execution is likely to vary depending on that). What I personally do is a very hacky "colourful debugging". So I sprinkle a bunch of dynamic branches with #if DEBUG / #...


20

Generally to see what is being rendered in the various steps of your pipeline I'd suggest the use of a tool for frame analysis. These usually provide you with a view on the content of each buffer for each API call and this can help you in your situation. A very good one is Renderdoc which is both completely free and opensource. Also it is actively supported....


11

I tested several applications/APIs/libraries to get data from FBOs in applications which use gbuffer for example. After months of suffering I discovered apitrace available on Github to debug OpenGL, Direct3D and WebGL. I used in Windows and Linux without problems. I hope that could be useful for you.


9

There is also GLSL-Debugger. It is a debugger used to be known as "GLSL Devil". The Debugger itself is super handy not only for GLSL code, but for OpenGL itself as well. You have the ability to jump between draw calls and break on Shader switches. It also shows you error messages communicated by OpenGL back to the application itself.


7

Yes, there is a better way! 😊 OpenGL 4.3 and later support the glDebugMessageCallback API, which allows you to specify a function in your app that GL will call to issue a warning or error. In this function you can do whatever you like, such as setting a breakpoint in the debugger, or printing the error to a log file. This way you only need to setup the ...


7

There are several offerings by GPU vendors like AMD's CodeXL or NVIDIA's nSight/Linux GFX Debugger which allow stepping through shaders but are tied to the respective vendor's hardware. Let me note that, although they are available under Linux, I always had very little success with using them there. I can't comment on the situation under Windows. The ...


6

In addition to cifz's response, another way to visualise FBOs which doesn't cost very much code is to use glBlitFramebuffer() to transfer pixels from a framebuffer to a window. // XXX WARNING: Untested code follows // Blit from fbo... glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo); // ...to the front buffer. glBindFramebuffer(GL_WRITE_FRAMEBUFFER, GL_FRONT); ...


5

While it doesn't seem to be possible to actually step through an OpenGL shader, it is possible to get the compilation results. The following is taken from the Android Cardboard Sample. while ((error = GLES20.glGetError()) != GLES20.GL_NO_ERROR) { Log.e(TAG, label + ": glError " + error); throw new RuntimeException(label + ": glError " + error); If ...


5

While Debug Output is good, and manual glGetError usage is adequate, it's often better to employ a more dedicated tool for finding exactly where OpenGL errors came from. RenderDoc is probably the most up-to-date tool for this process, but there are quite a few in various states of functionality. These tools can also give you a detailed log of every OpenGL ...


3

If you want to learn OpenGL X.Y or DirectX A.B then shop for hardware that supports that specification. If you're using other software (Blender, Maya, 3DSMax, etc) you'll want to make sure it's supported. If your OS has a history of issues with a particular vendor, adjust accordingly. Beyond that, it's not going to matter much, especially at the hobbyist ...


3

Assuming your code has several locations that can allocate/release GPU memory, but you don't know which one leaks. Maybe you can try to add a GPU memory monitor to that code. When GPU memory is allocated in code, insert the buffer handle that was returned, the buffer size, the function/file name (or even better, stack trace) in a globally defined array. ...


3

Probably not. Most OpenGL resources (framebuffers, vertex buffer objects, textures &c.) are controlled by host code (i.e. your C++ code), but take up GPU memory. OpenGL doesn't make it very easy to manage these resources, so it's most likely that they're being created but not deleted from your C++ code. For example, it might create a new VBO per frame ...


2

This is a copy-paste of my answer to the same question at StackOverflow. At the bottom of this answer is an example of GLSL code which allows to output the full float value as color, encoding IEEE 754 binary32. I use it like follows (this snippet gives out yy component of modelview matrix): vec4 xAsColor=toColor(gl_ModelViewMatrix[1][1]); if(bool(1)) // ...


2

This commit contains the fix of the bug. In short, it is wrong to disable event for second edge, during event checking, when first edge may be truncated sooner then stated by its current associated event.


1

If you can't go to OpenGL 4.3 (or your implementation doesn't support glDebugMessageCallbacks), you can simplify your code in a number of ways. The first is to move the calls to glGetError() into a function like this: void checkGLError() { GLenum err; while( !(err = glGetError()) ){ std::cout << err; } } That reduces your code ...


1

The solution that worked for me is compilation of shader code to C++ - as mentioned by Nobody. It prooved very efficient when working on a complex code even though it requires a bit of setup. I have been working mostly with HLSL Compute Shaders for which I have developed a proof-of-concept library available here: https://github.com/cezbloch/shaderator It ...


Only top voted, non community-wiki answers of a minimum length are eligible