Hacker News Reader

Comment by dmitriid | Hacker News Reader

Apple has all the right to not think about Vulkan and invest in their own implementation.

- First release of Metal is June 2014. The Khronos Group began a project to create a next generation graphics API in July 2014. First release of Vulkan is 2016.

- Metal is C++. Vulkan is C. Yes, that may matter

- Metal is specifically optimised for a specific set of hardware with known capabilities. Vulkan aims at everything under the Sun

- Vulkan is headed by a consortium that wasn't known for its great decisions in the past, and Apple might want a faster turnaround on features and capabilities

- It's just business

View on HN

> Metal is C++. Vulkan is C. Yes, that may matter

The Metal API is Obj-C or Swift, only the shading language is a C++ variant.

A C-API (not C++) would actually be nice. While ARC is quite convenient it also adds a significant overhead. Most of this overhead can be prevented with quite a lot of handholding, but this also reduces the benefits of high-level languages like Objective-C or Swift, I'd even argue that this handholding is more hassle than having a more explicit C-API to begin with.

All of that is not a justification for their sick lock-in.

- It was explained above, that Apple knew well all along, that there was an effort to make a common low level API. Well before they started Metal. So they purposefully refused to participate.

- C was a proper choice for Vulkan (short of choosing Rust let's say), since it makes it easier to provide bindings from any language than let's say using C++, making bindings to which is way more painful.

- Optimization for hardware happens on low level compilation, so it's a lame excuse not to support Vulkan.

- Faster or not, Apple could observe the result (which was good) once it was ready, and support it. They refused (because Apple).

- Business or not, lock-in is a nasty attitude that's aimed at taxing developers. There is no no need for development tools lock-in, it's a sick anti-competitive methodology, for which Apple is quite infamous.

When Metal was initially developed and even when it was released, Vulkan wasn't even a proposed project yet. The only comparable thing was Mantle from AMD (which later evolved into Vulkan). At the time NVidia were still saying use OpenGL with AZDO techniques and on mobile, you were stuck with OpenGL ES, with a multitude of issues.

Optimization of existing code happens at a lower level but if you can gear an API for optimal use of your hardware and existing APIs, you make it easier for developers to write code that will have a better shot at being optimized. Not all code optimizes the same way.

Also what you view as taxing developers, can also be flipped around as being able to make an API that is a lot easier for the developers on their platform.

And indeed, metal is probably the easiest of the modern graphics APIs to get started with, with a very light learning curve even compared to OpenGL. All while not sacrificing performance and expressiveness for more involved development. Vulkan meanwhile remains very inaccessible to many developers even with graphics backgrounds.

Let's not also forget that apple isn't an outlier for lockin, and actually are quite open. OpenCL, Clang, webgpu, swift etc are all very open and cross platform. Meanwhile even things like directx are locked to windows.

The real goal isn't lockin. It's providing the best API to developers to let them get in quickly while also optimizing for their hardware. Lockin is an unfortunate side effect but they're also completely succesful in meeting their actual goals.

> The real goal isn't lockin.

That's an excuse, since the result is lock-in. I.e. if Apple so much wanted Metal - let them have it. But how does that prevent them from supporting Vulkan, for those who don't want to waste resources on duplicating work and want to reuse their existing Vulkan codebase on Apple systems? But no, Apple forces you to use Metal. So the claim that it's for developers' benefit won't fly. It's for Apple's benefit very clearly.

WebGPU is also a counter example, since Apple there try to prevent adoption of common formats like SPIR-V.

When it comes to sabotaging interoperability, Apple are always among the first.

Apple does all their driver and API development in house. Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead.

Why support Vulkan, which is arguably harder to use and takes more resources of their internal development teams, when they have an API that provides all the benefits and is arguably a better API? Especially when the major off the shelf engines already support metal. It's diminishing returns at this point.

Personally I'd be quite happy to have Vulkan support on mac, but if you take a step back from your inalienable position that it's a conspiracy, there's actually very sound reasoning behind it.

You may not agree with the decision, but you weaken your argument when you're trying to force everything to fit a black and white narrative. The reality is much more nuanced.

> Apple does all their driver and API development in house

Not OP but the games and film industry believe this here is the problem. The additional effort to support common APIs is an artificial self-imposed problem resulting in worse software.

I'll definitely agree here that it's got its share of pros and cons, and having worked in both realtime and film work, it is difficult.

But on the flip side, it does fit in with apples ability to develop very tailored platforms and make very easy to use APIs.

So while I often find myself on the wrong side of the double edged sword, I do also feel their decisions make sense as well. And honestly, having done dx9-12, OpenGL and Vulkan, I won't argue against how easy to use metal is.

I'm sort of mixed on how easy Metal is. Having to support Objective-C and/or Swift as part of the build toolchain is sort of a headache and Metal actually isn't low-level enough for me to support a lot of the optimizations I can do in DX12/Vulkan and especially doesn't come close to console APIs (which you'd think should be possible given that they can specialize for their hardware). My feeling is that for driver APIs, it's ok for the API to be lower level since users (and other developers) generally won't need to deal with that anyways.

Given what was shown at WWDC regarding software support and hardware for live 8K HD editing, I don't think film industry is that much worried.

As for games, the sales speak for themselves.

> Apple does all their driver and API development in house. Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead.

How does this jibe with your position that Apple isn't performing lock-in, particularly when Apple is now specifically refusing to approve previously-available Nvidia drivers and thereby preventing them from being used in external GPUs for Macs?

The details of that aren't public other than both companies want control of the driver stack and neither is willing to budge. The driver breakage happened between major operating system versions that had significant graphics systems overhauls so would not be compatible as is.

I don't classify that as lock in. It's an unfortunate side effect of business dealings between two immovable companies.

However apple does work with AMD and Intel GPUs, and still allow AMD external GPUs.

> Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead.

First of all, who exactly prevents GPU vendors from doing it for Apple? Apple. Secondly, with Apple's resources I don't buy the excuse of "it's too hard" or "we can't spend on it". Apple are very happily spending piles of money, when it helps them hamper interoperability in result. So being cheap here is just another lame excuse for lock-in.

It's simple policy. Apple do their own dev and don't use third party companies for the development. This is for a variety of reasons including providing a tailored platform to their specifications, and meeting the level of secrecy required internally.

Whether you agree or not with the policy, it's not one motivated by lock in.

And again it's not a matter of being cheap. It's a matter of perspective. Apple believe metal is worth using and that it delivers needed performance, optimization and features for their stack. Apple also believe in very straightforward developer stories within their own platform. Vulkan doesn't provide value above and beyond what metal does from apples perspective, and it complicates their developer story.

> It's a matter of perspective.

That's my point too - their perspective is lock-in. Not just in graphics APIs but in many things. So this issue falls into the common picture with many other similar ones.

I.e. Apple could easily implement it. They don't for political reasons, and I don't buy any lame excuses like "that's better for developers" and such.

No , your perspective is lock in. You're trying to fit all their rationale into one convenient box and ignoring the nuance of the situation.

Theorizing about non malicious motives doesn't change the facts - the result is lock-in. And when it consistently happens all the time for supposedly "other reasons", excuses about it not being done for the sake of lock-in stop being even a tiny bit convincing. To put it differently - who cares about motives at this point, when the result is a nasty lock-in which Apple refuses to remove.

You seem certain that preventing people from hastily porting Android games was NOT a motivation for Apple.

But they have explicitly said in the past: they really prefer we not put cross platform apps on the App Store.

I don’t know why you won’t consider the odds that Apple is trying to hamper cross platform apps with Metal deliberately as a policy when they’ve specifically said that’s their strategic goal.

Google is the company currently driving WebGPU efforts and has shown the fruits of their labour at Google IO.

To the point that what Intel has contributed to WebGL 2.0 compute shaders implementation on Chrome might be thrown away, as Google now considers it needless in presence of WebGPU.

Which by the way is based on HLSL, just as Khronos is also finding out on their Vulkan PR efforts, is the favourite shading language among professional game devs.

Which is why Samsung and Google are the two biggest contributors to HLSL to SPIR-V compiler.

Shader language shouldn't matter as long as it's compiled to standard SPIR-V. There is no point to limit it to one language.

It matters if the available tooling isn't practical.

What do you mean tooling? Like Unity?

IDE like support for shader development, something that all proprietary APIs support out of the box, and both OpenGL and now Vulkan have always been lacking.

Usually what gets thrown by OEMs or FOSS devs looks more like sample apps, are OEM specific thus making the API not as portable as advertised, or feel short.

For example you can pinpoint specific pixels and trace back to which code lines from each shader were involved in rendering the pixel. Check the Metal debugging talk at WWDC 2019.

I would honestly have been happy if we just had OpenGL compute shaders available on all desktop operating systems. That was standardized in 2012 by OpenGL 4.3, two years before Metal.

> Let's not also forget that apple isn't an outlier for lockin, and actually are quite open. OpenCL, Clang, webgpu, swift etc are all very open and cross platform.

OpenCL is deprecated on macOS, and hasn't been updated past OpenCL 1.2 (2011). It was killed in favour of Metal.

I hope that WebGPU is a good cross-platform API for GPU compute when the standard is finalized and implemented, but I've learned not to count my chickens before they hatch.

"Lock-in" means that there are alternatives that you could use, but the vendor does not let you. When Metal appeared, there were no alternatives, Vulkan wasn't a thing for 2 years after Metal, and even today, Vulkan has seen relatively low adoption, so one could argue that it still isn't really a thing.

Metal might be many things, but lock-in isn't one of them. If you are happy with Vulkan then good for you - without Metal, Vulkan wouldn't even exist. It took Apple telling Khronos to GTFO for they to start working on Vulkan.

> without Metal, Vulkan wouldn't even exist.

That's completely false. Apple only started the whole Metal effort because of Mantle, which was the origins of Vulkan. But being Apple, instead of collaborating and ending up in proposing things for Vulkan, they pushed for NIH lock-in.

> Lock-in" means that there are alternatives that you could use, but the vendor does not let you.

Which is exactly the case here. Take some project like Wine for example, that works on implementing Direct3D over Vulkan. That's the alternative they want to use, yet Apple prevents them, forcing them to either waste resources on implementing another path using Metal, or to go suboptimal route of extra translation. Who is to be blamed for it, but Apple?

> Metal might be many things, but lock-in isn't one of them.

It wouldn't be, if Vulkan was available as an alternative. But like you said yourself, lock-in happens when the the vendor does not let you use the alternatives. Who but Apple prevents native Vulkan support from appearing on their systems? So Metal is very clearly lock-in, according to your own statement.

> Apple only started the whole Metal effort because of Mantle

No.

They responded to it. AMD were first to come up with such design and published it for everyone in the form of Mantle. AMD also clearly communicated their idea to make it open and available for all.

Apple used the idea, but instead of eventually joining Vulkan group, pushed their NIH in their typical fashion.

You're understanding of the history of Mantle, Metal, and Vulkan is very poor.

1. Mantle was not originally being proposed as a "open" API as you are implying. A reading of the [original white paper](https://www.amd.com/Documents/Mantle_White_Paper.pdf) makes apparent that AMD was trying to leverage their game developer mind-share from the consoles by bringing it to desktops. Mantle was being proposed as an AMD GPU only API.

2. Metal was released 10 months after Mantle was announced (and 3 months after API docs surfaced). That's an extremely short timeline for a big company to go from zero to deciding to release a new graphics API, spec that API and it's shading language, write drivers and compilers for it, write developer tools, and author documentation. The timeline you're proposing simply doesn't make sense. Apple was clearly working on Metal long beforehand.

3. Vulkan, as an initiative, was reactionary to Apple's release of Metal, being that - up to that point - iOS and macOS were the largest OpenGL[ES] markets and Apple the only company commercially invested in OpenGL (OK, maybe not the only, but clearly Apple was the most influential Khronos member). By the summer of 2014, it was clear that Mantle - as an AMD only API - was not commercially viable. Thus, it was "donated" (so to speak) to Microsoft and Khronos to bootstrap DX12 and Vulkan development. (My understanding is that DX12 was already under development, but it's clear that the API shifted drastically in response to Mantle as evidence by the DX12 version 1.0 docs containing passages verbatim taken from the Mantle programming guide).

Please stop spreading false narratives in order to bolster your agenda.

It wasn't open from the start, but AMD communicated their intent to open it. No point to pretend Apple didn't know about it. It took a while, and AMD did just that, by giving Mantle over to Khronos, as a base of Vulkan.

You know that Apple did not start working on Metal the day they announced it, right ?

> without Metal, Vulkan wouldn't even exist. It took Apple telling Khronos to GTFO for they to start working on Vulkan.

This is not true.

Reply on news.ycombinator.com