Hacker News Reader

Comment by shmerl | Hacker News Reader

Congratualations! It's a major step forward.

Note this however:

> “Vulkan takes cross-platform performance and control to the next level,” said Bill Hollings of The Brenwill Workshop. “We are excited to be working through Khronos, the forum for open industry standards, to bring Vulkan to iOS and OS X.[1]”

Of course Apple had to remain the jerks they are and not support Vulkan natively, forcing developers to write translation layers[2]...

[1] https://www.khronos.org/news/press/khronos-releases-vulkan-1...

[2] https://moltengl.com/metalvk/

View on HN

> Apple had to remain the jerks they are and not support Vulcan natively

Thats a rather immature view of the technology world that smacks of the tired old tribal warfare notions that only internet forums believe in.

Apple had a technical problem of slow, bloated and battery-draining OpenGL API and they solved it using Metal more than 18 months ago, when no other viable alternative was on the horizon. Are they jerks because they didn't saddle their users with a technically inferior solution for even longer?

Khronos has let OpenGL evolve into a byzantine beast of an API with GPU vendors effectively segmenting it into multiple complicated variants of best practices (like AZDO and others). Vulkan was announced more than two years ago, but unless you were in a select inner circle of developers, there was no actionable information available, until today.

In the meantime, major commercial engines already have official support for Metal (or Unity will have it soon). Popular games like World of Warcraft already have betas using Metal. I can download free IDE, documentation, sample profiling and debugging tools for developing Metal applications.

Sad truth is that Kronos and the Vulkan group took too long to evolve OpenGL and to give developers any actionable specifications for Vulkan.

> Are they jerks because they didn't saddle their users with a technically inferior solution for even longer?

Em no, they are jerks because they never updated OpenGL implementation on OS X (which still is generally 30% or so slower than Windows implementation on same hardware, not to mention lacking of full 4.2, 4.3, 4.4 and 4.5 OpenGL support) then implementing a new proprietary API on the desktop with huge fanfare and marketing about being "30%-50% faster" (or in other words - as fast as OpenGL is on Windows). Meanwhile, OpenGL implementation is still rotten as of 2016 at 2010 OpenGL 4.1 levels with no update.

Leaving an open implementation of a 3D standard to rot in performance limbo and then bringing in a new proprietary standard which has to be used to get competitive performance does bring the word "jerks" to mind.

> Thats a rather immature view of the technology

And you think lock-in is a mature approach to technology? It is not. And lock-in is the only reason why Apple pushed Metal instead of joining the Vulkan effort. Unless you are trying to claim that they just couldn't plan things and ended up with their own NIH despite Vulkan emerging in the background. But that doesn't fly, since they could have corrected it when they realized where things are moving. So "no ill intent" reasoning here doesn't sound convincing.

Metal predates Vulcan by any measure. It was the first publicly available low level graphics API and once they released it that have an obligation to support it. It was released, what, 4 months after aMD announced mantle? That's not enough time to develop and deploy an entirely new API, from my memory Vulkan was more a response to Metal, DX12 and Mantle.

> Metal predates Vulcan by any measure.

See my answer here: https://news.ycombinator.com/item?id=11112078

This "Metal predates Vulkan" argument is getting old already since it's historically incorrect.

> It was released, what, 4 months after aMD announced mantle? That's not enough time to develop and deploy an entirely new API, from my memory Vulkan was more a response to Metal, DX12 and Mantle.

You remember it wrong. Again, see the link above.

I'm not seeing a timeline in your link above.

According to Wikipedia's Vulkan article [1], "The Khronos Group began a project to create a next generation graphics API in July 2014..."

Wikipedia's Metal article [2] links to the presentation from WWDC 2014 (the first week in June 2014) where Metal was introduced. Apple doesn't ever per-announce APIs-- at this time Metal was available for developers to use.

The Mantle article [3] says AMD developed Mantle "...starting in 2013" (the referenced Forbes article is from September 2013.) I'm doubting this was ample notice for Apple to have elected to write Metal, design it, and implement it nearly completely for June 2014. However, I'd concede it is certainly possible (Apple just doesn't seem that nimble to me.)

I'd be interested in reading anything more authoritative than a comment board on the impetus behind what seems to be an industry-wide decision to create these lower-level APIs.

1 - https://en.wikipedia.org/wiki/Vulkan_(API)#History

2 - https://en.wikipedia.org/wiki/Metal_(API)

3 - https://en.wikipedia.org/wiki/Mantle_(API)

Their resemblance in design is just stunning and claiming it's accidental would be stretching that chance way too far. There were some documents published which even highlighted how early DX12 documentation was almost a verbatim clone of the Mantle one with only few minor changes.

You wouldn't find official documentation on AMD dealing with Apple and MS, because it was private. But you can clearly deduce that both Apple and MS had access to Mantle when designing their APIs by comparing them. It's even possible that AMD did some of the work for them.

Also, AMD never hid their intention to make Mantle open. They voiced it early on. So Apple and MS both new that would happen when they started working on Metal and DX12. And that's exactly what happened when AMD gave Mantle to Khronos. Vulkan essentially is an iteration over Mantle. Same as DX12 and Metal are.

Even if you assume it all happened by pure chance, and the stunning resemblance of design is just because many different people had the same way of thought - it's not going to explain why MS and Apple couldn't back Vulkan once they figured out where things are moving.

Well, not by 'any' measure (as others have pointed out). Additionally, do you find Metal to be a wholly unique creation? It certainly 'borrows' ideas from other low level mobile GPU APIs out there...

What Apple are doing with Metal feels eerily similar to what Microsoft did when they launched DirectX back in the day.

If we're lucky, it won't be as successful; decades of graphic stack fragmentation hasn't been pleasant to live through, both as a developer and a gamer.

I really doubt Apple will ever be big enough for many big game developers to consider making exclusives for Macs. They don't even sell any computers remotely targeted at games, and often sacrifice price and cooling for prettier design.

Then it is up to the community/Khronos to provide the same tooling and support games developers enjoy from Apple, Microsoft, Sony and Nintendo.

GPU vendors don't care much about API support tooling, as long as their hardware gets sold.

"Of course Apple had to remain the jerks they are and not support Vulkan natively, forcing developers to write translation layers[2]..."

We write programs that use DirectX,Metal, OpenGL/OpenCL, and now Vulkan and I disagree.

We believe competition is great. OpenGL/CL was in theory a standard but over the years we had to funnel way more resources to make that work than with DirectX or Metal combined. Why? Because of the "design by committee" mentality of OpenGL/CL.

The only reason they had to react with Vulkan was competition from private companies and even then the reaction was slow and painful for those that were forced to support the bloat software for years.

We could do the same thing in OpenGL/CL with 5 different ways,one modern way and 4 obsolete but not pruned from the standard because some company of the committee that had obsolete legacy code banned the removal.

This made the codebase so big and hard to maintain, and expensive for developers to support.

If Microsoft and Apple runs circles around those people, they are forced to act and develop a better standard.

For us it is easier to develop translation layers that support OpenGL/CL messiness.

> We believe competition is great.

Competition is great, sure. But Apple are anti-competition here. Competition would mean choosing between using Vulkan or Metal on their system. Where is that choice (wrapper is a workaround, but besides)?

All those lock-in proponents are actually scared of competition. So we are not in disagreement. Competition is indeed good. Lock-in however is not, and lock-in is anti-competition.

> The only reason they had to react with Vulkan was competition from private companies

It's the other way around. The only reason MS and Apple suddenly woke up is because AMD was planning to open up Mantle (which resulted in Vulkan). Except they reacted in their usual manner. Instead of helping the shared effort they pushed for more lock-in.

I am not scared about Apple getting a monopoly. They are not going to sell as much as Android because they only care about the high margin stuff.

I am more worried about Microsoft though, with Windows and Xbox they force millions of people to use DirectX.

Yeah, we agreed on that . It took millions for our company to support OpenGL/CL only because we did not want to make our code dependent on just one provider. It was tough to justify that decision (financially). Decision that only started to pay back with Android popularity.

The good part is, since all of them (Vulkan as well as DX12 and Metal) have roots in Mantle, they have a lot of similarities, which makes creating translation layers easier. So I wouldn't be surprised if we'll see Vulkan → DX12 layer in addition to Vulkan → Metal one. As well as other way around.

As though its of no cost to Apple to make Metal available on every platform, or support other products on their platforms?

Not every decision has to be filled with malice, sometimes it just makes sense.

> As though its of no cost to Apple to make Metal available on every platform, or support other products on their platforms?

It was of no cost for them to simply copy most of the ideas from Mantle to make Metal, saving all that huge effort on initial design, isn't it? Somehow that doesn't surprise you. But when they are criticized for not doing it in the opposite direction (by sharing the effort and supporting the common API), you are surprised.

PS: Things like compilation of shaders really made us suffer with OpenGL/CL. Those guys did not want to do it, so simple, and they did not do it for years, because they could.

No matter what feedback from developer were, those people didn't care. But Microsoft did and forced the guys to react much later.

The same thing happened with so many things to mention here, like asserting the same quality on different machines that save millions to companies in debugging time and money.

This is really more a case of fragmentation than it is of competition.

"They have every logo on here except Apple," was the first thing I thought upon seeing the page.

You can still use OpenGL on OSX / iOS. If the Flowchart is true, then it wouldn't matter for 80% of people, for the rest, there is Metal.

> for the rest, there is Metal.

The question is why Apple can't support Vulkan, or rather why wouldn't they. The answer is quite obvious - they like lock-in.

> If the Flowchart is true

Flowchart is not true, because using OpenGL is not a good proposition going forward. Some will develop more tools and higher level frameworks to make using Vulkan easier. But jerks like Apple, MS and others will put roadblocks for developers preventing them from using the new API on their platforms.

"because using OpenGL is not a good proposition going forward."

Why? Khronos has publicly stated that development of OpenGL will continue, and that OpenGL and Vulkan will continue to co-exist.

> Why?

Because it's inherently stuck in the outdated model of using huge state machine where state is shared. It doesn't allow using parallelism efficiently.

> Khronos has publicly stated that development of OpenGL will continue

They are free to continue it, but I don't see a benefit of using it instead of Vulkan for anything new. The main drawback of Vulkan now is that it's low level in comparison with OpenGL. That gap will be filled in with frameworks on top of Vulkan which will provide higher level abstractions implementing a lot of common boilerplate while using Vulkan's approach of avoiding massive state machines. And those who need that low level directly can always go there. So why would you use OpenGL exactly?

This is kind of turning into FUD, the problem with OpenGL is not state - that is the problem with DX11, but for OpenGL we have AZDO in theory and properly implemented you should not see more stateful overhead comparing a Vulkan vs AZDO program.

The problem with OpenGL is that despite the official version being 4.5, and that including all the useful mechanisms to reduce overhead and make your renderer CPU efficient, only AMD and Nvidia proprietary drivers on Windows and Linux support it - which means you cannot realistically actually use it without having the same "minimum version renderer with extensions for optimization and features" model that makes writing OpenGL programs literal hell.

The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".

It's not a FUD. OpenGL was strongly overdue to be redone from scratch completely, and it's just great that Vulkan eventually was born from this necessity.

> The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".

It's both. AZDO attempted to fix serious deficiencies of the API without rewriting if from scratch, making it a rather awkward and not easy to use addition. Vulkan solved the same problem building it neatly from the ground up.

And of course making compliant and verifiable implementations is a great benefit of Vulkan, and it's something that OpenGL always lacked.

"So why would you use OpenGL exactly?"

Because I care about working on phones, and on crappy old video cards and iOS and OSX.

Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound, and that only happens on high end video cards, which are handling my workload without a sweat, so why would I bother optimizing those?

Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.

Because the work I do is more closely related to the CAD market than the video game market, and I know that there's enough money in CAD, and that OpenGL is not going anywhere for CAD, so I'd bet that OpenGL will be around for ~25 years in some form or another. I wouldn't place that bet on Vulkan.

> Because I care about working on phones, and on crappy old video cards and iOS and OSX.

Sure, OpenGL will remain useful for supporting both legacy applications and legacy hardware.

> Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.

I answered that above. It's not a reason to use OpenGL, it's a reason to write something on top of Vulkan to make things easier.

> Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound

It provides a benefit of using your hardware to full potential. You can't even properly saturate the GPU with OpenGL with parallel workload, unless you use AZDO and other such things which turn it inside out trying to bypass its limitations.

> Because the work I do is more closely related to the CAD market

And why exactly Vulkan can't be used in the CAD market?

> OpenGL is not going anywhere for CAD

Longspeaks has the CAD industry to thank for.

More likely, they committed to Mantle and now they have have to maintain it. The manpower to maintain 3 separate graphics back ends probably wasn't worth it, especially since big portions of the OS libraries now support metal.

My first thought on seeing Vulkan is that it is basically Metal for everyone else. Is that not so? Then why would you expect Apple to support Vulkan given that they already have Metal?

It's like saying that Apple shouldn't support JavaScript in the browser and should use AppleScript or anything else as long as it's incompatible (remember browser wars?). Why they should use it is quite straightforward - because it reduces duplication of work. Why they don't use it is clear as well - because they want to tax cross platform development with that extra burden. I.e. they use development tools as lock-in tactic. That's simply crooked.

Some history can also help. It all started from Mantle. Basically AMD grew tired of current APIs being behind the curve, and designed one from scratch that matches modern hardware approaches. Then Apple and MS used those ideas to push their lock-in off-shoots (they copied most of the ideas verbatim, working closely with AMD). Meanwhile, AMD simply opened up Mantle (they voiced this intention from the beginning) and gave it to Khronos as an initial proposal for Vulkan. The rest you probably know. So why exactly MS and Apple didn't get behind the shared effort? Because they are lock-in jerks. That's all there is to it.

This seems cognate to "Web standards are basically an alternative to the way IE 6 works, so why would you expect Microsoft to support Web standards?"

Yes, the crappy OpenGL version that they ship. Which lacks things like compute shaders. We are already seeing issues because of that: even though Elite: Dangerous runs on the Mac, the expansion does not and will not, as it requires compute shaders.

No, you really can't. Not only is the version available on OS X significantly out of date, it isn't even fully functional for the level of OpenGL it claims to support.

That's crass: Apple has Metal, and has had it for a few years now, so perhaps a healthier attitude is to give it time.

Apple knew where things are going all along. See my other answer: https://news.ycombinator.com/item?id=11112078

So it doesn't excuse their lack of support for Vulkan in any way.

They don't need excuses when they don't behave as you wish, as they aren't subject to your whims.

> They don't need excuses

Sure, I'm not saying they are looking for excuses. They are just lock-in jerks and never really hid the fact.

Apple doesn't have infinite software engineering resources. In fact, given how slowly they adopt new OpenGL stuff, it's probably safe to say that they're pretty constrained on software engineering resources when it comes to low-level graphics technologies. So it's not surprising at all that they've chosen to focus on Metal instead of implementing Vulcan.

As for why they did Metal, they most certainly started work on it before the Vulcan project started. Wikipedia says[1] that the Vulcan project was started in July of 2014 (and then announced publicly at SIGGRAPH, which appears to have been in August). But Apple released metal with iOS 8 in September of 2014, and they'd obviously been working on it for more than a couple of months.

In an ideal world, Apple would support both. But it's not an ideal world and supporting Vulcan would take resources away from their work on Metal, and that's not something that makes sense for Apple to do.

[1] https://en.wikipedia.org/wiki/Vulkan_(API)#History

> So it's not surprising at all that they've chosen to focus on Metal instead of implementing Vulcan.

That's not the real reason, unless Apple will claim that they can't plan things right. They knew Vulkan was coming, so they could allocate their resources to it from the beginning. But they decided to push for Metal instead.

The history you linked to is missing important events prior to that. See here: https://news.ycombinator.com/item?id=11112078

TL;DR: Vulkan wasn't born out of nothing. Things started with Mantle. Apple didn't want to share effort in both directions joining the open API (which ended up in Vulkan), and made their Metal for themselves only, using the same Mantle as the source.

Their hardware vendors already wrote drivers that support vulkan for other platforms. If Apple is so resource constrained (despite sitting on billions of dollars in cash) why do they insist on building it themselves when they can't keep up?

Reply on news.ycombinator.com