Imagination’s PowerVR DevTech team has a brand new tool that will help you accelerate development work for any application dealing with shaders, especially high-demanding mobile games. Joe Davis is here to give you a brief description on what the tool does, how you should use it and why he put everything together in a small, simple script.
Many regular users of our PowerVR Graphics SDK already leverage PVRUniSCoEditor for individual shader profiling, but this can become cumbersome when dealing with a huge number of shaders in complex graphics applications such as games, navigation and UI. Wouldn’t it be great if the SDK included a tool that made large scale shader profiling easier? Fortunately, the SDK already includes a great tool that can be used for this purpose.
The GLSL profiling compilers in the SDK are used by PVRUniSCoEditor to retrieve the per-line and entire shader stats. This information is ideal when prototyping shaders to understand their cost without having to execute and benchmark them on target hardware, but it’s only given for the currently selected shader. Conveniently, the compilers are command-line tools and they either write out profiling information to a file or to print it to the console (depending on the profiling mode), so it’s very easy to write a script that can batch process shaders and collect profiling information for them all.
To ease developer support, we’ve written a Perl script called GLSLShaderAnalyzer that does exactly this. The user can point the script to the directory that contains the SGX GLSL ES compilers (535, 540 & 543) and to the vertex and fragment shaders that need to be processed (text files with .vsh and .fsh extensions, respectfully), and then run the script to write profiling information to .csv files. We’ve chosen to write to .csv files as they can be opened in a spread sheet tool, such as Excel, to analyse the data or can be parsed and used as input to a custom analysis tool. A .csv file will be created for each combination of SGX compiler and shader type. For example, the default configuration will create 6 .csv files – a vertex and fragment .csv for each of the available compilers (535, 540 and 543).
Before we go any further, we are issuing the following disclaimer: this was done by a Perl newbie, there are some Perl module dependencies (if you don’t already have the modules, a warning will be given and you can download them with CPAN) and the script is only written to use the Windows 32 bit compilers. Also, we’ve put some checks in to prevent it exploding, but the script doesn’t check the validity of paths that are given as arguments (which isn’t too much of a problem, as long as the parameters are correct).
How does batch profiling for shaders work?
If the Perl script is executed without any arguments, it will display a short manual that describes the parameters that can be given:
No arguments have been specified
The following commands can be used
-sgxCore=all|535|540|543 Default: all
-profileMode=all||profile|perfsim Default: perfsim
-compilerDir=<somePath> must be set
The bare minimum argument that needs to be set is the “-compilerDir” path. If only this is set, “-inDir” and “-outDir” are assumed to be the current directory and the other parameters use the default options that are listed.
“perfsim” is the default “-profileMode” option as this profiling information comes from a GPU simulation path in the compiler. The “profile” stats come from an earlier stage in the compiler that allows per-line estimates to be calculated, but this is before the compiler optimizes the shader so the actual total number of cycles to execute the shader (as given by the “perfsim” flag) may be lower than this.
Once the script has completed, you will have a bunch of .csv files that contain profiling information for all of the shaders that have been processed. As there are separate .csv files for each SGX GPU it’s easy to, for example, compare the output of a USSE1 based GPU – such as an SGX540 – against the output of the SGX543 USSE2 compiler.
One of the great things about this script is that you can give it any GLSL ES .fsh and .vsh files as input. This means that in addition to using this script for shaders in your project that may already be .fsh and/or .vsh files, you can also use it to process shaders that have been dumped by PVRTrace (can be done with the “File->Save->Save Shaders” option) or you can write another script to convert from GLSL ES shaders in your favourite game engine into .fsh and .vsh files that can then be batch profiled.
The profiling shader compilers are just one of many excellent tools in the PowerVR Insider SDK that can be scripted or integrated into your own tool chains. We hope this post has given you a few ideas for the best way to incorporate these components into your OpenGL ES development process!
Come back to our blog regularly for more developments on our PowerVR Graphics SDK and follow our @ImaginationPR and @PowerVRInsider Twitter accounts for the latest news on all things PowerVR mobile graphics.