I just downloaded and installed the SDK today (but I only ticked the PVRShaderEditor component as that estimation of cycles on different PowerVR chips was all I was looking for).
I have spent a few hours playing with basics GLSL ES (version 100) fragment shaders and I have become somewhat convinced that the cycle counts both displayed next to the lines, and the estimated total is somewhat “random”.
So many times I could have sworn that when I make a change and then revert it, the cycle values don’t return to what they were before the change. I initially chalked this up to mix of tiredness, forgetting when I had toggled between chips in the preferences (Edit - Preferences - “PowerVR GLSLES Series5” and “PowerVR GLSLES Series6” compilers) and perhaps the editor being quirky and not always updating; but I ruled out of of these things (with the editor quirks* I made a habit of adding and removing extra whitespace and semicolons to make sure changes were not missed) and I am certain that seen the same input GLSL programs are give very different cycle counts - even changing tabs in the editor will change the cycle counts on the lines and total/s.
The full version info of the software is: PVRShaderEditor 2.6 (SDK build 3.5@3523712), it is freshly installed but I have also tried checking for updates anyway (it reports it is up-to-date). The compilers show version info shows as “SGX540 rev 130” for the Series5 compiler and as “G6x00” for the Series6 ES compiler.
*I describe the editor as quirky, because in my short time playing with it and typing into it I have experienced it displaying errors on glsl lines from before I had finished typing/editing them, after the change was complete (eg. changing “mediump” to “highp” the error " ‘high’ : syntax error; " may persist until I make further changes to the source
Here is some example code:
[pre]#version 100
precision highp float;
// Code adapted from: https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/lighting.php
varying vec3 N;
varying vec3 v;
uniform vec3 lightPos;
varying vec4 alberto;
void main(void)
{
vec3 L = normalize(lightPos - v);
vec4 lambert = alberto * max(dot(N,L), 0.0);
lambert = clamp(lambert, 0.0, 1.0);
gl_FragColor = lambert;
}
[/pre]
With the Series5 compiler option the “vec3 L = …” line shows a cycle count of 4, and the “vec4 lambert…” line that follows it a cycle count of 9. 4+9=13 but the output area shows “Cycle count: 12.0” mirrored by the Profiling which shows “Emulated Cycles 12”, curiously they also show for this glsl fragment program Non-dependent texture reads/loads:3
With this simple shader I am not able to find a set of edits that lead to the total changing and then not changing back when the edits are reverted…
EDIT: I don’t think it describes all of the cases of the totals changing in unexpected ways, but with a 2nd fragment shader open in another tab (but not focused) I went to Edit - Preferences and switched to the Series6 compiler… I observed the preformance estimate change to show a Performance Estimate of 33 cycles (which seems excessive for Lambertian diffuse), toggling back to the Series5 compiler option then showed it too was now producing Cycle Count: 33.0… In this situation I believe these cycles are result of the editor compiling/reporting on the wrong shader program - the 33 cycles would see to correspond to the shader in the other tab.
Hi Nat,
Thanks for the feedback. The per-line estimates can be confusing, as the values come from the compiler before certain optimizations are applied. This is why the emulated cycle count is almost always lower than the per-line total.
We have started to look into ways to improve the per-line estimates for a future release. Unfortunately. we wont have time to improve the feature for our imminent 4.0 SDK. For now, I would recommend using the emulated cycle counts as a guide for all optimizations, as this total value includes compiler optimizations. For a more detailed analysis of your shader I would recommend using the disassembly output.
Joe, thanks for the reply. Glad to hear there might be a newer version available soon - maybe it’ll fix the issue with described in my edit to my second post - which is where the real randomness of the figures that I was pulling my hair out for seems to originate from (which was exasperated by confusion of different figures).
Is the issue with the wrong tab’s source being compiled/shown on preference change a known issue or one you have heard of before? I ask because although I can try and work around it now I have figured it out, I imagine I can’t be the only one to be confused by it’s effects.
Hi Nat,
[blockquote]Is the issue with the wrong tab’s source being compiled/shown on preference change a known issue or one you have heard of before?[/blockquote]
I’ve discussed the issue with the PVRShaderEditor lead and he informed me that a fix was implemented for this in time for our 4.0 SDK. The new SDK went live yesterday - you can download the latest installer here: https://www.imgcommunity.local/developers/powervr/installers/
Please let us know if you encounter any issues with the new version of the tool.
Thank Joe, I will do that cheers 
