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

Discussion in 'iOS Development' started by maik, Feb 23, 2012.

  1. maik

    maik

    New Member

    Joined:
    Dec 4, 2011
    Messages:
    55
    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.
  2. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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.

    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.
    Last edited: Feb 24, 2012
  3. maik

    maik

    New Member

    Joined:
    Dec 4, 2011
    Messages:
    55
    Thank you.

    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...s.html#//apple_ref/doc/uid/TP40008793-CH7-SW3) (Or by unity: http://unity3d.com/support/documentation/Components/SL-ShaderPerformance.html)

    Can you elaborate more on this?
    Last edited: Feb 24, 2012
  4. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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.
  5. actuallystarky

    actuallystarky

    Member

    Joined:
    Jul 12, 2010
    Messages:
    156
    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?
  6. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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.
  7. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Messages:
    10,312
    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.
  8. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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.

    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.
    Last edited: Feb 26, 2012
  9. moonjump

    moonjump

    Member

    Joined:
    Apr 15, 2010
    Messages:
    1,558
    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?
  10. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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.
  11. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Messages:
    10,312
    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.
  12. maik

    maik

    New Member

    Joined:
    Dec 4, 2011
    Messages:
    55
    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?
  13. Jessy

    Jessy

    New Member

    Joined:
    Jun 7, 2007
    Messages:
    7,173
    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!

    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.

    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.
    Last edited: Feb 27, 2012
  14. moonjump

    moonjump

    Member

    Joined:
    Apr 15, 2010
    Messages:
    1,558
    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.