It's exactly the spirit of glshim, but Regal is a better example of a project targeting this specific functionality (getting GL 4.3 / ES 3.0 to work on any GL target with shaders).
Maybe the description I gave was too limiting. But there are API features that are more there for programmer convenience or features that can be emulated with a reasonable amount of overhead, and then there are features that need specific hardware support exposed and can't be emulated in a way that's remotely practical.
If OpenGL ES 2.0 was enough for a decent level of support without a completely unreasonable performance overhead I think they would have done it and I think they're in a better position than we are to make that claim. Sonicadvance1 has been adamant that ES 2.0 isn't good enough. In fact, even ES 3.1 is not enough to support all features, as per this thread:
https://forums.dolphin-emu.org/Thread-nvidia-tegra-x1?pid=352286#pid352286
Explains why geometry shaders and atomic images are necessary, and here:
https://dolphin-emu.org/blog/2015/04/01/dolphin-progress-report-march-2015/
Full occlusion query support is needed for a feature too. But ES 3.0 was enough to get games working at a level they considered worthwhile so that was the baseline.
However, the SGX drivers implement some extensions to OpenGL ES 2.0 that bridge part of the gap. There's a list here:
http://e2e.ti.com/support/omap/f/885/p/354512/1244473#1244473
It doesn't look like the drivers TI's using support all of the extensions IMG have enabled on other platforms and I doubt we'll see more progress in this area. It does have GL_OES_depth_texture, so that's something.
Sonicadvance1 talks about some of the GL ES 3.0 features Dolphin relies on here:
http://ouyaforum.com/showthread.php?1402-A-question-about-OpenGL-ES-extension-supportTwo of the three extensions listed below are available (including the one he says is really a requirement), and GL_NV_uniform_buffer_object appears to have an equivalent in GL_IMG_uniform_buffer_object, but GL_NV_framebuffer_blit and GL_NV_map_buffer_range don't appear to have equivalents. Later in the thread he mentions GL_EXT_frag_depth, which also isn't supported on OMAP5.
But suffice it to say, there was a never a port targeting Tegra 4 (despite him getting a Shield) which has more extensions than Tegra 3, including the missing 24-bit depth he saw as a major problem.
Maybe ask him directly what the reality/consequences would be of trying to fit Dolphin to OMAP5's extension set.
