Would you use shader debugging if it was available?

[_michal]

Would you?
The GLSL development in Mesa 3-D is going to be finished in a matter of one, maybe two months.
I realize that it wont be super-fast, but would you use Mesa to develop shaders if it had a nice extension allowing third-party apps execute the shader's code step-by-step and watch variables contents in between?
If yes, what functionality would you expect it to have?

[ZbuffeR]

Great !
A software implementation of GLSL would be great to run shaders without risking crashing the machine because of beta drivers, allowing to debug code, trace variables values, etc.

I would really like ability to step through a pixel shader on a user selected pixel.

Would be cool to add such features right in ShaderDesigner !

[dorbie]

Other stuff that's not explicitly used in a shader for example screen x & y will probably be of interest.

[sqrt[-1]]

Wow... just Wow, I never expected Mesa to implement GLSL...

If I had to choos a debug API this is kinda what I would want:

glShaderDebugBegin(GLenum shadertype, uint programID);
//Resets the debug state and begins the debugging, All standard GL calls are invalid between the Begin/End();

void glSetShaderDebugValue(GLenum variable_Type, T value);
//Sets variables for the debug state (ie. the current processing vertex for vertex shaders/ the current pixel coordinate for fragment shaders)

glShaderDebugDrawElements(...)
// Same as glDrawElements?Range? but does no rendering, will progress through shaders a line at a time on calls to glGetShaderDebugNextLine();
// Must have the debug vertex number or pixel coordinate before this is called
// All render calls between a shader debug section does not actually 'render', they are just called for debugging.
//(This is so we can debug the shader multiple times without worring about if the frame buffers have changed etc)

GLint glGetShaderDebugNextLine();
//Gets the next line number that the shader is currently up to. This is expected to be called continuiously until -1 is returned. (when the shader is complete or data is not set)

void glGetShaderDebugValue(GLenum variable_type, T *retValue);
//Gets info from the debug state. Similar values like the GLSL query interface. Values to:
// - Get the number of active variables
// - Get active variable x's type
// - Get active variable x's value

glShaderDebugEnd(); //Ends the debug state

Psudo example usage:

//Start debugging program 1's vertex shader
glShaderDebugBegin(GL_VERTEX_SHADER, 1);
 
//Debug vertex number 10
glSetShaderDebugValuei(GL_SD_VERTEX_NUMBER, 10); 
 
//Dummy render start
glShaderDebugDrawElements(GL_TRIANGLES, 20, GL_UNSIGNED_SHORT, indices);
 
//Loop while still on a valid line
int currLine = glGetShaderDebugNextLine();
while(currLine  != -1)
{
  //If the line is a line with a breakpoint
  if(IsBreakPointLine(currLine))
  {
    //Get the number of active variables
    GLuint numVars=0;
    glGetShaderDebugValuei(GL_SD_NUM_ACTIVE_VARIABLES, &numVars)
 
    //Loop for all active variables
    for(uint i=0; i<numVars; i++)
    {
      //Get variable type
      glGetShaderDebugValue(...);
 
      //Get variable value
      glGetShaderDebugValue(...);
    }
 
    //Update UI with new values (does not return until user gotos next line)
    UpdateDebugUI(...):
  }
 
  //Get the next line  
  currLine = glGetShaderDebugNextLine();
}
 
glShaderDebugEnd();

[Ffelagund]

Hello,
I'm the author of the Shader Designer, and I have one or two thing to say about this topic. First, I must apologize, because I said that Shader Designer (or it's successor) will have in the near future a GLSL debugger. Well, currently we can't write the debugger for the Shader Designer. It is a very BIG task for only two guys (I'm not looking for more people to work in) that work for free. As said in another thread, we've already started the successor of the Shader Designer (will be a commercial tool), and the debugger module will have to wait until we convince some investors that our product worths (we want to live of our products, that's why we've created TyphoonLabs), but the announcement of the MESA debugger will change a bit our plans

But we will be very pleased to include a software path for GL rendering in the Shader Designer in order to include the MESA's GLSL debugger, when be finished, and we offer our collaboration to MESA GLSL dev team to help in the debugger design/implementation.

[_michal]

Here you can find proposed spec for vertex and fragment program debugging.
This model introduces callbacks to simplify IHV's implementation. ISVs can in the callback query various GL state.

Sqrt's solution is very handy I must say. One can imagine a debugger that in the first step redners one frame of animation and then allows user to select a particular vertex or pixel and execute it step-by-step. Although exporting all the possible combinations of render calls (DrawElements, DrawArrays, etc.) might not be such a good idea.

Maybe Im wrong, but I am thinking more about an API that allows you quickly add one call here and here and inspect your broken app. No need to replace existing render calls, just add some enable (glEnable (GL_SHADER_DEBUG)?), some query functions (for getting and setting intermediate values) and you are ready to go.

Im open for suggestions.

[sqrt[-1]]

OK, just so you know where I am comming from, I develop GLIntercept and the debugger interface I had in mind was:
- Let app run normally
- User opens the run-time shader editor
- If user adds a breakpoint(with a specific pixel/vertex number), break and create a Mesa offscreen surface and copy all relevant GL states.
- Debug using mesa.
- Any edits get compiled back into main app(as currently happens) and Mesa gets a new copy. (kinda like edit-and-continue debugging)
- Let app continue

Using the suggestions in the above post, you don't have to have a new render function(s) (you could use the existing ones and detect when in a ShaderDebugBegin/End statement - I just though it might be simplier to implement for you if there were only specific render calls)

I would also be happy with a glEnable/Disable GL_FRAGMENT/VERTEX_DEBUG switch instead of the Begin/End. (Which would do essentially the same thing. )

An addition to the above "spec" of mine. It would be nice to query if a line position is valid for the current debug . (ie. boolean IsShaderDebugLineValid(GLuint lineNum); as a lot of lines may not be valid to add a breakpoint to - whitespace/preprocessor stuff/ formatting etc )

Looking at that old spec, I could live with someting like it (as long as you added vertex/pixel location selection) but I do feel my design is a bit more GLish as it does not have callbacks. (Would callbacks be a problem in non-C languages?)

Also from the old spec, is changing values while debugging going to be out of the question?

But at the end of the day, you are implementing it (and it is not a core OpenGL feature) so as long as it is reliable, I should be happy.

[V-man]

sqrt suggestion is good because we need to be able to track vertices and fragments.

Adding glGetCurrentLine(char *thisline)
would be nice so that I can immediatly see the line.

For fragment debugging we can send GL_POINTS I suppose.

Has MESA_program_debug been implemented? How do people feel using it?

[_michal]

Originally posted by V-man:
[...]
Has MESA_program_debug been implemented? How do people feel using it?

Im affraid it wasnt fully implemented. This spec is not even listed on the mesa's home page, it is hidden.

Brian enhanced NV programs with PRINT instruction which basicly allow you to spit diagnostic messages in conjunction with selected register.

I dont know why program_debug wasnt finished. Maybe it is because today you can buy gfx card for $50 and run programs smoothly (unlike software solutions). A developer, if he/she has a problem with a shader, just writes the intermediate results to fragment color and watches the screen.

Maybe todays shaders are so simple that they dont need debuggers yet. And that means it is a matter of time to feel the need for a debugger.

[kingjosh]

Michal,

I would have to respectfully disagree. Shaders are quickly getting more complicated, and a debugger would be a great help to today's developers. Shaders are destined to get even more complicated as hardware improves, so this is definitely something that would be useful!