I think it would be useful to have a debugging tool for shaders. MS has made something (I forgot the details) to be able to debug shaders in Visual C++.NET which is good enough for them.
For GL a stand alone tool or one that could be plugged in to RenderMonkey. I’m not sure how it would work, since input is necessary.
It should be possible to spy on any variable and be able to step through it.
A special software renderer should not be used (unlike MS’s solution) because I want to know when the hardware will screw up.
I might need to run several “similar” shaders in parallel to see which one avoids the problem.
As for the input, perhaps random input could be sent or perhaps we could at least choose the primitive type.
What do others think?
If you can wait a while the next version of GLIntercept should include a shader debugger (for ARB VP/FP and GLSL)
OK, I’ll check it out when it’s ready.
But I think you would have to make some drastic changes, no?
I our next Shader Suite solution (codename SD2.0) we’ve planned a software GLSL debugger, but is a very hard task, so will take some time…
Hey, it’s good that someone is doing work in this direction. But last time I ran shader designer it was crashing.
There is a way to do the debugging manually.
Port the shader to a C/C++ compiler. Run it with test values values and use the standard debugger.
The ran the shader and output to a float buffer and read back.
And finally, compare.
Of course this is a way, yes, but for a product, it’s better don’t depend on having installed a compiler. I could see hundreds of mails telling us: “Why do I need install a huge compiler to run your application?”
We are working on a standalone product, we won’t depend on gcc (or another free compiler) to do such tasks. But this is a big task…
V-Man - Check out the GLIntercept thread in the advanced forum for the GLIntercept shader editor.