Shaders -- Which ones? (fixed, surface, cg?)

Hi,

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:
http://www.youtube.com/watch?v=fy3Zc...eature=related

(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.

Quote:

---

Originally Posted by maik

Also, unity mobile shaders are fixed functions, which means they use ogles 1.1 = "slower". Right?

---

Some of them. The rest are surface shaders. Either way, could be faster.

Quote:

---

Originally Posted by maik

And surface shaders use of pixel light every where, so they may be trouble specially for iphone4, ipad1 ?

---

Surface shaders deal with whatever types of lights you set up in the Editor, with little code. That's why they're useful.

Quote:

---

Originally Posted by maik

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?)

---

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.

Thank you.

Quote:

---

Originally Posted by Jessy

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.

---

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)

Can you elaborate more on this?

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.

Quote:

---

Originally Posted by Jessy

Fixed function shaders will always be translated to the programmable hardware in a way that yields suboptimal performance.

---

This sounds sensible but it's a bit scary. Most, if not all of Unity's built-in mobile "optimised" shaders are fixed function. Considering that the only Apple supported devices today are opengles 2.0, does this mean the mobile shaders are all sub-optimal and should be replaced?

Quote:

---

Originally Posted by actuallystarky

Considering that the only Apple supported devices today are opengles 2.0, does this mean the mobile shaders are all sub-optimal and should be replaced?

---

Not replaced. GLSL SubShaders should be added, so they well on obsolete hardware, and faster on modern hardware. You can find threads here from the past year or so in which I detail this.

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.

Quote:

---

Originally Posted by hippocoder

as anyone actually got any significant speed gains from rolling their own equivalents to the mobile/ set?.

---

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.

Quote:

---

Originally Posted by Jessy

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.

---

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?

Quote:

---

Originally Posted by Moonjump

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 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.

This means it's clear that the following shaders need a good bit of optimizing:

Multiply, Add, Alpha and unlit. For most people that is.

thank you again.

PVRUniSCo seems to be a great tool.

Quote:

---

Originally Posted by Jessy

However, because you're on a mobile device, framerate should not be your only concern. GLSL saves battery.

---

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?

Quote:

---

Originally Posted by maik

PVRUniSCo seems to be a great tool.

---

It is actually one of the worst applications I have ever used, but it can definitely be educational in the five minutes that it runs before it stops working!

Quote:

---

Originally Posted by maik

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?

---

There is only one other option: fixed function instructions. Unoptimized GLSL will not run better than fixed function code being translated by the drivers.

Quote:

---

Originally Posted by maik

One last question, have you done performance tests from surface shaders vs glsl in iOS?

---

Surface shaders are GLSL when you build for mobile devices.

Quote:

---

Originally Posted by maik

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?

---

Not yet. I think it makes sense if your audience is high-end PC users, but I don't know of a Unity game that has targeted that market.

Quote:

---

Originally Posted by Jessy

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.

---

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.