I’ve been looking for a good tool/IDE for authoring GLSL shaders (preferably
with an ability to debug them) and at this point my search came to a halt -
as it seems that there are tools available but none of them actually has
all the features I want and sometimes those tools are simply unstable to
the point of being completely unusable.
So I wanted to share my findings with OpenGL community and let me know/correct
me if I’m missing anything.
I’m being a hobbyist OpenGL developer for a few years now, have a big faith in
OpenGL and it is just discouraging sometimes when you realize that the only way
to figure out what is wrong with your shader is to use printf-style debugging
while knowing that the other camp (DX) has very powerfull and stable tools,
like PIX for example.
Ideally I would like to have a tool/shader authoring IDE that would allow me to
do the following:
Syntax highlighting + intellisense (language version sensitive);
Tooltips for function parameters (like in Visual Studio) + context sensitive help;
Debugger with autos/locals/watch-window/breakpoints/run-to-cursor support,
pixel-debugging features, etc.
The tools I looked at are these ones:
glslDevil: I had high hopes for it. Looks very nice on screenshots and even provides
hardware-aware debugging. But! - most of the time it just crashes on me
(I’m on Windows Vista Home Premium 64-bit running 2xGF280 SLI);
I need to turn off OpenGL function call trace to get faster to the next shader switch -
otherwise it takes very long - 15-20 minutes or it just freezes. Every time
(95% of all attempts) when a click the Pause button (in the GL Trace window) it crashes.
Another problem: I could never fully debug vertex shaders - I could not get
the values of the variables displayed.
When (while debugging a vertex shader) I click the ‘add to active window’ button (Watch window)
it crashes always.
Thus: hardly usable at all (and I checked - there are no detectable GL errors).
NVIDIA’s FX Composer (2.5):
From the overview video seems to be a very nice tool - and just what I need - but!
no GLSL support - and it does not seem to be provided any time soon.
From what I found on forums - adding GLSL support is quite hard as structure
of GLSL program is quite different from Cg/HLSL - no techniques/pass/includes support…
Render Monkey (1.82);
The best tool so far (and I’m using it) - but no debugging support.
No GLSL support; requires source code modification; fragment shaders only.
No updates since 2003.
*) only provides syntax highlighiting;
*) only supports VS 2008 (I have VS 2005 a see few reasons to
upgrade to 2008 as I’m mostly doing C++)
Typhoon Labs Shader Designer:
*) Crashes on Windows Vista/7. Could get it to work though on Windows XP.
*) Supports intellicense and syntax highlighting;
*) Does not support shader debugging;
*) No longer updated as the development has been ceased - thus does not
support latest version of the language.
So is this the state of affairs in OpenGL land?
Thanks for your feedback.
P.S. I guess I should just send bug reports to the glslDevil team hoping that they would
fix them in less than a year…
To debug shaders, I just render to 4 MRT RGBA32f targets, outputting whatever var interests me, and showing the 16 float values on a pixel under the mouse.
I name the glsl shader files as .c and include them in the VisualStudio project (skip build), there with definitions of vec3,vec4, etc I get full intellisense.
Breakpoints and such can be easily improvized with the MRT method. Otherwise, you may have to wait for months or years for complete 3.2 tools
You are joking right? This might be a sensible option if you are an indie developer or doing hobby programming, but not when time is money.
NVidia has great tools for doing Shader development, and debugging with full access to the graphics card information, but they are not caring at all about GLSL.
NVidia only cares about giving just enough support to keep people happy to use OpenGL with their cards, I would say.
FXComposer is not having GLSL support and from the forum discussions it will never get, most likely.
Nexus is a Visual Studio extension to work with Cuda, DirectX Compute and it will have basic OpenCL support. No debugging support besides tracing, is planned for OpenCL or OpenGL, at least on version 1.0.
It does not work in 64bit Windows, which might be an issue, beside the ones already mentioned.[/QUOTE]
According to the information on their web-site: Debugger version (32/64-bit) must match host application
So far, the 64-bit version of glslDevil only supports debugging of 64-bit applications. In order to debug a 32-bit executable (independent of the host system), please use the 32-bit version of the debugger.
So I’m using 32-bit version of glslDevil on 64-bit Windows to debug 32-bit executable…
Unfortunately glslDevil does not seem to support GL3.x
I’m also very disappointed about te OpenGL tools support from either, AMD or nVidia. They may have great tools, but only for D3D.
Even most basic performance profiling is not possible. Nvidia has PerfSDK, but its too old (you need ancient instrumented rivers) and does not work properly on 64bit OS’s. GLExpert might be a good tool, if only one could get it to work.
ATI has a AMD_performance_monitor. It spits out hundreds of counters, but there is ZERO information on what they mean and how to interpret them. ATI’s GPU PerfStudio 2.0 is D3D only.
So in fact there is not a single usable performance profiling tool for OpenGL out there. I don’t know how good gDebugger is. But assuming they rely on the same API’s that nVidia and ATI provide, I conclude they suffer from the same problems.
So I gave glslDevil another try yesterday: I tried to debug my application on these 2 configurations:
Windows 7 Home Premium 32-bit/NVIDIA ION/Driver Version: 186.44 (OpenGL 3.0)
Windows XP SP3 32-bit/NVIDIA GeForce Go 7800/Forceware Version: 86.02 (OpenGL 2.0)
No differences in behavior: same crashes, freezing as I previously described in my first post.
I tried to simplify my rendering scene by turning off rendering of some passes - no difference.
And I actually discovered another issue which it leading to its crash…
I tried to debug another executable - same issues.
So the only thing I have left is to try it on Linux - as it seems to me that
there has not been any thorough testing on Windows…
But it is going to be challenging, I guess, if you never dealt with Linux…
Until I’m completely desperate I will just stick to printf-debugging which is
hard but still gets the job done sooner or later…
So all that leads to the following questions:
Why there are no commercial (that is actually supported/up-to-date/bug-free or at least bugs get fixed as they discovered)tools for OpenGL? (other than gDebugger which barely provides any GLSL support other than displaying source GLSL code - as far as I looked)
Nobody is interested?
There is no market for it?
Too difficult to do?
Not enough access to the underlying hardware?
Because it seems to me this is a good thing to start working on.
Am I wrong?
I guess no one cares. NVidia and ATI are mostly providing support for their own technologies and DirectX. Maybe because they see no advantage in providing support for free OpenGL tools and no one complains about it. I am not being totally correct here, they provide actually some support, but not as good or complete as for the other technologies.
Maybe that now so many smartphones with OpenGL ES hardware are appearing on the market, they might start improving this situation, but I have my doubts.
This used to be true for the longest time, but they now have NVPerfKit (include SDK) out now for 64-bit Linux (see https://nvdeveloper.nvidia.com). 190.32 drivers supporting PerformanceMonitorMode that work. I would like docs on all the new counters however. Maybe when it’s an official release.
There’s also NVPerfKit 6.0 out there (173.13 drivers, ~1.5 yrs old) out there, but I never got them to work. These are in my/your “ancient instrumented drivers that do not work properly on 64bit OS’s” category.