Would you use shader debugging if it was available?

[John_Kessenich]

Originally posted by _michal:

 
(true ? gl_FragColor.x : gl_FragColor.y) = 1.0; 

Yes, the specification says this is not allowed. We will fix it.

I made an attempt to port 3dlabs’ compiler in the beginning of 2005. There were so serious problems with compiling it.
Were you using an out of date or non-standard C++ compiler? On Windows, we went to the .NET version of the compiler a long time ago, because 6.0 was too non-standard. Since then, we have put back in most support needed for 6.0.

JohnK

[_michal]

Originally posted by John Kessenich:
Were you using an out of date or non-standard C++ compiler? On Windows, we went to the .NET version of the compiler a long time ago, because 6.0 was too non-standard. Since then, we have put back in most support needed for 6.0.

The Mesa’s projects under Windows use VC6 projects (.dsp and .dsw files). That’s why I asked for VC6 support.
Now I think that Mesa should switch to dotnet project files. So VC6 issues wont be a problem any more.

Thanks

[mikef]

Isn’t shader debugging already theoretically possible?

Surely you could annotate a shader to output values at strategic points in the code (eg. at the currently active breakpoint), redirect output to a pbuffer and inspect the output. Yes, I know it would be more complicated than that but the only serious problem I can think of is driver quality - heavily annotated shaders would likely break some of the more fragile drivers out there.

Integration into a regular app would be a headache, but it’d be a nice addition to (eg) rendermonkey.

Am I missing something?

[ZbuffeR]

mikef, as you stated it yourself, an important problem is the stability of current hardware drivers on GLSL.
I think that having a reference software implementation with complete debugging support is really important.