Recently while working on OpenGL ES version 3.0 to Metal translation layer (part 1 here), I discovered one obstacle that will prevent it from becoming 100% fully compliant to OpenGL ES 3.0 specification: Provoking Vertex.
OpenGL and many other Graphics APIs’ shader allows some fragment shader’s inputs to be optionally flat instead of interpolated. In this case, the inputs will get the values from the “Provoking Vertex” of the primitive generating the fragment. OpenGL ES 3.0 by default chooses last vertex in the primitive to be “Provoking Vertex”, while most other Graphics API choose first vertex. I have no idea why they (OpenGL board) choose this convention. Why OpenGL have to be oddly different in many cases compare to other APIs like this?
There is currently no way to translate this Provoking Vertex convention between OpenGL ES and Metal without affecting the performance. ANGLE’s D3D11 translation uses geometry shader to re-order the primitive’s vertices to work-around this. However, Metal doesn’t have geometry shader, so this trick cannot be applied. So I have no choice but to keep this feature non-compliant for now.
Le Hoang Quyen's homepage 
I offer my heartfelt congratulations on this project. It solves a huge problem for my product, CartoType, which is a portable map rendering library that uses OpenGL ES 2.0 on all platforms. I haven’t got the time to create and support a separate graphics system for iOS only, so Apple’s announcement that it was deprecating GLKit was a heavy blow. I’ve got MetalANGLE working with CartoType and it seems to function perfectly.
Can you confirm that it is impossible to create a fat binary framework for MetalANGLE that will work on both an iOS device and a simulator?
LikeLike
Hi, it should be possible to create fat binary for simulator and device. You have to do it manually using lipo. My default xcode project just creates separare libraries currently.
LikeLike