Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Would you use shader debugging if it was available?

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2005
    Posts
    12

    Would you use shader debugging if it was available?

    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?

  2. #2
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,575

    Re: Would you use shader debugging if it was available?

    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 !

  3. #3
    Super Moderator OpenGL Guru dorbie's Avatar
    Join Date
    Jul 2000
    Location
    Bay Area, CA, USA
    Posts
    3,969

    Re: Would you use shader debugging if it was available?

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

  4. #4
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,000

    Re: Would you use shader debugging if it was available?

    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:

    Code :
    //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();

  5. #5
    Member Regular Contributor
    Join Date
    Mar 2003
    Location
    Spain
    Posts
    273

    Re: Would you use shader debugging if it was available?

    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.
    "!I don't know... fly casual"

  6. #6
    Junior Member Newbie
    Join Date
    Apr 2005
    Posts
    12

    Re: Would you use shader debugging if it was available?

    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.

  7. #7
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,000

    Re: Would you use shader debugging if it was available?

    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.

  8. #8
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: Would you use shader debugging if it was available?

    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?
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  9. #9
    Junior Member Newbie
    Join Date
    Apr 2005
    Posts
    12

    Re: Would you use shader debugging if it was available?

    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.

  10. #10
    Intern Contributor
    Join Date
    Mar 2004
    Posts
    52

    Re: Would you use shader debugging if it was available?

    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •