Dranix, the move from OpenGL 2.1 to 4.1 is hugely significant for games on OS X. Having previously worked at Feral porting games to now working on the Mac version UE4 at Pitbull Studios for Epic, I can tell you Apple's GL 4.1 is night and day better than their 2.1 GL.
It was a real frustration at Feral that games would ship without the advanced rendering features, like tessellation in Batman Arkham City because we were at the time restricted to OpenGL 2.1 which doesn't support anything like the features of D3D11. Nor was it especially performant when compared to latter-day D3D9 renderers. Some games would be notably slower on the Mac due to the way we had to implement certain features on GL 2.1 that could have been improved on GL 3.2 or later (texture copying springs to mind here). Unfortunately D3D9 games tended to make some use of the old fixed-function pipeline so we couldn't move up to the 3.2 core profile as that removes fixed-function support. I seriously looked into whether we could use Regal when porting Batman Arkham City for just that reason, but I couldn't get it to work in that game well enough.
Newer game engines like UE4 or those used by the new Tomb Raider & Hitman from Feral, are designed for D3D11 from the get-go, so no fixed-function pipeline and much cleaner mapping to the OpenGL 4+ feature-set. The only problem is that base D3D11 features were added in OpenGL 4.2 and 4.3 but Apple only supply 4.1.
The examples I gave were the three extensions that would most help to add Shader Model 5 rendering support to Mac UE4, which is currently limited to Shader Model 4 due to their absence. I'm not crying about this & I'm not angry either. It'd just be nice to have them so that our users can access the full potential of UE4 & their GPUs.
GL_ARB_texture_view is the equivalent of D3D11 Shader Resource Views, allowing you to create an alias to a subset of another texture's data, potentially also reinterpreting the format. This is more efficient than changing the original texture object's GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL and/or copying data between textures of different but compatible formats.
GL_ARB_shader_image_load_store is OpenGL's equivalent to D3D11's RWBuffers - they let you perform arbitrary read and most importantly, write, operations to a single texture layer. You could try and emulate this by copying the texture data to a PBO then binding it as a GL_TEXTURE_BUFFER, while simultaneously binding the texture as a colour attachment to write to, but that'll end up being more complicated and slower. Depending on the driver's capabilities you might also be unable to write to the same formats. A further and potentially crippling limitation would of course be the inability to mimic this extension's most useful feature - writing data in one shader and then reading it in a following one with quite a degree of control over synchronisation e.g. writing data in the vertex and reading in the fragment using atomic load/store.
GL_compute_shader allows you to use GLSL to perform highly parallel general computation on the GPU from within the OpenGL pipeline, analogous to DirectCompute. This means you need only support two shader languages - HLSL and GLSL since compute is just another shader stage. It also avoids all the tedious & slow manual binding of GL objects to CL using the CL_GL_interop extension, which also breaks if you change certain GL object properties (like GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL). Finally, most game engines aren't designed to batch all the compute work to one part of the frame, since consoles & DirectCompute don't require it, so the required manual GL-CL context swap can be costly as you switch back and forth between GL & CL from one render pass to the next.
The big limitation in OpenCL 1.2 in Mavericks is the limited support for GL textures and texture sampling in the GL_interop extension. There's no support for mip-mapped textures, only a single texture level can be exposed to CL. Nor can it perform texture filtering or binding from some of the GL texture types. OpenCL 2.0 adds more texture types as well as mip-mapping and linear filtering support, so it is better, but it still isn't ideal compared to GL_ARB_compute_shader.
