Big question. How fixed function opengl ES 1 is emulated using ES 2

[ATTACH=CONFIG]534[/ATTACH]
Okay, before you guys go thinking I asked an easy question in the title, read on…

Apple claims in its documentation of the implement OpenGL ES 1.0 on modern hardware on top of OpenGL ES 2 using shaders. Here’s where I call shenanigans however.

https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html

Apples documentation above states that under ES 2.0, vertex shaders can support at most 128 uniform vec4’s which makes any kind of shader that supports 8 lights almost impossible to write using uniforms. So how the heck did they pull this off using a single pass of rendering??

Any gurus want to throw out any theories?

Experimenting with a 1.0 context, shows me that manipulating light parameters is very interactive, making it seem as though they are still using uniforms to implement the lights, and not some sort of compiler constant trickery.

Even gl kit (and every other OpenGL ES 1.0 emulation shader that I can find) only supports three lights, leading me to believe that the actual OpenGL ES 1.0 implementation uses some kind a hardware shortcuts unavailable to me under 2.0. This seems like not that big of a deal, however the application that I’m writing has to support up to 8 configurable GL lights with rendering quality and performance identical or better than that on es 1, otherwise I can’t make the transition to 2.0 without breaking backwards compatibility.

Summary, TL;DR, how to emulate ALL 8 fixed function lights with only 128 uniform vec4’s of storage.

[QUOTE=mlfarrell;1255988][ATTACH=CONFIG]1177[/ATTACH]
Apples documentation above states that under ES 2.0, vertex shaders can support at most 128 uniform vec4’s which makes any kind of shader that supports 8 lights almost impossible to write using uniforms.[/QUOTE]
How so? You need 24 components (6vec4) per light, so that’s 48vec4 for 8 lights. That’s a fair chunk of the total number of uniforms, but not prohibitive. Another 8*4=32 vec4 are required for texture matrices, 6 for clip planes and 8 for texture environment colours, but that should be all of the arrays (ES doesn’t have glTexGen).

You need a lot more if you store derived values (e.g. front/back material-light products), but that’s only an optimisation; you can get by without it. I count 116 * vec4 required if no derived state is used.

It would be interesting to see whether there’s a sudden performance drop above a certain number of lights, possibly dependent upon whether GL_LIGHT_MODEL_TWO_SIDE is enabled.

You’re right. I was dividing by 4 like an idiot and interpreting the limit as the number of components instead of vectors. I’ll be giving this a try soon. I’ll use preprocessor directives for compile time optimization to handle the cases where it’s not necessary to iterate over the entire set of lights.

Ill post back here with the performance results.