It would be a good riddance IF there was another universal API (Vulkan) and they would adopt it in substitution.

The fact they want to force game developers to use instead Metal is... ridiculous, especially considering the extremely low macos marketshare, particularly outside US.

Sometimes at work I daydream about this alternate reality where we let go of the idea of an universal API on top GPUs and just let vendors publish some ISA and hardware-specific libs/drivers/docs. I'm sure people would figure out nice (and less nice) abstract libraries on their own just as well.

It's so frustrating to read what the GPU is actually capable of (for example in the intel PRMs) and to know that there is absolutely no way to get the driver's compiler to do the right thing in a reliable way.

I mean imagine if icc was the only x86 compiler.

It's ok man, we can just keep piling on more turtles.

I do get the impression the new more-explicit APIs help somewhat with that, no?

All game engines that matter already support Metal, plus writing platform specific APIs is something that professional game developers are used to do since Atari 2600.

What do you think about them forcing you to use Swift or Objective-C for this? Forcing you to use languages that use ref counting and object oriented pointer tables that are traversed at runtime? How much of the gains does objc_msgSend eat up? I though you are against such things?

How ugly would the JAI code to need to be to interface with this?

I wish they had a simple Metal C API, but their new API comes with a bunch of Objective-C baggage.

Have you actually used the API? When it comes to submitting geometry and textures (some of the biggest bottlenecks), it's exactly the same as in C. You pass a pointer to your buffer of bytes and they get copied to the GPU for you.

When you're calling any library, that simple C call invariably goes somewhere else inside the library itself. For OpenGL this is because there's always hooks for introspection, or because the GPU driver wants to implement something themselves, etc. For many other libraries it's just because people don't feel like they've written "production quality code" unless it goes through a bunch of hoops and ends up in some method with five underscores in the name.

In Metal the Obj-C abstraction is part of the design and used to eliminate any other abstraction people would want to introduce. The objects you get back from the API are implemented straight in the GPU vendor code, and the debug tools can swap the methods out for extra validation, recording, etc.

Any overhead coming from objc_msgSend is minuscule compared to the gains from things like better serialization of GPU-bound tasks and not having to synchronize repeatedly with the CPU.

If you're worried about refcounting, use ARC (which you have to with Swift anyway). First, the compiler is very smart about optimizing away retain/release/autorelease calls whenever it can. Second, when those calls do have to be made, they're implemented using vtables, and never hit objc_msgSend() in the first place.

I think it is about time industry relevant OS vendors start to move away from C, kudos to Apple.