Jump to content

  • Log In with Google      Sign In   
  • Create Account


Metal API .... whait what

  • You cannot reply to this topic
71 replies to this topic

#1 imoogiBG   Members   -  Reputation: 1018

Like
0Likes
Like

Posted 03 June 2014 - 07:02 AM

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' 


Edited by imoogiBG, 03 June 2014 - 09:44 AM.


Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
3Likes
Like

Posted 03 June 2014 - 07:47 AM

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 - Software Engineer @Amazon - [swiftcoding]


#3 phantom   Moderators   -  Reputation: 6785

Like
9Likes
Like

Posted 03 June 2014 - 08:23 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.

#4 Ravyne   Crossbones+   -  Reputation: 6749

Like
6Likes
Like

Posted 03 June 2014 - 12:00 PM

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. 



#5 Promit   Moderators   -  Reputation: 6077

Like
0Likes
Like

Posted 03 June 2014 - 12:02 PM

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.



#6 MJP   Moderators   -  Reputation: 10218

Like
10Likes
Like

Posted 03 June 2014 - 04:18 PM

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


Edited by MJP, 03 June 2014 - 04:21 PM.


#7 Ed Welch   Members   -  Reputation: 463

Like
0Likes
Like

Posted 03 June 2014 - 04:50 PM

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



#8 Chris_F   Members   -  Reputation: 1937

Like
0Likes
Like

Posted 03 June 2014 - 04:52 PM


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.



#9 Glass_Knife   Moderators   -  Reputation: 3355

Like
0Likes
Like

Posted 03 June 2014 - 05:10 PM

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"
Indie Game Programming

#10 Hodgman   Moderators   -  Reputation: 27543

Like
5Likes
Like

Posted 03 June 2014 - 06:33 PM

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.

#11 Promit   Moderators   -  Reputation: 6077

Like
5Likes
Like

Posted 03 June 2014 - 06:37 PM

Given the course this conversation has taken, I'm booting it out of Horrors and into Graphics.

 

As far as the Metal API design, there's no real surprises (apart from the C++ shading language thing). I'm a little dismayed that command buffers are transient-only objects, as I'd much prefer to build them once and just reissue. Anything to fix the moronic way GL handles pipeline state is good. Anything to get away from the moronic way GLSL handles everything is good. Everything to [...] threading is good. The list just goes on.

 

In the meantime we're seeing multiple vendors clearly draw out battle lines on APIs, to the point that being dependent on GL may well become a significant competitive disadvantage. Most people aren't drinking the MultiDrawIndirect kool-aid (and it wasn't even in the cards for ES). The interesting questions are, just how much fragmentation are we going to see before things pull back together? Does GL have legs? Or will we get some new standard that is reliable across platforms and vendors?


Edited by Promit, 03 June 2014 - 06:40 PM.


#12 MJP   Moderators   -  Reputation: 10218

Like
2Likes
Like

Posted 03 June 2014 - 07:31 PM

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 don't think so. Collectively there's a lot of experience with this style of graphics programming among console developers, but unfortunately nobody can share anything publicly due to NDA's.

Probably the biggest issues with people looking to learn will be the manual memory management and synchronization. These things open the door to a lot of performance gains and memory savings, but getting it right can be very difficult. 

 

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

 

Yeah, it's pretty interesting. There's definitely been times when I wished that I could template a function so that I didn't have to write 4 versions of a function to handle the 4 float vector types. Using Clang also seems like a good idea, so that they can leverage that technology instead of subjecting their developers to years of working with a buggy compiler. However if I were them, I would be careful to make sure that it's not too difficult to convert from HLSL or GLSL. Does anyone know if they support swizzles?



#13 Hodgman   Moderators   -  Reputation: 27543

Like
3Likes
Like

Posted 03 June 2014 - 08:01 PM

Yeah they support swizzle sand a a lot of the other stuff you expect from a shading language:
https://developer.apple.com/library/prerelease/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/Introduction/Introduction.html


Regarding synching, I only had a very quick skim of the docs yesterday, but I thought I saw stuff on how to tell if a command buffer has executed yet in order to know whether it's safe for the CPU to read produced data or overwrite consumed data.

#14 clb   Members   -  Reputation: 1777

Like
5Likes
Like

Posted 03 June 2014 - 08:02 PM

This is an extremely funny and interesting development. After GDC this year, I would not have dreamed that in the AMD Mantle vs MS D3D12 race, I would be first reading Apple's docs instead on close-to-metal rendering API. And by the looks of it, there's a chance that Metal will be the first one of the three to ship out to public developers in a stable form. Some thoughts:

 

Was glad to see how it moves from core GLES2 spec towards D3D11-esque abstractions:

  • immutable state objects
  • no VAO-like abstraction, but proper separation of vertex format declaration and vertex data like D3D10+ has.
  • no shader program objects that causes vertex*fragment shader combinatorial explosion, but cleanly separate set()table like D3D8+ has.
  • by the looks of it, shader data bind to device and not to shaders/programs like GL and GLES has it. (which is completely retarded and silly)
  • based on UBOs and sampler objects, like D3D10+
  • proper support for offline shader compilation, like D3D9+. Runtime compile from strings still exists like in GL, so they didn't go the strict route like MS did on WinRT.
  • resource views in the form of MTLBuffer and MTLTexture, like D3D10+ resource view semantics.

 

Stuff that's there that D3D11 doesn't have:

  • Very nice machinery for starting and finishing rendering to a Framebuffer, to make buffer discard, preserve and resolve semantics explicit. Also makes it explicit that FBO switches are the most expensive ones that tiled GPUs have, so makes it easy to write code that takes that heaviness into account.
  • Command Buffers and Queues. Also like noted above, I was surprised that Command Buffers are transient (per-frame creatable single-use) and not permanent offline-creatable.

 

It feels like MJP said: the upgrade is largely to jump from GLES2 to an API that conceptually is much more like D3D11, there's not a great amount of enhancements on top of that.

 

Things that left me wondering:

  • Will it be available from C/C++ code? The examples are all with Obj-C, but perhaps they will provide a C header for accessing from C code?
  • Wth is the 16bytes of color data per sample restriction in Framebuffers? A single 4xFloat32 already consumes all of that and it's not possible to add multiple render targets after that. That is very low, and limits a lot of deferred rendering abilities, which I'd think the latest-gen hardware is very capable of already.
  • Where is their versioning/extension/feature query APIs? They don't seem to have any in place. Perhaps they'll solve that issue when the first update comes in, but I'd hope they'd develop something better than that. The current restrictions that are codified in numbers in the documentation alone are very arbitrary. I wish they will do something that does not resemble anything like the poor GL extensions mechanism, but instead something more direct (e.g. glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS) or more global (e.g. D3D feature levels), and not a confusing indirect "play a spec-lawyer across all spec versions and extension registryes" type of game. Since they can dictate, I imagine that won't be the case, gladly.
  • What is the error reporting machinery they have? I hope it's something explicit like in D3D debug runtime (exact errors to console + coarse error enum as return) and not a GL-like METAL_ERROR_INVALID_CALL generic guess-what-happened biz.

 

Overall, like Promit mentioned, I'm also very glad to see this development. It's a great shakeup, the race is on, and even if in the short term we'll have multiple players, the weakest will eventually drop out. Since performance+programmability tradeoff is this time the technical merit being judged here, there's a good chance that OpenGL will get a good blow and have to reform itself properly this time, and not like the halfbaked AZDO extensions that they're coming up with. I really hope that *each* of these succeed and very well, to the point that Google will feel threatened on their Android platform with GLES3 only, which would pave the way towards a future where OpenGL as a technology either gets completely rewritten, or sunset as a legacy technology. One can always dream ;)


Me+PC=clb.demon.fi | C++ Math and Geometry library: MathGeoLib, test it live! | C++ Game Networking: kNet | 2D Bin Packing: RectangleBinPack | Use gcc/clang/emcc from VS: vs-tool | Resume+Portfolio | gfxapi, test it live!

#15 Frenetic Pony   Members   -  Reputation: 1185

Like
2Likes
Like

Posted 03 June 2014 - 08:05 PM

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.

 

This is why I just want something like this from OpenGl, at least on the driver overhead front and if possible (hardware guys make it so!) with memory control. 1 API to rule them, One API to run them, One API to render them all, and in the code bind them (or bindless if that's your thing).

 

But that's Khronos, at least I got a Lord of the Rings reference out of them.


Edited by Frenetic Pony, 03 June 2014 - 08:09 PM.


#16 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
2Likes
Like

Posted 03 June 2014 - 08:29 PM


Using Clang also seems like a good idea, so that they can leverage that technology instead of subjecting their developers to years of working with a buggy compiler. However if I were them, I would be careful to make sure that it's not too difficult to convert from HLSL or GLSL. Does anyone know if they support swizzles?

Keep in mind that Apple's GLSL compiler has been running through Clang for some time now.

 


Where is their versioning/extension/feature query APIs? They don't seem to have any in place.

I'd imagine they'll just do the same thing they do for API releases: additive only, place the new features behind #ifdef METAL_SDK_MIN_VERSION >= 1.1 guards.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#17 MJP   Moderators   -  Reputation: 10218

Like
0Likes
Like

Posted 04 June 2014 - 12:14 AM

  • Wth is the 16bytes of color data per sample restriction in Framebuffers? A single 4xFloat32 already consumes all of that and it's not possible to add multiple render targets after that. That is very low, and limits a lot of deferred rendering abilities, which I'd think the latest-gen hardware is very capable of already.

 

I would assume that they're just exposing the limitations of the on-chip framebuffer used by PowerVR GPU's.



#18 Hodgman   Moderators   -  Reputation: 27543

Like
3Likes
Like

Posted 04 June 2014 - 12:22 AM

They mention a 4xMRT limit, so 4 x 4x32bit follows on from that anyway, seeing as 4x32bit is the fattest texture format biggrin.png

But yes, a "feature level" API would be nice, so you can ask the device what kind of limits it actually has.

 

BTW, I wouldn't dare use 4 x 4x32bit on the nextgen consoles! That's way too much bandwidth -- At 1080p, that's over 120MiB of framebuffer!

(or if you assume a perfectly optimal only 1 write followed by 1 read per pixel, then at 60Hz that's 14.8GiB/s of bandwidth)

3 x 4x8bit is a pretty standard setup for deferred rendering, and even that's uncomfortable from a bandwidth point of view...

 

Keep in mind that on Xbone, you want to keep your frame-buffers under ~30MiB! 3 x 4x8bit plus a depth buffer just barely fits in 32MiB of ESRAM.



#19 Olof Hedman   Crossbones+   -  Reputation: 2642

Like
3Likes
Like

Posted 04 June 2014 - 01:15 AM


Will it be available from C/C++ code? The examples are all with Obj-C, but perhaps they will provide a C header for accessing from C code?

 

Since you can write C/C++-code in obj-c files, it should be pretty easy to integrate an Obj-C graphics api into an existing C/C++ engine, just implement your backend in a .m/.mm-file instead of a .c/.cpp-file

 

That fact also makes a C-version of the api a bit unnecessary, it would just be a more or less 1:1 wrapper of the api with little or no gain.



#20 clb   Members   -  Reputation: 1777

Like
0Likes
Like

Posted 04 June 2014 - 01:31 AM

They mention a 4xMRT limit, so 4 x 4x32bit follows on from that anyway, seeing as 4x32bit is the fattest texture format biggrin.png

But yes, a "feature level" API would be nice, so you can ask the device what kind of limits it actually has.

 

BTW, I wouldn't dare use 4 x 4x32bit on the nextgen consoles! That's way too much bandwidth -- At 1080p, that's over 120MiB of framebuffer!

(or if you assume a perfectly optimal only 1 write followed by 1 read per pixel, then at 60Hz that's 14.8GiB/s of bandwidth)

3 x 4x8bit is a pretty standard setup for deferred rendering, and even that's uncomfortable from a bandwidth point of view...

 

Keep in mind that on Xbone, you want to keep your frame-buffers under ~30MiB! 3 x 4x8bit plus a depth buffer just barely fits in 32MiB of ESRAM.

 

Oh, perhaps I read that wrong. The docs state "A framebuffer can store up to 16 bytes of color data per sample."  instead of e.g. "A framebuffer can store up to 16 bytes of color data per sample in each color attachment point."  so I understood that the total amount of bytes is accumulated over all used attachments. If the limit is 16 bytes for each attachment, then that's of course adequate for most uses, however stating such a limit is odd since I don't know of any pixel formats where a pixel takes up more than 16 bytes anyways. I guess there are some exotic RGBAxFloat64Bit that this would limit, but I haven't even heard of such a thing in D3D/GL land.

 

 

 


Will it be available from C/C++ code? The examples are all with Obj-C, but perhaps they will provide a C header for accessing from C code?

 

Since you can write C/C++-code in obj-c files, it should be pretty easy to integrate an Obj-C graphics api into an existing C/C++ engine, just implement your backend in a .m/.mm-file instead of a .c/.cpp-file

 

That fact also makes a C-version of the api a bit unnecessary, it would just be a more or less 1:1 wrapper of the api with little or no gain.

 

This is basically saying "since you can access the API in Objective-C, there's no point in providing a C/C++ API"? I was pondering exactly whether it was possible to avoid having to write Objective-C to access the API.


Me+PC=clb.demon.fi | C++ Math and Geometry library: MathGeoLib, test it live! | C++ Game Networking: kNet | 2D Bin Packing: RectangleBinPack | Use gcc/clang/emcc from VS: vs-tool | Resume+Portfolio | gfxapi, test it live!





PARTNERS