
Metal – Apple’s new graphics API - oflordal
https://developer.apple.com/library/prerelease/ios/documentation/Miscellaneous/Conceptual/MTLProgGuide/Introduction/Introduction.html
======
klodolph
Anything that provides access to GPU command queues is welcome. It's been
clear for a while that OpenGL and D3D are ill-suited to modern ways about
thinking about GPUs. This also explicitly supports multithreaded clients, each
with their own command queues.

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Miscellaneous/Conceptual/MTLProgGuide/Cmd-
Submiss/Cmd-Submiss.html#//apple_ref/doc/uid/TP40014221-CH3-SW1)

The shading language appears to be precompiled (which is sorely missing from
OpenGL) and based somewhat on C++11.

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40014364)

My concern is drivers: drivers for video cards on OS X haven't been as good as
Windows drivers. That, and of course the specter of another platform-specific
API. This invites a comparison with Mantle. I don't think either Metal or
Mantle will "win", but they're good prototypes for the next generation of GPU
APIs.

~~~
apetresc
As far as I know, Metal has only been discussed for iOS. Did I miss an OS X
announcement somewhere? Otherwise, the driver point is moot.

~~~
rm445
I'm daring to post from a position of ignorance, trusting intuition to be
correct. But this is a framework for shipping (graphical and other) workloads
over to the GPU. _Surely_ it isn't mobile-only?

Just for instance, Apple sell an extremely expensive workstation with two very
powerful graphics cards. Providing better ways to use a Mac Pro's GPUs is a
good way to sell more Mac Pros, and a way to unlock more computational power
as the power of CPU cores has levelled off.

~~~
sliverstorm
What we know: the stated goal of Metal is exactly the same as the goal of
Mantle; reducing CPU overhead.

Hypothesis 1: Metal aims to replicate that for iOS, while Mantle can be used
in the Mac Pro (which uses ATI cards)

Hypothesis 2: Metal could wrap around Mantle on OSX and some other similar
interface on iOS where Mantle is not available, for a unified Apple interface
without having to write their own ATI drivers

~~~
TazeTSchnitzel
Don't Apple already write their own graphics drivers on OS X?

~~~
sliverstorm
Sorry, I was unintentionally vague, I meant without having to write their own
version of Mantle. The other upside being if Metal wraps around Mantle, they
can still expose Mantle to software that targets Mantle.

~~~
TazeTSchnitzel
Ah, I see. That would make sense, though if they're trying to reduce overhead,
it might not be the best idea.

------
jarrett
It's somewhat scary to see new graphics APIs being introduced.

The fragmentation of OpenGL is enough of a headache, but at least it offers
some semblance of "write once, run anywhere." The introduction of Mantle and
Metal, plus the longstanding existence of Direct3d, makes me worry that OpenGL
will get no love. And then we'll have to write our graphics code, three, four,
or goodness knows how many times.

I know: It's not realistic to expect "write once, run anywhere" for any app
that pushes the capabilities of the GPU. But what about devs like me (of whom
there are many) that aren't trying to achieve AAA graphics, but just want the
very basics? For us, "write once, run anywhere" is very attractive and
_should_ be possible. I can do everything I want with GL 2.1, I don't need to
push a massive number of polys, I don't need a huge textures, and I don't need
advanced lighting.

~~~
zanny
OpenGL 5 _will_ happen in the next two years (and GLES 4) and it _will_ take
the wind out of all these alt-language sails.

I can't see Khronos making the same fuck up twice, as they did with Longs
Peak.

Yeah, it means depreciating a bunch of 3.x shit, and probably making another
profile, but this time they better do it right.

~~~
cwyers
I think it's reasonable to assume if an entity had fucked up once, they are at
least capable of doing so again.

~~~
fleitz
Even if they don't fuck it up, the half-assed implementations of it will.

------
higherpurpose
You can thank AMD for this one. This is exactly why I supported Mantle
initially - not necessarily because I thought Mantle will replace DirectX and
OpenGL, but because it would push all the others to adopt similar changes to
their APIs.

And this is exactly what happened, first OpenGL (through AMD's extension for
now at least), then Microsoft with DirectX 12 [1], and now Apple, too.

Before you get _too_ excited, though, remember Mantle "only" improved the
overall performance of Battlefield 4 by about 50%. It can probably get better
than that, but don't expect "10x" improvement or anything close to it.

[1] - [http://semiaccurate.com/2014/03/18/microsoft-adopts-
mantle-c...](http://semiaccurate.com/2014/03/18/microsoft-adopts-mantle-calls-
dx12/)

[http://hothardware.com/News/New-Reports-Claim-Microsofts-
Dir...](http://hothardware.com/News/New-Reports-Claim-Microsofts-DirectX-Rips-
Off-Mantle-Wont-Help-Xbox-One--But-Is-It-True-/)

~~~
danudey
From what I understand, it's more accurate to say that it reduces CPU use by
about 50% (rather than improving performance). If CPU is not your bottleneck,
you won't see a performance improvement. If it is (which is common these
days), then you'll have twice as many free CPU cycles on your main thread,
which will translate into however much improvement your GPU can muster.

~~~
sliverstorm
Even if CPU isn't the bottleneck, you ought to see some power savings.

Either way, it will make it easier to bolt a monster GPU onto a smaller, more
efficient CPU.

(What we do about GPU power consumption is a different problem...)

------
coldcode
This to me is more surprising than Swift. But it will make for difficult
platform decisions. But since there are 4 game platforms already working on it
(Unreal hasn't committed) maybe it's not a bad idea at all.

~~~
unphasable
I thought Unreal was 1st in line? Why would the be on stage as the poster
child for Metal yet not commit?

~~~
mikewhy
first was Unity, Unreal wasn't mentioned but Epic Games were.

~~~
CanSpice
Epic Games makes the Unreal Engine.

~~~
unphasable
good news: [http://i.imgur.com/ke0czgU.png](http://i.imgur.com/ke0czgU.png)

------
pjmlp
So OpenGL seems to loose support on the platform that helped to make it
relevant again.

~~~
dsl
You can still use OpenGL directly. I believe Metal is aimed more at engines,
so they aren't providing an abstraction of an abstraction of a system call.

------
oneofthose
This seems to be Apple's answer to Google's RenderScript. It is too bad big
companies (Google, Apple) are developing their own GPU software stack instead
of building upon and furthering existing frameworks such as OpenCL. OpenCL
desperately needs a kick in order to catch up with CUDA. Instead they are
focusing on things like SyCL, hoping to catch up with already superior
projects such as C++AMP. OpenCl should rather fix their poor specification and
get implementers on the same page about it. The mobile community could have
been a driving force. Instead, frustrated with what OpenCL is, mobile decided
to roll their own. As always.

~~~
pjmlp
Metal is for graphics programming, not GPGPU.

But yes, OpenCL with its basic C API is way behind what CUDA offers in terms
of language support.

Maybe SPIR will fix it, but it remains to be seen if anyone on HPC will care.

~~~
foxhill
> But yes, OpenCL with its basic C API is way behind what CUDA offers in terms
> of language support.

strange, language support is really the only thing that CUDA doesn't have over
OpenCL. there are C++ (and python, Java, various others) bindings for host
code, at least. if you're looking to use device intrinsics in your kernel code
(at the cost of portability) then blame nvidia for not exposing it (and for
their lack of support for OpenCL in general).

> Maybe SPIR will fix it, but it remains to be seen if anyone on HPC will
> care.

yes, there are people doing HPC that care.

~~~
oneofthose
I guess "language support" was referring to the restrictions within the kernel
language. And CUDA is better there - they support templates, you can typecheck
a CUDA kernel call. With OpenCL you have to jump through hoops to get that.
While some projects have managed to do it, it could be better still.

What bugs me about OpenCL is the intentional vagueness of the specification
that gives every implementer the freedom to do whatever they want with the
result that performance portability is often difficult to achieve.

~~~
foxhill
templates are not something that (outside of simple uses) you'd want to use in
your kernels. regardless, nvidia should be pushing their improvements through
to OpenCL by exposing extensions. they might get adopted into the core
profile.

> What bugs me about OpenCL is the intentional vagueness of the specification
> that gives every implementer the freedom to do whatever they want with the
> result that performance portability is often difficult to achieve.

well, that flexibility is required for OpenCL to be meaningful. that's where
the variation in the hardware platforms exists. it's what differentiates
compute devices. if that vagueness wasn't there, then we couldn't have things
like OpenCL on FPGAs (altera, xilinx)

as for your statement on performance portability, perhaps that is an issue
(but that's entirely dependent on the type of problem you're trying to
compute). but something i don't understand is this;

you could have picked a proprietary API to do your compute. but say you choose
CL. you optimize for your hardware, then what do you know - it's not really
that fast on other hardware. but you're entirely overlooking the biggest boon
here - your code ran on the other hardware _in the first place_. getting
performant code is now only a matter of optimizing for that piece of hardware.

you could argue that's entirely too complicated, but that's what we have been
doing already with our regular C/C++ programs (SSE/AVX/SMP...)

~~~
oneofthose
Templates are an essential tool to write type-independent algorithms. They
enable meta-programming, an invaluable tool to provide flexible yet efficient
active libraries to users. They allow automated kernel-space exploration. So
templates are exactly what you want.

I understand the need for a standard that supports various different
architectures, even architectures that might not exist yet. I guess I just
dislike the way the did it. Compared to other standards (that also leave
various things to the implementer), I think they did a poor job. They should
have defined the semantics and the types better. The entire buffer mapping for
example is a huge mess. Nvidia went ahead and fitted pinned memory in there
somewhere. Others didn't, with the result that the meaning of the code changes
completely depending on which library you link against.

I'm not arguing against OpenCL here, I'm saying they could do even better. It
should not be too much effort too. And if companies like Apple and Google
would have chimed in, we would have pretty awesome OpenCL standard and
implementations today.

As for your argument about hand-optimization: C++ library implementers [0,1]
(and compiler vendors probably too) found abstractions, tricks and tools that
give performance portability today. They are of course domain-specific but it
is possible.

[0] [https://github.com/MetaScale/nt2](https://github.com/MetaScale/nt2) [1]
[http://eigen.tuxfamily.org/](http://eigen.tuxfamily.org/)

~~~
foxhill
> Templates are an essential tool to write type-independent algorithms. They
> enable meta-programming, an invaluable tool to provide flexible yet
> efficient active libraries to users. They allow automated kernel-space
> exploration. So templates are exactly what you want.

but OpenCL C only has primitive types. templates become more useful when you
have classes, but bringing classes to the GPU is.. well, less than optimal.

> Compared to other standards (that also leave various things to the
> implementer), I think they did a poor job

i don't know what your complaints are exactly, but i don't share your opinions
- i think OpenCL is almost as flexible as it needs to be.

> The entire buffer mapping for example is a huge mess

i disagree. clCreateBuffer creates a buffer, clEnqueue(Read|Write)Buffer reads
or writes to it. you can do more advanced transfers with the *rect variants,
but you kind of probably know what you're doing at that point.

you want pinned memory? call clCreateBuffer with CL_MEM_ALLOC_HOST_POINTER.
and instead of Enqueue(Read|Write) use Enqueue(Map|Unmap). wether or not you
get pinned memory is up to the runtime (and nvidia's runtime does not
guarantee it - it's an impossible one to make).

> Others didn't, with the result that the meaning of the code changes
> completely depending on which library you link against

as mentioned, use map/unmap. it works on all the runtimes, and at least isn't
any slower than read/write. as for what library you link to, that's also a
moot point - we have ICDs now, you link to a shim layer that dynamically links
the appropriate run time during context creation (you can have several OpenCL
platforms on one machine).

> As for your argument about hand-optimization: C++ library implementers [0,1]
> (and compiler vendors probably too) found abstractions, tricks and tools
> that give performance portability today. They are of course domain-specific
> but it is possible.

i haven't looked into either of your links in detail, but with the various
BLAS/LAPACK libraries that exist, which are also far more mature (and more
widely used), would almost certainly be a better choice. lots of these already
work on GPUs and are optimized to death by beings who think in assembly.. most
of them are in fortran, as well (although they have front ends for several
languages).

------
corysama
Any mention of hardware requirements? I'm betting this is 5s/Air-only. But,
I'd love to be wrong.

~~~
hraedon
A7 and above, if the keynote is correct.

~~~
yaeger
Isn't this part of the new iOS8?

If so, I think I recall seeing the screen which models are eligible and I
think the 4S was the first on the screen. Going up all the way to the 5S.

So, I think everything before and including the iPhone 4 will be left out?

------
syjer
This one is quite surprising. I would have guessed that given the pervasive
use of opengl(es) in their os, they would have advanced a azdo approach ( as
described in [http://www.slideshare.net/CassEveritt/approaching-zero-
drive...](http://www.slideshare.net/CassEveritt/approaching-zero-driver-
overhead) ).

~~~
kevingadd
The 'fill command buffers with commands' approach they adopted is basically an
alternate way of achieving the same goals as AZDO. You can view AZDO GL as
just filling a command buffer for you behind the scenes (with a few other
quirks)

------
abdophoto
This has to be a move towards the development of games on an Apple TV.

~~~
hjnilsson
Indeed, it also explains why they put the A7 in all their devices (instead of
recycling the A6 as they did previous years). An Apple TV with A7 and Metal
will be competitive with Xbox360 / PS3 / Wii U spec-wise. And without a fan!

~~~
orkoden
Currently Apple TV has an A5. The A8 is due in the fall. So an updated Apple
TV with an A8 could be a powerful gaming machine.

------
toksaitov
Judging by what we have it looks usable not only for graphics. Finally we got
OpenCL on iOS. Kind of

------
general_failure
Does this mean now that xplatform graphics code will be a thing of the past?

~~~
deminature
Open GL ES is not going away, just a more performant option is available.
Also, Metal is supported by at least two of the most popular engines (Unity
and UE4), so they should handle most of the cross-platform work, provided you
are using one of those.

------
vacri
Another framework, another needlessly generic word to play havoc with search.

------
shmerl
Key questions:

1\. Is it open and cross platform?

2\. Is it going to be supported across all GPU vendors?

If either of those is no, than it's a failure from the start and just another
walled garden thing.

~~~
to3m
Being "another walled garden thing" will hardly be its death knell.
Proprietary single-vendor APIs are already common on games consoles, and it
hardly seems to have caused a problem. Look at DirectX, even; not quite
single-GPU-vendor, but hardly renowned for its portability, and popular
nonetheless. These things will succeed if the platform is popular, and other
factors are pretty irrelevant.

I suspect iOS is popular enough to make this work.

~~~
shmerl
I don't mean it won't be used. You are right, for example PS4 uses its own
PSSL. But it's still a failure, because it's bad for developers who have to
support multiple APIs and bad for users who likely won't get some titles for
their platform because developers have no resources to support multiple APIs.

~~~
MBCook
> But it's still a failure, because it's bad for developers who have to
> support multiple APIs and bad for users who likely won't get some titles for
> their platform because developers have no resources to support multiple
> APIs.

That doesn't make it a failure, that makes it something you don't like.

This could easily be very big. If it helps developers make faster/better
looking games on iOS they'll do it, especially if it's supported by middlware
(since most devs probably don't make their own engine).

It that happens to make it harder to port games to Android (or at least get
them to look as good), so much the better for Apple.

~~~
shmerl
I don't like it for a reason that it multiplies exclusive titles. I consider
it a failure. Normally authors should aim to reach the most audience, not to
exclude users because they use a different OS. This API will proliferate the
later.

~~~
MaxBarraclough
A failure is something which doesn't succeed in achieving its goals. We often
approximate this by looking at how widely used something is. For an API, this
measure seems reasonable.

It has nothing to do with your views on vendor lock-in.

Direct3D also causes lock-in. That doesn't make it a failure.

~~~
shmerl
Failure applies here to cross platform availability. Vendor lock is is a
failure by default.

 _> Direct3D also causes lock-in._

It does indeed. That's why it also fails to be the proper portable graphics
API.

~~~
MaxBarraclough
[https://news.ycombinator.com/item?id=7838196](https://news.ycombinator.com/item?id=7838196)

I already spelled out for you what the word 'failure' refers to, but fine,
I'll try again.

"Failure" does not mean "failure to please shmerl". That simply isn't the way
the term is commonly used.

Direct3D fails to make me a coffee, too. So what? Portability to non-MS
platforms was never a goal. Neither was my coffee.

It is clear that you are being deliberate obtuse to avoid conceding the point.

~~~
shmerl
Failure means failure to be a portable API. Whether it's pleasing me or not is
irrelevant. I explained the context of what I was discussing above.

------
pekk
Yet another special Apple-only lockin mechanism.

~~~
vincetogo
I really don't see this being the case. Any competently designed graphics
engine has an abstraction layer between the app's graphics routines end the
platform's graphics API. While it's not trivial, another API shouldn't be
something that prevents an app from being ported to other platforms.

~~~
kirab
Did you completely miss just how much DirectX locked games into the Windows
platform?

~~~
pjmlp
You mean the same that were equally available on Wii, PS 3 and XBox 360?

------
chrismorgan
I hate pages that deliberately break the functionality of the Space bar.

~~~
chrismorgan
Downvotes!? Why? The Space bar is supposed to let me _scroll_ , and on the
linked page it doesn’t do anything.

------
ausjke
Saw lots of HN news on Apple, I own absolutely no Apple devices, as I think
while them are well made, the software ecosystem coming with it is similar to
whatever Microsoft had before, i.e. essentially closed, and that is important
to me, it made me to own zero Apple devices.

Am I alone here? I'm running Linux everywhere from home to my office for
years, and my tablet/cellphone is Android-based.

~~~
tvon
You are not alone but you are probably in the minority.

(quick edit: You saw a lot of Apple news because the WWDC keynote was today)

~~~
ausjke
for what reason that my comment as above deserves down-votes? could those
down-voters explain why this should be down-voted? you have down-vote rights
does not mean you can abuse it, shame on you HN

~~~
bobbles
You're getting downvoted because your comments add nothing to the discussion
and have nothing to do with the article that has been posted.

