Metal API .... whait what

Started by
70 comments, last by Krohm 9 years, 11 months ago

Apples rendering API:

http://www.ubergizmo.com/2014/06/apple-metal-graphics-api-to-boost-ios-game-performance/

EDIT: It was not intended to to post this topic on "Coding Horror" I've missclicked the 'GDNet Longue'

Advertisement
It's not really a coding horror. AMD has introduced Mantle to fill this niche, DirectX 12 is pitched in the same direction, and console GPUs have been programmed this way for decades.

Most AAA game studios and engine developers already target at least 3-5 separate graphics APIs (DirectX 9, OpenGL, XBox 360, PS3, and Wii), with the leaders targeting many more (DirectX 11, OpenGL ES for android/iOS, XBox One and PS4). So adding another platform to their rendering backend is not a huge deal, especially if it gives them a competitive advantage.

And the advantages are pretty big - not only do you get a drastic increase in the number of draw calls which can be performed in a frame due to lower setup overhead, but explicit management of memory gives you a degree of control completely unobtainable through traditional OpenGL/DirectX drivers.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

We are now in a fun situation where 3 APIs look largely the same (D3D12, Mantle and Metal) and OpenGL - while this won't "kill" OpenGL the general feeling outside of those who have a vested interest in it is that the other 3 are going to murder it in CPU performance due to lower overhead, explicate control and the ability to setup work across multiple threads.

It'll be interesting to see what, if any, reply Khronos has to this direction of development because aside from the N API problem the shape of the thing is what devs have been asking for (and on consoles using) for a while now.

I would hope that this might finally convince Khronos of the need for a more drastic re-imagining of OpenGL. Hell, Introduce a new open, low-level, cross-platform 3D API if they have to, but they need away to break away from the legacy and move in a different direction than what they are now. Their latest proposed enhancements gain performance but lock you into certain patterns that you or your program might not favor, and still places a lot of burden on drivers.

Everyone else is ready to move to the automobile, and meanwhile Khronos intends to build a better horse.

Equally interesting is what this might mean for Android -- GLes (or Unity) has been the traditional cross-platform layer between iOS and Android Graphics. Android mostly lacks the high-end mobile gaming market already, but when Metal becomes the API of choice for AAA-style mobile games, and it looks to be a stone's throw from D3D12, it might boil down to iOS and Windows Phone serving up high-end mobile games.

throw table_exception("(? ???)? ? ???");

I for one am very happy to see Metal -- much more so than I care about Mantle or D3D 12. The GL ES API is a ridiculous amount of overhead.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

People keep saying it's Apple's version of Mantle/D3D12, but to me it looks a lot more like D3D11. No manual memory/sync management (or am I just missing that somewhere?), no bindless textures, etc. So far the only solid step above D3D11 that I've noticed is that there's actual API's for managing command buffer submission, and they allow for free-threaded command buffer creation. The fact that they don't let you re-use command buffers across frames is a bit of a bummer, as are the separate command buffers for rendering/compute/copy. However I would suspect that this is a reflection of how the underlying hardware works on their platform. Probably the biggest issue is the apparent lack of Draw/DispatchIndirect functionality. Compute is a whole lot less useful without that.

Still, it's cool to see that Apple cares enough to give developers a way out of the nightmare that is OpenGL ES. Too bad they had to make it an Objective-C API. dry.png

I heard that the metal API only works on A7 devices.


Too bad they had to make it an Objective-C API.

Would it be better if it used their new Swift (supposedly Obj-C without the C) language? Because the only things better than Objective-C is a new language based on Objective-C.

I can't imagine that OpenGL will just go away. It is used by so many other things besides games. I figured with all the effort that Valve has put into Linux and OpenGL that it will force them to be relevant.

My big question is what to start learning now to stay relevant? Are there books on this new way of doing graphics, or is it still too "bleeding edge"?

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

OpenGL has made it's bed and now has to lie in it. If they'd just done their job, then D3D wouldn't have won the war on windows, and Mantle/Metal wouldn't have been born.
Suddenly, Windows is conquered by D3D, wih Mantle being he underdog, Apple is breaking the GL monopoly, and AMD will soon be invading the Linux bastion with a Mantle army too!

@MJP - yeah it's not quite on the same plane as D3D12/Mantle, but they seem to have used he same consolidation of state into a pipeline object (blend, fetch, mask, programs), and the thread able command buffer model. From what I read, they only expose pixel/vertex/compute shaders too (which matches GLES, but not Mantle/D11?)...

The single-threaded command buffer model in GL is one of the biggest gripes... And the resource managment... And the state management... And the shader compiler... :lol:

Metal's C++ based shader language is an interesting idea. Generics/templates might be fun.

This topic is closed to new replies.

Advertisement