MGL – OpenGL 4.6 on Metal

&gt; I didn&#x27;t build this for conformance I just wanted to program OpenGL on the MacOS platform<p>That&#x27;s a bit of a red sign. It may work on your machine for your application. Conformance tests are a great mechanism to understand how it&#x27;s going to work for <i>other</i> applications you haven&#x27;t tested. Hooking up OpenGL CTS on macOS shouldn&#x27;t be too hard - we got the Vulkan CTS running there a while ago.<p>Practically speaking, this project is interesting. While generally I&#x27;d recommend looking at Vulkan instead of OpenGL 4xxx (as opposed to, say OpenGL ES 3.1), in this case Vulkan -&gt; Metal is much more involved than OpenGL -&gt; Metal. The low level abstractions of Vulkan just don&#x27;t play that well. For example, MoltenVK doesn&#x27;t really record any command buffers before you submit(), and that&#x27;s an abstraction failure. So OpenGL -&gt; Metal is an interesting way to have portable code with a more flexible (better?) abstraction, assuming you can make it work :)

OpenGL is huge. It&#x27;s probably a better idea to use the shared code in Mesa and write a Gallium to Metal driver. That&#x27;s how Zink (GL on Vulkan) and Microsofts GLonD3D12 work.

Related: MoltenVK is now compliant with Vulkan 1.2.<p><a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;MoltenVK-1.2-Vulkan-Apple" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;MoltenVK-1.2-Vulkan-Apple</a>

How does this compare to ANGLE or the MetalANGLE fork, assuming I have some renderer code that already works on both OpenGL 3.2 core profile and OpenGL ES 3.0? (We are already using ANGLE on Windows with the D3D11 backend and might consider using something similar to stop relying on the &quot;deprecated&quot; native OpenGL implementation on macOS.)

It’s annoying that Apple already has an implementation of OpenGL on Metal, but they don’t share the source and they also put up a lot of deprecation warning noise to discourage you from using it.

Cool. I like (!= love) modern OpenGL and use it every now and then. I don&#x27;t currently use any Apple product or service, but I have been forced to a couple of times, and I find their bully approach to deprecating stuff very annoying.

The readme doesn&#x27;t say if this works on iOS, which would be an upgrade from Apple&#x27;s OpenGL ES implementation.<p>OpenGL ES works great on curent iOS hardware&#x2F;software but the Simulator support is broken with newer iOS images. In the Simulator, GL ES is now unusably slow, buggy, crashy.<p>I have an app store Mac&#x2F;iOS app which is written twice, but the two versions share lots of source, including all the GL rendering code, which is complicated. My strategy has just been to silence the GL deprecations and carry on, as it&#x27;s not worth the time to rewrite the renderer in Metal, and the performance is great on modern GPUs. I just do cosmetic updates to the UI code as needed.

Zink + MoltenVK can do that too in a pinch, no?

Nice to see that someone does apples job here… plain stupid for devs that they don’t support OpenGL.

I have very, very, rarely opengl only games. Most are vulkan.<p>Latest unity engine with their new universal 3D pipeline seemed to do it for good.<p>unreal engine 4&#x2F;5 don&#x27;t even have opengl anymore as far as I know.<p>Godot4 engine has a vulkan backend, but it seems it needs more testing.<p>I play on native elf&#x2F;linux.<p>Then, games which run on rottenfruitOSes without an engine with a native metal backend &quot;just need&quot; to ship with the vulkan-&gt;metal translater (molten something).<p>As far as I know, this is how CSGO runs on vulkan: valve did package the game with the DX(11?12?)-&gt;vulkan translater.