Cg on iPhone slow compared to GLSL

I am currently testing the performance of shaders on the iPhone 4 (using Unity3b5) and noticed that Cg shaders are really slow compared to GLSL, even in the simplest case. A shader doing only transform and a texture lookup, filling the entire screen, the Cg version runs at around 25-30 fps. The equivalent GLSL shader runs at 60 fps (capped), same as the built in diffuse shader. I tried ARB_precision_hint_fastest but no change in performance. Has anyone encountered this problem or an explanation to the big difference?

 

the problem with CG is that its output is opted for GLSL, the real GLSL

unhappily, OpenGL ES has only a subset of GLSL so the cg side, as it still offers its full amount of functionality, has to use own functions to fill up the stuff etc resulting in significantly longer shaders to replicate the CG code.

Even worse if you use the surface shader system, no way to get through with that as the shader size then basically "explodes" compared to a handoptimized GLSL ES shader.


You can actually check out the cg generated shader if you click the edit compiled shader button.

Also ensure that you use the platform pragma that tells unity to only compile an OpenGL ES 2.0 shader out of it.

 

Thanks for the tip about compiled shader, hadn't seen that one. It appears that the iPhone GLSL compiler is the culprit. It does almost no optimisation on the shader, which means function calls are not inlined and unnecessary moves are not removed. Found glsl-optimizer (http://github.com/aras-p/glsl-optimizer) for precisely this problem, but I will probably go the handcrafted route instead.

 

hehe you are aware that aras-p = one of the programmers behind Unity?

so if that tool works, you best report a bug that the input get significantly better with that tool. I though would expect that it is already in use.

Question is if the optimization it does is GLSL for OpenGL or GLSL for OpenGL ES (not looked at it yet)

From what I recall from his blog though that tool was one of the experimental paths he followed (and potentially still follows) to get rid of CG at some point due to its errorous shaders compiled in general. it binds more texture registers than needed due to new registers for temp textures and stuff like that, depending on the platform and if pragmas are missing like dx9 and alike

 

Ah there you go, no wonder he ran into that problem then

Will see if I get some time to check out the tool, it certainly would be nice to be able to write shaders with function calls etc, even if it just are some simple ones.

 

schweet

 

Just installed b6 and looked at the compiled shader output; a lot leaner code, will certainly help the poor glsl compiler on the iPhone!

 

I'm developing 2D game and there're about 100 big sprites on the screen (everything dynamicaly batched to 6 draw calls).
I tried to use custom shader to multiply texture color on constant and got 15fps.
I started to research Cg and GLSL shaders and tried both from thread (with modifications: Tag=Transparent, ZWrite Off, Blend SrcAlpha OnMinusSrcAlpha).
Result is: GLSL 10fps, Cg 30fps.
I've tried mediump and lowp in GLSL but without any boost.
Wierd thing is when in Cg shader I've tried to use ANY operation with color (add 0.1, multiply to 0.1) fps reduced to 20.

Seems Cg shader is faster then GLSL now.

But what to do with fps drop in Cg shader with simple operations?

Tested on iPod touch.