Vulkan and Metal (some observations)

As Vulkan spec has been released few days ago, I think it might be interesting to look at how it compares to what Apple gives us with Metal. First of all, a disclaimer: this is mostly from an academic standpoint, I am interested to comparing the APIs, the provided fetures and their relative merits. I hope that some other people here who are curious about GPUs, APIs and API design could offer their thouhgts on the matter.

Some folks (me included) were quite dissapointed to learn that Apple is jumping the Vulkan bandwagon. After reading the spec, I think I understand why. And I am starting to believe this might be a very reasonable move by Apple. Here are some thoughts.

I think it should be fairly clear that Vulkan offers higher performance potential then Metal. Metal still does a lot of hand holding and behind-the-scenes management for you, while with Vulkan you are responsible for — literally — everything. And man they were NOT kidding when they said that the API is explicit. Its actually quite ridiculous how diffficult and detailed the API is. Of course, the nice thing is that you can optimise the resource usage very precisely in regards to the specifics of your engine, and you get quite precise performance guarantees. On the other side, you need to make sure that the data you use for a particular pass is in the device memory, which means juggling data around, recreating resources, breaking down yoru renderign commands and doing all kinds of weird memory dances. In fact, I can't imagine that many people will use Vulkan directly, instead we will see a bunch of wrapper libraries that abstract the tedious tasks like manual memory management and operation synchronisation.

At the same time — and that is the funny thing — Vulkan does not seem that much more powerful to me. Yes, it supports stuff like geometry and tesselation shaders, it has batched bindings updates, sparse ressources, command buffer reuse and atomic texture operations. But all these things can be trivially added to Metal (and I'm sure Apple is working on that already). The ressource binding model of Vulkan is more efficient, that for sure, but it is certainly not more powerful — it does not allow you to build more complex shader inputs than what Metal already offers.

The explicit nature of Vulkan might offer additional optimisation opportinuties to applications seeking to squeeze those 100% out of the hardware, but at the extreme expense of usability. Metal is a more casual API, which is very convenient to use and still offers very good performance (and performance guarantees) that will satisfy an overwhelming majority of applications, both for graphics and compute. With some extensions, it will basically have feature parity with Vulkan, and it can easily borrow some of Vulkan's optimisations without sacrifising ease of use (e.g. batched binding updates, reusable command buffers as well as synchronisation primitives). And let's be honest here — applications that really need explicit control like Vulkan provides are high-end game titles, which are not targeted at the Apple platform anyway (because they require really beefy GPUs, which Apple simply does not ship in their machines).

I think Apple might have lost the initial interest in Vulkan after they saw what it was shaping up to become. They were interested in having a convenient and efficient replacement for the difficult to maintain and erratic OpenGL. Vulkan is certainly efficient but I wouldn't call it 'convenient'. Its not an API that would draw developers (especially small-time developers) away from using OpenGL or encourage them to make more titles for OS X. Instead, Metal hits the spot exactly. I still would like to see Vulkan on OS X and iOS at some point (to make it easier for devs to port from other platforms), and from what I gathered, it should be actually possible to implement a Vulkan wrapper on top of Metal (which will of course lack features such as sparse resouces, tesselation shaders etc. — but thats is still perfectly legal according to the Vulkan spec). Personally however, I'd be much more interested in a Metal implementation on top of Vulkan to use on Windows/Linux.


Here's the problem--VR is one of the driving forces in the computer graphics industry at the moment. All of the big 3D apps are looking at Vulkan and what it can deliver, and wondering if they have the resources to continue supporting Apple and its distinct lack of forward progress in the graphics area, or not.

Metal vs Vulkan is yet another reason to abandon Mac hardware for serious graphics, as if the lack of adequate GPU solutions wasn't bad enough. Now we're talking about an additional switch in the codebase to support graphics specific to the one platform no one's going to be using for VR.

THIS *****, BECAUSE I AM A HUGE MAC FAN. But seriously, Apple needs to step the **** up and let us know what their plans are.

This is a massive, unparalleled opportunity for some companies to get a leg up on the competition, but only by embracing Vulkan. Unless Apple makes it real **** easy to support Vulkan, we're going to see OSX left behind.


(who works with these companies and has to hear about this problem every day)

First a quick comment: I wouldn't nessesarily say that Apple lacks forward progress in the graphics area. Metal is a very well designed and probably the most user-friendly next-gen graphical and compute API available. Sure, it lacks features at this early stage — but they can easily be added in future updates. Vulkan lacks features too, e.g. there is no API to copy between different GPUs.

Nevertheless, you raise a very valid concern. Both Apple and Apple users would surely benefit if they offered a standard, mature API that developers can rely on across platforms. I think there is already a company developing a Vulkan-to-Metal wrapper, and I still hope that Apple will implement the API in the close future. There is no reason why Metal and Vulkan shouldn't be able to coexist.

its too early to pass judgement on Vulkan. Give it a couple of years and we can then talk about it in more detail.

On the theoretically side, the way I see it , Vulkan is far more abstract and far lower leven than openGL, which is awesome for pc developer but not big deal for apple developer. Apple is better with custom software that works well and has been designed for its hardware and this is what Metal really is.

But to be frank with its really a moot point, because nowdays the vast majority of developers use game and graphic engines. Less and less people work directly with opengl and metal and I suspect even less with work directly with Vulkan. Its just too complex to do something like that.

I am using Unreal Engine , which currently supports Metal / OpenGL / DirectX / Cuda /OpenCL/ PhysX and much more, most likely it will support Vulkan as well if it does not already. An Unreal developer even though the game engine is state of the art rarely deals with low end backends unless we are talking about a big studio that wants to push envelope. For small team developers they dont even use C++ , they heavily rely on blueprints which is a form of visual scripting.

The Brenwill Workshop (who I work for) is indeed developing an implementation of Vulkan on Metal (using a similar approach to our existing OpenGL ES implementation on Metal). The Vulkan implementation runs on both iOS and OS X, and will be released soon.

I do a fair amount of OpenGL development for custom applications and starting to shift to Metal begrudgingly. So the demand is still there for graphical programming. I think the problem with Apple is that they've let OpenGL rot on their OS. It's in a really sorry state. Metal isn't mature enough or capable yet to fully replace it. The drivers are not great either.

This means all the companies not game related that have custom graphics code must port that over to Metal eventually. It's easier to port over OpenGL or Vulkan used on other platforms then it is to rewrite it all for a proprietary API. The last and most serious point is that regardless of all these different APIs it doesn't matter if the GPUs used are absolute crap.

You aren't going to be able to run VR or anything graphically intense on a Mac because none of them have capable GPUs. The new Mac Pro doesn't count either. Those sorry *** GPUs are terribly designed and severely limited by tdp. There was an article about the CGI group that created the Deadpool movie burned out the GPUs in 10 new Mac Pros because they just couldnt handle it. Dual D700s arent even capable of VR on the lowest setting. Oculus Rift wrote a piece on how VR will not come to Macs until Apple actually releases a good computer. How laughable is that. Apple has always lagged in the GPU department as well as their driver support. Look at Blizzard they aren't bringing their new game Overwatch to the Mac because the graphics technology and drivers has lagged so much it would cause their game to be below their standard of quality.

Apple needs to get their **** together. Metal is not going to save them. Having used Macs for over 15 years this is the lowest point I have seen for their graphics capability and technologies.

Unfortunately, without command buffer re-use, we still see high CPU usage encoding rendering and compute commands every application frame. This can be offset a bit by enqueing command buffers and then encoding them on separate threads, but the room for real savings in enormous with command buffer re-use. My hope is that this is added as a core capability to the Metal framework in the near term. Everything else is of secondary importance.

biggest problem no one in gaming industry wants to use Obj-C/Swift. We are comfortable with C++

So, even if apple does anything in gaming industry we are not going develop for OSX. Over that hardware ***** even external GPUs don't support to use internet mac display.

Over that Xcode *****. We can't refactor C++ code and C++ doesn't have good support on Xcode

New Apple is Razer Blade. Good design + Gaming. The fact after steve job's death there ain't any guy left in Apple you could take risks and do crazy things 😟