Jump to content
  • Advertisement
Sign in to follow this  
mikev

OpenGL GLSL debugger that lets you step through shader execution?

This topic is 1415 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I recently have been reading up on GDebugger which seems to be a popular and professional OpenGL debugger. While it does allow me to edit shader source code on the fly, I was really hoping for the ability to put breakpoints within my shaders, step through the shader execution, and see variable values on hover (Visual Studio style, or something similar).

 

Does anyone know any debuggers with this capability? I understand that this sort of thing would probably require some sort of GPU emulation and may perform wicked slow, but that wouldn't be a problem for debugging purposes.

 

 

In general, can people give me their general opinions on OpenGL debugging tools?

Edited by mikev

Share this post


Link to post
Share on other sites
Advertisement

If you have an Nvidia card then you can use Nsight which lets you debug graphics programs through Visual Studio. You can set breakpoints in shaders, step through, etc. Here's a demo of someone using Nsight on YouTube:

 

 

I'm not aware of anything similar for AMD or Intel though.

Share this post


Link to post
Share on other sites

Honestly, you should never need to do that anyway? I've been doing graphics for 7 years. What are you debugging? I've never had a problem that wasnt debugged by output a color value for the pixel that represents the data I'm looking at.

Share this post


Link to post
Share on other sites

Wow! That's exactly what I wanted, and I'm in luck because I have an NVidia card! :D

 

Thanks so much for pointing me to it!

Share this post


Link to post
Share on other sites

Hi dpadam450!

 

Thanks for your input, I was curious to hear if anyone had that point of view. Do you think using a debugger would actually be detrimental to growing as a graphics developer?

 

I am developing a graphics engine for my game and while I have no bugs on my hands at the moment, I have been frustrated with how time consuming debugging has been in the past. OpenGL is designed for high performance, not for easy debugging. 

 

Up to now, I have only ever done exactly what you said - dumping values to the screen. My only incentive is saving time. Time I lose writing temporary shaders/OpenGL calls whose sole purpose is to give me an onscreen picture of what has gone wrong. And sometimes a pixel picture is not always very telling. 

 

For example, you write a new technique and on your first test you see a blank screen. Dozens of questions need to be asked - is the problem an OpenGL state variable issue, a shader issue, a problem with your loaded models/textures, etc? Being able to quickly answer these questions would save me truckloads of time. I also think using a debugger and profiler could potentially improve my understanding of how to write correct and optimal OpenGL applications. 

Edited by mikev

Share this post


Link to post
Share on other sites

Do you think using a debugger would actually be detrimental to growing as a graphics developer?


Sure, the same way that using an application debugger instead of printf makes you a worse programmer.

(That's sarcasm, by the way.)

Sometimes dumping colors is the easiest way forward and can give you a _lot_ of information in a very concise and rich format that's easy to see and reason about globally across the scene. It's a tool in your toolbox and should be one you have comfort using. A GPU debugger is another powerful tool that you should _also_ be comfortable using. An event recorder is another powerful tool. No one tool supersedes all others. If you want to grow as a graphics programmer you have to learn all the tools and when to use which.

Share this post


Link to post
Share on other sites

I'm down with giving up some of my "growth as a graphics developer" for a debugger that can step through GLSL 3.30+ and works in Linux.

Edited by TheChubu

Share this post


Link to post
Share on other sites

RenderDoc is a really cool tool for DirectX by Crytek that shows you much much debugging stuff and I believe will actually let you step through shader execution.

It takes experience to learn what is going on when you have a bug. With openGL you just need to know the right way to debug it. OpenGL is a very small library that once you know whats going on, at least in my case, my bugs are solved very quickly.

With shaders though they are super tiny and you can debug the shaders apart from the state variables pretty easily. If you think there is bad data coming from somehwhere, you can hard-code variables in the shader and see what the final colors are.

The other reason you dont need to see it is there isn't crazy stuff going on. You can expect dot() to perform a dot product, if the color output from there is bad then your inputs are bad, so you just move up the chain quickly. Do you really need to see what multiplies are doing? they are multiplying...  again on my color output, your texture2d() calls either return something valid or not, so u know if its an improper bound texture.  Debugging shaders shouldn't be very hard. debugging the application side and why opengl isn't rendering anything at all is where the bulk of your problems may be.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!