metal-cpp VS MoltenVK

My understanding is the proliferation of “XYZ-cpp” AI frameworks is due to the c++ support in Apple’s gpu library ‘Metal’, and the popularity of apple silicon for inference (and there are a few technical reasons for this): https://developer.apple.com/metal/cpp/

This is basically also what the "official" C++ API for Metal does (https://developer.apple.com/metal/cpp/), it's an automatically generated bindings wrapper which calls into ObjC runtime functions.

I also dabbled a bit with this idea by parsing clang AST-dumps of macOS system headers:

https://github.com/floooh/objc-ast-experiments

Unfortunately this is very brittle, and also broke on ARM CPUs, I guess the shim code needs some ABI adjustments (famously, objc_msgSend has multiple "ABI shapes": https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...).

There's official C++-interface: https://developer.apple.com/metal/cpp/

It doesn't matter if the project driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/).

In the future, the question won't be "what language do I need to learn to code on this platform", but instead "are there language bindings for my favourite language".

this? https://developer.apple.com/metal/cpp/

Doesn't it just use objc/runtime.h and if anything is missing you can just add your custom api calls?

Metal has C++ bindings (which cover a full app lifecycle so you don’t have to touch Objective-C/Swift at all) but they’re based on the Objective-C memory model. There are some helper structs mimicking shared pointers, but you’ll still need to understand the basics of how an autorelease pool is used to avoid memory leaks and/or bad access crashes.

On https://developer.apple.com/metal/cpp/ check Foundation folder and all those nice Object::sendMessage().

https://github.com/KhronosGroup/MoltenVK

Translating between rendering APIs is not really the problem. The GPU design is more different than the API is.

Khronos maintains MoltenVk though, which is "official" as it gets: https://github.com/KhronosGroup/MoltenVK

...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), Microsoft doesn't support Vulkan either ;)

MoltenVK implements large parts of Vulkan on top of Metal for Apple systems. It isn't full Vulkan but it makes porting Vulkan games to OS X easier.

That's cool. Maybe I haven't thought enough about this. Let me check it out. FWIW it's this PR that you are referring to I think: https://github.com/KhronosGroup/MoltenVK/pull/1815/

For Metal specifically, they could adopt and contribute to Vulkan and get access to a lot more software. Right now you need to use a compatibility layer, and surely Apple could just support both APIs natively with much lower overhead. But they don't, because it nudges developers to stick to the Apple ecosystem instead of being able to support multiple platforms.

At the moment the most promising thing is MoltenVK (DX12 -> DXVK -> Vulkan -> MoltenVK -> Metal), but the development is not that quick mainly because there aren't tons of developer that works at the same time on the project. It's not actually a Metal related problem at the moment (they have a road map of things that they can be achieved with Metal 3 like Mesh shader and Geometry shader).

What you asked is already existed for at least 8 years. Yeah EIGHT years. It's called "MoltenVK". So far it's the only implementation of Vulkan for macOS. Basically it's a wrapper that runs on top of Metal API.