iOS Metal ANGLE Prototype

[danoli3]

iOS Open GLES 2.0 GLKit to MLGKit / MetalKit Wrapper for openFrameworks

WiP : Bleeding edge developments here but for those interested

Automatically converts OpenGL ES 2.0 to Native Metal Change no code at the openFrameworks level for all Open GL ES calls

Set the main.mm/main.cpp to use METAL_KIT instead of GL_KIT or UI_KIT

Currently setup for iOS. Can be converted to include tvOS and macOS Catalyst in further developments Could be adapted also for macOS if you use custom renderer instead of GLFW

Metal Framework: Add to /libs/ https://drive.google.com/file/d/10aeY5IbXSyRSRT_jWlarsnxbIbLNlKmL/view?usp=sharing

• [x] Core Project to adapted to Metal ANGLE
• [ ] Example Project
• [ ] tvOS
• [ ] Catalyst
• [ ] Apothecary Script to build framework

[ofTheo]

Wow, very cool! If macOS support was added would this support all programmable OpenGL pipelines macOS currently supports?

[danoli3]

iOS 16.0 + now Renders the openFrameworks (and all other) Open GL ES 2.0/ OpenGL ES 3.0) Contexts directly in a OS Level version of ANGLE - which is unfortunately leading to Garbage collector / maxing out of VBO / Mesh and Textures with base oF datastructure use.

It is likely there is some leaks of GL objects in the ProgrammableRenderer that are not contained and within the scope of a Metal or Vulkan or Directx12 wrapper these leaks fill up the GPU buffers and texture memory leading to stalls / hitches and the Graphics card fighting to allocate / release required amounts per draw. I've seen the same symptom in many Unity Projects in the past that were basically impossible to release due to these bugs, when same project the Open GL ES output was fine (mostly gl devs got away with a lot due to glFlush()) - and the same rendering on Metal would lead to 30 fps or 10 -15fps under after a set duration of the game/app running (or once the memory or vertex position arrays were filled).

Fixes I applied in those projects were fixing leaking temporary textures and vbos allowing Metal rendering to be - so we need to look into this. ofVboMesh / Mesh seems to be a leak

oF iOS Performance as is: It will all still render and work: however overtime the buffer leaks will peak from avg rendering time of 1ms up to 16 ms with many 32 ms hitches (on latest iPhone 14 Pro) yep- that target should be 8ms as well

METALKit using this MGLKit Angle wrapper for us I'll recommended for all projects since control is given directly back to us the engine developers to release / allocate critical data structures such as buffers / textures rather than it potentially be an issue at Apple's / Kronos (which it could be for iOS 16) I'll be further investigating and pushing some fixes

[danoli3]

Wow, very cool! If macOS support was added would this support all programmable OpenGL pipelines macOS currently supports?

Yes the examples I am basing a lot of my conversion for iOS supports macOS, Catalyst, tvOS, iOS - all from pure OpenGL / OpenGL ES 1.0/OpenGL ES 2.0/OpenGL ES 3.0

It's very very stable and yeah Apple now even using it at OS level in some fashion for iOS and for Ventura ! You can see this in the Xcode Profiler