Built-in OpenGL on macOS works a little bit different from other platforms like Windows or Linux. On Windows, system-provided opengl32.dll
doesn't actually implement OpenGL but is rather a proxy-library dynamically loading functions from a driver provided by a graphics card vendor. Graphics card vendors provide drivers independently from Microsoft and OpenGL capabilities can be implemented without Microsoft approval.
In contrast, macOS is much more closed system, where all graphic drivers are part of the system and cannot be (normally) updated without updating system itself. Apple holds the full control over OpenGL functionality in system and doesn't give graphics card vendors any way to deliver users more up-to-date OpenGL features (even when their hardware supports them on other systems).
This is quite unpleasant situation for a developer of multi-platform software, as Apple steadily pushes to their platform-specific APIs like Metal as the only choice, which implies a stronger vendor-lock and/or a more expensive development.
An alternative to using platform-specific APIs directly could be using a proxy-library implementing a multi-platform API on top of platform-specific API. So far, currently known options:
- Apple's OpenGL implementation over Metal.
Unfortunately, it has stuck on OpenGL 4.1, and there is no reason to expect the version will ever grow up; the library could be even removed in some newer macOS.
You may already notice that information provided by a system library on modern macOS versions mentions Metal, so that it is already a wrapper over other graphics API (although Apple may cheat by accessing some internals).
- MoltenVK, an open-source Vulkan 1.1 implementation over Metal.
This is not an OpenGL library, but Vulkan is another multi-platform graphics API and some references tells that MoltenVK in current state is solid enough for using in real projects, and Vulkan 1.1 is expected to give more features than outdated OpenGL 4.1 (though, I cannot confirm this personally, just my expectations).
- MoltenGL, a closed-source OpenGL ES 2.0 implementation over Metal.
As current implementation is limited to OpenGL ES 2.0 (e.g. much lower than Apple's built-in OpenGL / OpenGL ES libraries), it looks quite useless...
- Google ANGLE, an open-source OpenGL ES implementation over other APIs.
So far, ANGLE implements only OpenGL ES 2.0 over Metal, and OpenGL ES 3.1 (3.2 in progress) over Vulkan. So that with more layers like MoltenVK it could theoretically give more, if layers will not blow up ;). However, even OpenGL ES 3.2 doesn't look good enough compared to OpenGL 4.1. There is also MetalANGLE - an ANGLE library fork adding iOS support and some extra features.
- Zink, an open-source OpenGL implementation over Vulkan.
Zink already implements OpenGL 4.6 on Linux (supported OpenGL version depends on exposed Vulkan features and extensions).
There is a work-in-progress making this Mesa Gallium driver working on top of MoltenVK on macOS.
To me, it looks that sticking to OpenGL 4.1 (provided by Apple) for a while is quite a good option in case if your application may afford losing some features requiring higher version of OpenGL. Although Apple has deprecated OpenGL in SDK, so far it looks non-realistic that it will be actually removed in nearest future within newer macOS updates; even Apple M1 GPU received OpenGL 4.1 support on macOS Big Sur. Don't know if Apple has some strategy black-listing applications using deprecated APIs from AppStore market (e.g. system will support OpenGL, but you will not be able publishing application on AppStore), but this might become an issue in some future. Alternative OpenGL 4.6 implementations (on top of Metal or on top of Vulkan-on-top-of-Metal) might come in some distant future.
Relying on Vulkan-on-top-of-Metal implementations might be most provisional choice, but it will certainly require more efforts to develop a graphics engine on top of Vulkan instead of OpenGL. Cannot comment, though, how current MoltenVK implementation is comparable to native Vulkan implementations on Windows for the same graphics hardware (by features/performance/limitations). Of course, using some existing graphics engine already implemented on top of several graphics APIs (Vulkan/Metal/Direct3D/OpenGL/OpenGL ES) will also take this maintenance burden from you, but this is out of scope of initial question.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…