Except for trial and error, incremental edits, and binary search debugging, are there any “real” profilers for GLSL shaders? I’m able to max out the triangle pipeline and can match the fixed function pipeline’s performance and display but my shaders are very simple. As my shaders become more complex, I would like to be able to identity hot spots in the flow and focus my efforts (instead of manually trying to locate problem areas). The are tools for D3D, but I don’t see anything for OpenGL.
What about GPU Shader Analyzer from AMD? It supports GLSL and ARB assembly shaders and it can provide you a lot of information about the shader, like:
How does it look like in hardware assembly
How many cycles it takes for a shader core to execute it.
Which part of the shader might be the bottleneck (like texture fetches, or ALUs, etc).
And the best part is that it provides this information separately for every GPU so you can see how it would perform e.g. on an HD2600 compared to an HD6850.
While it is far from all that is needed in order to write efficient shaders and profile them, it is a very good starting point.
This keeps me from re-loading the shader and looking a the actual performance numbers and it’s nice to see the assembly code to understand what’s happening under the covers. As you said, it’s far from what is needed to fully profile shaders.
I did run into some anomalies whereby the compiler would generate errors if my shader had a uniform structure. The line number was completely bogus and I had to resort to the steps in the original post to finally figure that one out.
When I said that there is no support for GL shaders debugging and profiling, it was said out of rage because of ignorance and absence of will to support developers with proper API. It was said many times before, but I’m going to repeat it again.
Debugging means an ability to stop the execution and take a look at values of the variables. Which tool enables that for GLSL shaders?
Frankly, I’m doing that using TF and moving output vector throughout the shader to catch right value, but I really doubt that any beginner can do the same. For VS output is caught with the texture, of course.
Considering profiling, there are bases for very serious work, but the support is extremely poor. AMD_performance_monitor is a great OpenGL extension, but … Although it works for the latest GPUs, retrieving about ten thousand (!!!) values without any clue what they mean is useless. NVIDIA PerfAPI is also great API, but there is no support for Ferim. Kepler is already at the market, but we still don’t have any support for two years old GPUs.
AMD’s GPUPerfAPI looks promising, but, unfortunately, I am oriented toward NV GPUs so I haven’t tested it yet.
Comparing to support for CUDA and D3D, it is a shame how poor the support for OpenGL is.
glslDevil was probably a very useful tool 4 years ago. But I’m not sure anybody can use it now because it supports OpenGL up to the version 2.1. OpenGL world changes very dynamically. In such environment intercepting tools are doomed to extinction, unless they are provided by hardware/drivers’ vendors.
Much better solutions are instrumentation tools since they are version independent. They are more complicate to use, because they are based on their own API and have to be built-it in the code, but are more flexible. The only way to have long-term usable debugging/profiling is to be directly supported by the GPU vendors. That’s why I insist on updating and supporting profiling/debugging APIs.
Really? Good to know, would have not expected that (latest release seems to be 02/16/10 and is not available on Win + GLSL 1.2 max indeed). Would explain why it consistently crashed way beck then - i was definitely in GL3.0+ land at the time.
