GLSL debugger that lets you step through shader execution?

Started by
9 comments, last by Kaptein 9 years, 6 months ago

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?

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.

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.

NBA2K, Madden, Maneater, Killing Floor, Sims http://www.pawlowskipinball.com/pinballeternal

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!

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.

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.

Sean Middleditch – Game Systems Engineer – Join my team!

What do you mean by an event recorder?

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.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

@TheChubu - Hahahaha...

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.

NBA2K, Madden, Maneater, Killing Floor, Sims http://www.pawlowskipinball.com/pinballeternal

This topic is closed to new replies.

Advertisement