We are about to start a new 3d game for iOS.
We are targeting iPhone 3gs, iPhone 4/ipod4, iPhone4s , iPad1 and iPad2 (and iPad3 when it comes out :P)
As far as i understand all are armv7, and the 3gs, iPhone 4 and iPad 1have the same GPU. So for those devices i have to keep in mind the fillrate problems (so try to avoid blending/alpha test shaders). And for the 3gs keep in mind the drawcalls.
Now, opengles 2.0 has no backwards compatibility. And for what i read in the forums, opengles 2 runs faster than ogl 1.1 in the devices i want to target. Also, unity mobile shaders are fixed functions, which means they use ogles 1.1 = "slower". Right?
And surface shaders use of pixel light every where, so they may be trouble specially for iphone4, ipad1 ?
So, does this means that it would be better to always code my own Cg shaders? (i.e. replace all the default shaders with my own ones in cg?)
In my case, when or where would it be more optimal to chose between "mobile shaders", surface shaders or my own in Cg?
Our game will be in 3d, something similar to the first 20 seconds of this game:
(A main character, with some "simple" enemies/obstacles and a linear level (the level will not be as complex as the one in the video) ).
I would appreciate any help on this.
thanks in advance.
Some of them. The rest are surface shaders. Either way, could be faster.
Surface shaders deal with whatever types of lights you set up in the Editor, with little code. That's why they're useful.
Last edited by Jessy; 02-23-2012 at 04:21 PM.
Assuming an ideal scenario where the translated GLSL code from Cg is as optimized as Unity says it should be, which scenarios Wont be faster coding Cg than using Surface shaders or Fixed function? . Or the other way, which scenarios will probably the Cg code would be slower or the same as using surface or fixed function? (assuming i'm following some good practices as the ones recommended by apple :https://developer.apple.com/library/...008793-CH7-SW3) (Or by unity: http://unity3d.com/support/documenta...rformance.html)Non-surface shader Cg can be faster, but the device runs GLSL. If performance is an issue, GLSL is the way to go, unless the Cg auto-translates into optimized GLSL. Sometimes it will, sometimes it won't. If you find GLSL to run faster than the translated Cg, you should report a bug. I don't have time for that (the auto-translated GLSL looks like garbage, so comparisons are too time-consuming), so I use GLSL directly, but that's not the approach Unity steers you into.
Can you elaborate more on this?
Last edited by maik; 02-23-2012 at 06:42 PM.
Fixed function shaders will always be translated to the programmable hardware in a way that yields suboptimal performance. Surface shaders are Cg; they just trade control for speed of creation. Until you learn to spot slow code, the only ways to find out when it won't be optimized code are by using this tool or testing framerate on the device.
I'm a bit confused about this. It was my understanding that the mobile shaders actually get compiled to pretty decent glsl from unity's shaderlab syntax.
Has anyone actually got any significant speed gains from rolling their own equivalents to the mobile/ set? There's a lot of talk of them being fixed function this and fixed function that but that isn't even remotely correct. For a start, 3GS and above don't even understand fixed function and if 2.0 is enabled, then they will get compiled into the opengl es 2.0 equivalents right?
Just curious about the whole process as I understood that Aras spent significant time making sure that it wouldn't suck.
hippocoder, you're getting fixed function shaders confused with surface shaders. Apple's drivers do the conversion from OpenGL ES 1.1 code to shaders, but obviously you can't affect that result, and it is not good enough to match the speed of whatever it does, under OpenGL ES 1.1, in 2.0.
Last edited by Jessy; 02-26-2012 at 07:45 AM.
I have been using the default Unlit shaders. I thought they were supposed to be exceptionally fast because they are so simple. You are saying you create faster shaders?Yes. But only for unlit materials. I haven't had a need for the default shaders otherwise, so I can't compare the results with lighting. The default shaders have to take care of all the lighting cases that Unity provides; if you know what subset of that you need, you can make a faster shader that can work easily for your specific needs.
thank you again.
PVRUniSCo seems to be a great tool.
when you said "GLSL saves battery", which is the "opposite"? I mean, if GLSL saves battery, what are the other options that does not saves battery?
One last question, have you done performance tests from surface shaders vs glsl in iOS?
Do you think the "gain of coding speed" that surface shaders provides is worth the performance it could cost versus coding all the shader in GLSL?
There is only one other option: fixed function instructions. Unoptimized GLSL will not run better than fixed function code being translated by the drivers.
Surface shaders are GLSL when you build for mobile devices.
Last edited by Jessy; 02-26-2012 at 08:15 PM.
Thank you Jessy. I am working on a 2D game where I have had to model objects so that I can make them opaque. I had terrible performance when using transparency because of overdraw. Using opaque as much as possible has added a lot of work, but it does mean I am OK for performance. At least I can delay studying shaders in detail for a future project.Yes. But the main reason is because unlit shaders are generally the norm only for 2D games. And with 2D games, fragment shader instruction count matters for performance, because of overdraw. If you only had opaque objects, I bet it wouldn't affect the framerate. However, because you're on a mobile device, framerate should not be your only concern. GLSL saves battery.