Several capabilities seem to exhibit hardcoded limits, namely: - MAX_COMBINED_TEXTURE_IMAGE_UNITS (WebGL=8, iPad mini retina native=32) - MAX_TEXTURE_IMAGE_UNITS (WebGL=8, iPad mini retina native=16) - MAX_VERTEX_TEXTURE_IMAGE_UNITS (WebGL=8, iPad mini retina native=16) - MAX_FRAGMENT_UNIFORM_VECTORS (WebGL=64, iPad mini retina native=224) - MAX_VERTEX_UNIFORM_VECTORS (WebGL=128, iPad mini retina native=512) - MAX_VARYING_VECTORS (WebGL=8, iPad mini retina native=15) These limits match iPod touch 5th gen limitations, but they are still reported back when running WebGL on an iPad mini retina, which has higher limits natively.
The low number of available vertex shader uniform vectors is the most surprising restriction to me, and probably the hardest to work with. Having access to only 128 uniform vectors implies that GPU skinning is severely limited to a small number of bone transforms. It would make a world of difference if at least 250 uniform vectors were supported on most iOS devices. As you can see on the WebGL stats page, 99.6% of WebGL enabled browsers support at least 250, so it's become a reliable vector count to use.
(In reply to comment #0) These native values you are reporting indicate that you are using OpenGL ES 3.0. Many devices cannot use OpenGL ES 3.0 according to https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html I'm not sure what else this will give access to or what this will do to the extensions, but here is a patch that gives access to the additional vertex uniform vectors, etc.
Created attachment 232816 [details] Patch
This patch does not change the behavior of an iPhone5, but it significantly changes the behavior of an iPhone5s. For example, GL_OES_texture_float is no longer in the string returned by ::glGetString(GL_EXTENSIONS) so our extensions detection thinks that we no longer have OES_texture_float. This is true with the other GLES2 extensions that are standard to GLES3. What do we want to do about this?
Created attachment 232828 [details] Patch
This patch feels pretty hacky, but it's necessary to maintain the same behavior as OpenGL ES 2. This is especially necessary with people querying the extensions through JavaScript. Maybe this should be specifically mentioned in the WebGL 2.0 spec, which claims that "WebGL 2 is backwards compatible with WebGL 1: existing content will run in WebGL 2 without modification." Also, maybe this is getting too close to WebGL 2.0 behavior to be included in WebGL 1.0.
I was under the impression that things like usable texture units, uniforms and so forth should reflect the limitations of the machine, rather than limitations of the revision of API in use. Afaik that's how the parameters are handled by most other drivers. In that case, the fault would seem to lie rather with the driver, because the limits imposed upon the iPod touch 5th gen seem rather severe given the fact that they're far exceeded by even Nexus 4 hardware, which should be somewhat weaker hardware than the iPod 5g ones. Regarding using OpenGL ES 3.0 as the backend, I don't think that should be an essential problem. However, I did notice that the ES 3.0 context on iOS does seem to forgo extensions which where present in ES 2.0, in case that they would be available as part of ES 3.0 core functionality. These extensions would seem to be: - OES_texture_float - OES_texture_half_float - OES_depth_texture - OES_element_index_uint - EXT_draw_buffers - EXT_instanced_arrays - OES_texture_float_linear - OES_texture_half_float_linear - EXT_color_buffer_float - EXT_frag_depth - EXT_sRGB - EXT_blend_minmax - EXT_shader_texture_lod I think that this means that if you switch to an ES3 context on iOS, that you'll have to provide the corresponding WebGL1 (ES2) extensions, you'll need to emulate the extensions above using ES3 core functionality on iOS, lest you'll want to lose that functionality on ES3 compatible devices.
I think this might be prematurely jumping into WebGL 2.0 functionality. The "problem" is correctly following Apple's specified behavior using GLES2, and the workaround would need more extensive specification and testing. I think this should wait until the WebGL 2 spec is more complete so we know what to do with GLES3 stuff.
The hardcoded limits are expected and documented behavior, since WebKit is currently backed by an OpenGL ES 2.0 context. See https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html for details. I think we should close this bug as "INVALID", and open a new bug that tracks progress to move WebKit's WebGL implementation to GLES3 on the backend.
Done. https://bugs.webkit.org/show_bug.cgi?id=133745 <rdar://problem/17242741>