I’ve been looking into shader debuggers lately; the one that made it to my shortlist was glslDevil (which is unfortunately unmaintained since 2009, and the open-source successor project is very low-activity).
Does anybody have practical experience with it glslDevil/GLSL-debugger? Or with some other shader debugging tool?
The problem is that you need to get hold of the shader in its compiled form. That happens late in the engine, so you’d either have to get hold of it externally through the OpenGL layer somehow (dunno if thats even possible) or have the debugger built into the engine. Depending on what info you need you could just use the error output which shows the compiled shader with line numbers and the location the exception occurred. You get a bit more info about generic OpenGL issues when you use the lwjgl-debug.jar instead of the normal lwjgl.jar but I guess most people around here debug shaders the “oldschool” way.
If you’re after variable tracking and step by step execution you’re probably out of luck unless you adapt an existing debugger to jME. You could also create the core / hard work of your shaders in a different environment that has an OpenGL debugger and then port them over to jME later.
glslDevil simply intercepts the OpenGL command/data stream via a debugging API (ptrace on Linux/Unix, something else on Windows), so yes getting hold of the final shader code is possible.
Variable tracking and single-stepping is actually what glslDevil does. It fakes it: Modfies the GLSL code so that it will abort at the point where the current breakpoint is, returns values in index and color buffers, then resets the OpenGL state; to do one step, it re-runs the shader with the abort moved to a later position.
Yes they parse GLSL shader code for that. The linked whitepaper is intriguing (but reimplementing that would be way beyond my time budget).
glslDevil can work with any program, no modification required; it might fail with newer applications if they use OpenGL feature that are post 2009 (since it might be unable to properly parse the shaders, or since OpenGL might have new state that needs to be restored).
JME could be just fine with that actually, we’re not using cutting-edge OpenGL stuff anyway.
Mostly, I’d like to hear whether anybody tried this already, before I sink time into experiments just to hear later “oh not, that tools isn’t useful anymore”.
It would sure be a nice new tool in the toolbox if it works.
The problem is that we use in house global uniforms and you can’t have them in a third party software.
As Normen suggested you can create the core of your shader with glslDevil and once it work convert it to JME shader, but that’s a bit cumbersome and error prone.
Global uniforms would show up in the OpenGL command stream and/or the GLSL code submitted, I’m not seeing a problem with that.
Okay, we’re actually writing shader code fragments and let JME combine them and add its own boilerplate. I’m not sure whether the original fragments are still recognizable from the final code, but that’s why I’m asking whether anybody has experience with using such a tool.
If nobody has used it, I’ll probably try it out and report back once I get back to doing shader work.
I wasn’t able to get any of these tools running on windows 7 64-bit with Nvidia card. They were failing either because of 64-bit (glDevil I think), or because nvidia drivers were not talking to them properly (gdebugger). I tried playing with stuff provided from nvidia, but eclipse-based one seems to be purely cuda oriented and VS one requires full edition of VS, won’t work with Express.
Yeah, I read that glslDevil doesn’t work and never worked on Win64, supposedly because the debugging library comes with a 10,000$ price tag for 64.
Win32 is supposed to be fine.
Ah well. Maybe somebody else has more to report.