Linked by Thom Holwerda on Fri 27th Jun 2014 17:42 UTC
Apple

Metal. If the name sounds hardcore, it's because it's a hardcore improvement to the way games will be able to perform on iOS 8. Metal represents a much more no-nonsense approach to getting the most out of the Apple A7's gaming performance, assuring users of the iPhone 5S, iPad Air and iPad mini with Retina display that their devices will continue to be top-notch game systems come this fall.

Right now in iOS 7 software called OpenGL ES sits in between the game and the core hardware that runs it, translating function calls into graphics commands that are sent to the hardware. It's a lot of overhead. And iOS 8 is getting rid of a lot of it.

A nice overview of Apple's Metal.

Thread beginning with comment 591486
To read all comments associated with this story, please click here.
Simple question
by Luis on Fri 27th Jun 2014 19:00 UTC
Luis
Member since:
2006-04-28

I'm completely illiterate when it comes to graphics and games, so when I hear all this buzz about new graphics APIs like Metal and Mantle, I can't help to ask myself how this works.

I believed (probably wrongly, it seems), that for a graphics API you first and foremost needed the GPU (the hardware) to support certain features, and then the drivers to enable the usage of those features. For example, when they release a new GPU (Nvidia, AMD, etc...) and they say that it supports DirectX 11 and OpenGL 4.2. Does this just mean that the drivers for that new GPU support those APIs? Is it unrelated to the hardware itself???

If so, my old Gen 4 Intel IGP that supports OpenGL 2.1 (I use Linux), could potentially support OpenGL 4.2 if someone actually cared to implement it in the drivers???

And if not, if hardware support for those features is needed (like a CPU that supports SSE4, etc...), how can Apple announce a new graphics API without partnering with GPU manufacturers to provide those features that Metal should offer?

Sorry if it's a completely silly question, but it really makes me wonder and I couldn't find any good answer to it by just searching.

Reply Score: 3

v RE: Simple question
by tidux on Fri 27th Jun 2014 19:17 in reply to "Simple question"
RE[2]: Simple question
by Luis on Fri 27th Jun 2014 19:56 in reply to "RE: Simple question"
Luis Member since:
2006-04-28

Hhmmm, did you check that? I read everywhere (including the article above) that they use a PowerVR G6430 by Imagination Technologies. That's "off the shelf" hardware, even if Apple might order the manufacturing to Samsung or whoever.

Actually the new Intel Moorfield platform uses that same GPU (though manufactured by Intel itself, I believe).

In any case, does your answer mean that yes, the graphics API needs hardware support in the first place? And that this GPU announced in June 2012 already supported the Metal API?

Reply Parent Score: 3

RE: Simple question
by burnttoys on Fri 27th Jun 2014 20:08 in reply to "Simple question"
burnttoys Member since:
2008-12-20

Hi, I'll try and chip in a bit. I have some understanding in this area (I've worked for 3DLabs, ZiiLabs, Imagination Technologies, Samsung and worked with Qualcomm and ARM all on GPU and GPU driver technology as well as some combined HW/SW systems from "back-in-the-day" based on 3Dfx VSA100/200 and Ti 32xxx DSPs).

Firstly, you're spot on with the SSE4 analogy - if the GPU actually lacks a certain feature then it would be VERY hard to support that concept efficiently (to the point where it might not be worth it). For example, OpenGL ES 3.0 fully supports floating point textures. Much older hardware simply can't do this (there may be work-arounds).

However, over the last few years - and especially now (Qualcomm 3xx, Imgtec 5 and 6 series, ARM Mali 6xx) the GPU isn't so much a GPU as a massively multi-threaded compute engine that also has some nice graphics features such as Z-Buffering, alpha blending and really nice texture look-up unit. Having scanned the Metal spec it seems that all of these have been kept as "first-class-concepts" in Metal - probably because they are fantastic optimization targets.

The REALLY big win from this seems to be the OpenCLish command buffer concept. OpenGL ES has a command buffer but you have no real control. You just use programs, set parameters, load buffers and that's it. I _think_ what Apple are offering up here is quite useful especially from a multi-core perspective.

Firstly it seems that damn near everything is deferred, that is work goes into command buffers and gets done when you "swap/flush/execute" (different API's - different parlance).

Secondly you can have multiple command buffers issuing work to the GPU - this REALLY helps multi-threading and multi-core programming which is EXTREMELY awkward using GLES. This should help GUI programming nicely too - that is you can parallelise the drawing of "widgets" and the like.

Remember - Apple aren't offering more fill-rate, texture through-put or vertex shading abilities (although in modern designs fragment and vertex programming tend to use the same ALUs but will have different output formats and optimization strategies).

Apple are offering better control. No longer will "useProgram" take an eternity - because that command is added to a queue and will processed along with many others. The state changes the app requires can be minimized 2 ways - firstly there is much more fine-grain control over the commands the GPU will execute. Secondly - you can have multiple command buffers for threading or so that you can set up several drawing commands without the restriction of only a single "program" being in use within the GL driver at any given time. GLES is highly serial and often synchronous. Indeed it is very hard to make GLES purely async.

Other optimisations come from shared buffer accesses instead of continual uploads - something barely standard in GLES (although present - esp for vertex arrays).

Hope this makes some sense - written in a hurry - I should be doing my accounts!

Reply Parent Score: 10

RE[2]: Simple question
by Luis on Fri 27th Jun 2014 20:33 in reply to "RE: Simple question"
Luis Member since:
2006-04-28

Thanks for that very detailed answer!

So it seems that modern GPUs are quite more "generic" than they used to be, so they give more flexibility for the way software can use them. That's why Metal can actually exist without a specific hardware design for it.

It sounded ironical to me when you explained this because I remember somewhere around 2008 (?) that Intel had some "project Larrabee" (that never was realized) that had this very same principle, and Nvidia was laughing a these efforts saying it looked like a GPU designed by a CPU team (or something similar). And in the end the GPU market has gone exactly that way for allowing GPGPU and things like Mantle and Metal.

Reply Parent Score: 2

RE: Simple question
by CaptainN- on Fri 27th Jun 2014 20:18 in reply to "Simple question"
CaptainN- Member since:
2005-07-07

OpenGL and D3D have a lot of overhead in their own abstractions.

Basically, you spend your time in those APIs putting data into formats that those APIs require, then the platform drivers convert that into something the GPU can use.

Then shaders (which also have to be compiled and messed with by drivers) operate on that data in batches. Because GPUs are massively parallel, they operate on a bunch of data at once, but you can't do 3 things to half the data and another three things to another set of data, etc. You have to do one kind of operation for all the data in the current buffer, then switch to a new buffer and do another type of operation. 3D engines will often do all the flat surfaces in one pass, switch the mode (shaders, etc.) then render all the shiny surfaces, etc.

The drivers do their best to optimize, but OpenGL and D3D are platform agnostic - not hardware specific APIs. This means the abstractions they deal with don't match the hardware directly, which causes overhead. Those drivers are also filled with a lot of ancient cruft that's hard to change without breaking things (this is more true for AMD). This means that developers have to jump through hoops to optimize (or fix bugs) on specific hardware - although it mostly means is they won't bother.

AMD's Mantle and Apple's Metal are ways to open the lower level of the actual GPU hardware to developers so they can better optimize their own work, and avoid the overhead of a generic API, freeing the CPU which normally would have to do a bunch of extra translation work to do other things. It should also open the door for some new kinds of operations that aren't feasible now - which is far more exciting than just the performance boost.

nVidia on the other hand often will optimize developers' games themselves and ship those optimizations in their own drivers to override whatever shipped in a particular game. They are so secretive I wonder if they'll ever release a similar low level API.

I'd guess the low level API coming for D3D has a very very long lead time because of how difficult it will be to create a low level API that works on many different GPU platforms (not just nVidia and AMD, but all the mobile GPUs). I wouldn't hold my breath for an OpenGL equivalent any time soon.

BTW, it's fun to watch the cycles here - we had early proprietary 3D hardware "accelerators" like 3DFX, with their own custom APIs like Glide, and then everyone clamored for a standard (OpenGL and D3D). And now here we are 20 years cheering the return of proprietary APIs. :-)

Reply Parent Score: 7

RE[2]: Simple question
by moondevil on Sun 29th Jun 2014 15:54 in reply to "RE: Simple question"
moondevil Member since:
2005-07-08

BTW, it's fun to watch the cycles here - we had early proprietary 3D hardware "accelerators" like 3DFX, with their own custom APIs like Glide, and then everyone clamored for a standard (OpenGL and D3D). And now here we are 20 years cheering the return of proprietary APIs. :-)


Proprietary APIs never went away. That consolidation only happened on desktop systems.

Reply Parent Score: 3

RE: Simple question
by Drumhellar on Fri 27th Jun 2014 20:54 in reply to "Simple question"
Drumhellar Member since:
2005-07-12

If so, my old Gen 4 Intel IGP that supports OpenGL 2.1 (I use Linux), could potentially support OpenGL 4.2 if someone actually cared to implement it in the drivers???


Not speaking for this GPU specifically (But, I'm going to assume it applies to this), but, API changes in OpenGL and DirectX frequently require new hardware changes to support things like new texture compression formats, new texture formats, or floating point numbers.

Sometimes, features can be implemented in the driver - tessellation can be implemented in software and cover some use cases without a huge performance hit, but this isn't always the case.

Reply Parent Score: 4

RE[2]: Simple question
by Luis on Fri 27th Jun 2014 21:13 in reply to "RE: Simple question"
Luis Member since:
2006-04-28

I see. So a graphics API does require hardware support, but the hardware support for this features is a rather generic thing and not something specifically tied to that API. And Metal makes use on the hardware features already available in current hardware, but just uses them in a different way. That makes sense, thanks.

Reply Parent Score: 2