[NickGerleman]

"The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms."

So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?

[om2]

We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the web.

Things worth noting: - We believe other browser vendors agree with us that the web API should work on all three of the major native APIs. - The web has security requirements which force us to go a bit higher-level than Vulkan anyway.

I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.

[hota_mazi]

> I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.

No, it's not a separate issue.

If Apple supported Vulcan, the simple act of proposing this new API as a standard would be laughed out of the room.

We can only speculate why Apple won't support Vulcan but I'm going to go with "Prefer a solution they designed themselves over one designed by other parties".

Just support Vulkan and let's abandon this silliness, shall we?

[om2]

I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done.

In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance.

So either way, we need a cross-platform graphics API.

Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs.

[ioquatix]

I think what you are going to find is that there is a lot of frustration w.r.t. Apple not supporting Vulkan. One system for everything else and one system for Apple.

> I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done.

Nothing you assert here is invalid. But, I think you've missed the main point, which is that people don't want an entirely new API, they want the same API across all platforms. Vulkan, exposed directly in JavaScript as much as is feasible (e.g. using an automatic API generation tool) would be awesome.

Simply look at how it is possible to cross-compile C/C++ to JavaScript. Now, add in support the Vulkan API. That would be incredible.

> In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance.

Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not.

> So either way, we need a cross-platform graphics API. Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs.

I think you are missing the point here again. As you say, we need a cross-platform API. But, by that logic, accepting that JavaScript is just another platform, we'd like the SAME API.

[Rusky]

> Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not.

Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. Direct3D 12 is at the same level as Vulkan, and I see no reason for the trend of D3D being higher quality than GL to end with Vulkan.

[ioquatix]

Those are pretty subjective assertions. Do you have any evidence to back that up?

[brians]

Vulkan isn't designed for adversarial input. The web language has to be. That alone is likely to require a ground-up redesign.

[boardwaalk]

But OpenGL wasn't either. I'd like to hear concrete examples of how it couldn't be made workable. There are already validation layers that do a pretty good job of checking for bad usage.

Especially since things like NaCl exist(ed) which are inarguably lower level and still safe.

I think it's folly to create a whole new API before evaluating the option of using Vulkan.

[ioquatix]

I'd argue that Vulkan IS designed for adversarial input. It deliberately provides a layer mechanism within the driver for validation of function calls. It's trivial to create your own layers and they can be used to validate EVERY entry point into the Vulkan driver.

[andreyf]

> One system for everything else and one system for Apple.

This seems to have worked out pretty well for innovation in the mobile OS market, no?

[ioquatix]

Yes, for Apple... For the consumer? I don't think so.

As a consumer, the mobile device market is a walled garden. Are apps compatible between platforms? Do you have control over your hardware? Can you choose what software you run on your own device?

[xenadu02]

Vulkan is not suitable for exposure directly to the web. Full stop.

Therefore your posts are off-topic.

[ioquatix]

Do you even know how Vulkan works?

The driver API exposes a layered stack. It's trivial to add a validation layer between the driver and the client. It's SO much better than existing OpenGL or DirectX driver models for this one reason alone.

[sametmax]

The persons in favor of Vulkan in this thread don't have to prove their point, you have. Their solution works, is battle tested, is cross platform and almost an industry standard.

Unless you backup the Apple proposal with serious evidences such as :

- hard metrics on performance benefits, why you need them, and why you can't improve vulkan to get them;

- demonstration of blatant issues with the vulkan API and very good solution you can implement and why you can't improve vulkan to get them;

- strong evaluation of the benefits your solution provide given the cost it would have compared to adopting vulkan.

Then you have no credibility.

"Let's fix something that works" is rarely welcomed in programming. Coming from a company that is well known for disrespecting the rest of the world by creating their own island of closed standards and help noone pass the border, it's even worst.

On this one, you are guilty until proven innocent, I'm sorry.

[lallysingh]

> On this one, you are guilty until proven innocent, I'm sorry

Or rather, he's got to refute the null hypothesis.

[om2]

In the case of web standards, the null hypothesis is "no new API" rather than "make something that works only on top of this specific native API". For the web, the latter is not even the default assumption once you've decided something needs to be added. The web is cross-platform by design.

[hota_mazi]

I understand and see some merit to your angle, but at the end of the day, I don't think Apple will be taken seriously in that area until they support Vulkan.

Go ahead and do that, then we can talk about going up the stack and judging the API you're proposing (and let's be honest, it's really Metal-for-Javascript).

Show some good will.

[threeseed]

Apple will always be taken seriously since they are not just a major mobile vendor but the only vendor capable of getting any technology widely deployed.

Your arguments are very reminiscent of the "Apple must adopt Flash" era. And as we've learn Apple was 100% right to dump that technology as it was simply a poor fit for mobile.

I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API.

[ioquatix]

> I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API.

And you are qualified to make this assertion because?

It would make an awesome JavaScript API. It is well defined, well supported, well documented low level API for graphics. It would easily be exposed within JavaScript.

[modeless]

> Lots of design work needs to be done.

So support Vulkan and then let's do the design work! The choice of underlying system API has effects on the design of the upper layers. Your refusal to support Vulkan is blocking progress.

[andreyf]

Why so combative? How is a JavaScript API standard going to benefit from Vulkan support on Apple platforms? More specifically, how will a JS API benefit from being built exclusively for Vulkan, instead of multiple "APIs that have nuanced architectural differences", to borrow Dean's phrase?

[modeless]

To the extent that Vulkan has capabilities or features that don't map perfectly to Metal capabilities and features, native Apple Vulkan support would increase the performance and capabilities, and reduce the complexity and bugginess, of a hypothetical WebVulkan implementation on Apple platforms. And by reducing the compromises that have to be made for platform compatibility it would benefit the API design on all platforms.

[shmerl]

You can simplify the design and reduce bloat if you don't need to address multiple APIs as backend.

[kartan]

> I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done.

Isn't that what we want? A low-level not opinionated API allows the market and the open source community to create solutions that are subject to competition.

If we get an opinionated high level API then we are close to future developments by small agents. Only the big players can decide on the future of 3D graphics on browsers.

Why can't Apple just develop their ideal API over Vulkan and let developer decide what to use?

[zanny]

> Why can't Apple let developer decide what to use?

Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?

[kabes]

You wanna focus this discussion on improving the web platform? Great, start with finally shipping WebRTC.

[alwillis]

Relax--they’re working on it: https://webkit.org/status/#specification-webrtc

[zbuttram]

What people seem to be missing here is that based on available info it seems Microsoft isn't officially supporting Vulkan either. Sure Nvidia and AMD have released drivers for Windows that have Vulkan support, but we're talking about a web standard that would need to be implemented by browser makers and if Microsoft isn't going to use Vulkan, then what do they implement as the backing for this new standard in Edge? Probably DirectX. I think the idea is to sort out an API that would be compatible between all three due to Microsoft and Apple _both_ not wanting to officially support Vulkan over their own platforms in their browsers, regardless of the support at the OS level.

[modeless]

There is a difference between "not officially supporting" Vulkan and completely preventing anyone from providing a Vulkan implementation for your platform. Microsoft allows competing APIs to be integrated into their platform at the driver level. Apple does not.

[cma]

FWIW, Microsoft doesn't allow that on ARM. Only where they have previous antitrust decisions holding them back (x86).

[mrec]

It used to be the case that 3D APIs other than Direct3D couldn't be used from whatever Metro^H Windows Store apps are called this week. Which kind of blocks it at a platform-within-a-platform level.

That may have changed, I dunno.

[vondur]

Could someone not provide Vulkan driver support on the Mac or is it forbidden by Apple to do so?

[mrec]

On Windows, Vulkan support is provided by the IHV graphics drivers from Nvidia, AMD etc. On Mac, Apple themselves ship the drivers (incorporating some portions of IHV code, but ultimately all under Apple's control).

[threeseed]

Apple allows you to provide an alternative API on OSX but not on iOS.

Microsoft is exactly the same. They do not support custom APIs on Windows Mobile AFAIK.

[modeless]

> Apple allows you to provide an alternative API on OSX

I'll need a source for this claim considering that no driver-level Vulkan implementations are available on macOS.

[MikusR]

It's a dead platform with no market-share.

[AsyncAwait]

Why are they so hostile to Vulkan and what problems does Vulkan, which is vendor independent and open, have that adding a new API to support to the pile would not?

[shmerl]

No good reason whatsoever.

[MBCook]

Do you have a source for your claim?

[hota_mazi]

NIAA.

Not Invented At Apple.

[slavik81]

It's not even that. They seem to have abandoned OpenCL as well, and that was invented at Apple.

[TazeTSchnitzel]

> Microsoft isn't officially supporting Vulkan either

It's Microsoft's lack of official support for OpenGL on Windows that leads to WebGL implementations using of ANGLE translation to Direct3D, rather than direct OpenGL, right? So I assume we'd have the same situation for a hypothetical WebVulkan. Yes, Vulkan would be available on Windows with the right drivers, but the browsers wouldn't want to use it.

[ioquatix]

I was under the impression that DX wasn't available out of the box either? That you'd need to install suitable drivers and a suitable runtime?

[pjmlp]

Starting with Windows 7, DX became a platform component.

[pjmlp]

Also HN seems to forget consoles a lot, which don't support OpenGL (PS3 GL was never used in production), even Nintendo with Switch actually does have another API besides Vulkan(NVN), which devs are more keen in using as it allows even more fine grained control.

[seanmcdirmid]

I'm sure Microsoft has an interest in a 3D web API working on top of D3D, even if NVIDIA and AMDS are putting out Vulkan drivers for the platform (Microsoft is not supporting Vulkan themselves as far as I can tell).

[philippeback]

Anyway, WebVR support is shaky on most browsers, except Firefox / Nightly where it works properly. Get that working before WebGL 2 or whatever. And throw in some support for external GPUs. Moved away from Apple and got myself an Intel NUC i7 w/ Thunderbolt. Better everything in there. Can use external GPUs of all kinds for easy testing. Apple may have had its best quarter ever but is not sexy to me anymore.

Yeah, support Vulkan.

[rehemiau]

> I understand your desire to have Vulkan on Apple platforms, but

There are no 'but's. Just support it and we can have simpler APIs on top of it.

[ionwake]

I agree

[angry-hacker]

While I agree with you, I doubt some random webkit engineer has any power saying what to support.

Apple never listens to anyone, probably some higher exec wants better lock in and that they design the standards. Everyone else keep their mouths shut.

[shmerl]

Then why should W3C accept the views of that higher execs as something useful for the Web? Let them remain Apple only.

[ChuckMcM]

The optics are just really bad. Apple could say "In the mean time we'll support Vulkan" and bam! there is a cross platform solution. Instead you say "We will generously let everyone implement our specifications, we hate to see everyone suffering so, but if everyone else works really hard to do what we say, things will be great!"

[om2]

I don't get what you are suggesting. Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. We're expecting work on the new web API to be super collaborative, so your framing is uncharitable and incorrect.

[ChuckMcM]

Not trying to be uncharitable here, I'm just sharing how it looks to someone driving by.

That doc says:

"It[WebGL] was based on OpenGL ES, a cross-platform API for graphics targeted at embedded systems. This was the right starting place, because it made it possible to implement the same API in all browsers easily, especially since most browser engines were running on systems that had support for OpenGL."

And then it says later this:

"The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms."

And one imagines you could put up a big chart and have all the platforms as the columns and each technology as the row, and show all of the gaps. But the consensus is that Vulkan would show up on all the platforms except Apple's. So one might ask "well if you put Vulkan on your platforms, then you would be back to the WebGL situation where you had stuff that ran on all platforms and you could work on a Web API to that code.

So "optically" which is to say, to a casual observer, it seems like Apple is saying everyone put this new thing on your platform as this web api we're working on will talk to it.

I understand that you just want the best experience possible given the advances that have been made in GPUs over the last decade.

[MrScruff]

But isn't the Vulcan situation on windows similar to the OpenGL one? You need to install drivers...

In which case won't browser makers target directx anyway, as they have with webgl?

[jamstruth]

Why would Microsoft behave any differently to this new API when they have not officially supported previous open attempts?

Adding another standard to the mix just seems to be compounding the problem to me.

[Benjamin_Dobell]

I think it's a bit disingenuous to say they're totally orthogonal. Presumably you understand that if Apple supported Vulkan natively, then "WebVulkan" would be the obvious choice for a web API (just as it was with OpenGL/WebGL).

[om2]

I don't think browsers will choose to pipe this through Vulkan drivers on Windows (since they are all unofficial and in general don't have as complete coverage) and I don't think they'd choose to use unofficial Vulkan drivers for Apple platforms either, even if they existed.

Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road best not traveled.

[comex]

> Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road best not traveled.

Are you sure? Don't forget about WebAssembly… Just as Emscripten currently exposes the original OpenGL ES API as a wrapper for WebGL, for the sake of porting existing C/C++ code that uses it, in the future there will be a desire to port Vulkan renderers to the web. That will be easier if the browser API is based on Vulkan; otherwise you'll end up with a shim on top of a shim. Also, the same arguments about developer familiarity that led to WebGL being designed as it is could apply just as well to Vulkan - albeit somewhat more speculatively, given Vulkan's newness.

[chc]

What does "unofficial" mean here? AFAIK Vulkan is fully supported by the current versions of both AMD and Nvidia's Windows drivers, which seems about as official as a driver can get.

[shmerl]

So who stops Apple (and MS for that matter) from making it official? If it's about collaboration, let them grow up and stop their petty lock-in games. And if not, I don't think anyone should accept proposals coming from them for such things.

[ioquatix]

If Apple supported Vulkan, all major platforms would support the same API. Exposing this to the web would be relatively straight forward. So, I don't think your assertion that they are orthogonal goals is correct.

[sydd]

Why come up with a new API for this? Why not use the one supported by Google, and MS, Vulkan? We dont need another (a fourth!) API for the same thing. Introduce a web variant like Khronos with with WebGL (its almost like OpenGL ES, which is almost like OpenGL).

[acqq]

> Why not use the one supported by Google, and MS, Vulkan?

https://www.lunarg.com/faqs/microsoft-support-vulkan/

"Microsoft has not expressed intent to support Vulkan."

[sydd]

and the next sentence goes "However, there are well defined mechanisms by which IHVs can ship a Vulkan driver on any version of Windows. But it will be as it is the case now with OpenGL. That is, it is up to the application to negotiate with the implementation to install an appropriate Vulkan driver for the hardware that is on the machine."

Also "Vulkan is available on all versions of Windows that are on DirectX 12, so there is potentially some value to the developer community to having a single API that spans multiple Windows versions."

Vulkan is fully supported on Windows with semi-recent GPUs (e.g. its supported by Nvidia with Geforce 6xx - released in 2012!) by all vendors.

The article is only saying that MS defers what API is supported to GPU manufacturers. Its not supported by Xbox and Windows Phones, but Xbox is a very different market and no one cares about Windows Phone.

[goldfire]

They don't need to support it, because the GPU vendors have done so in their drivers, so it works fine on Windows without Microsoft's assistance.

[surrealize]

> Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal.

The web GPU API and the lower-level API aren't "totally orthogonal" if you're using the Metal shader language in your web GPU API! You're trying get web authors to use (a part of) Metal! It's totally not orthogonal.

[om2]

The Metal Shader Language use in our prototype is totally a placeholder, and the post says so. We expect the standards process to define new source and binary representations, possibly based on Khronos's SPIR-V.

The shader language is partly independent of the API though, and we though the API was the interesting thing to prototype, more so than shaders.

[shmerl]

That's already something. But you shouldn't have started with a bad placeholder, waiting for others to criticize and propose replacing it. Start with open languages and technologies right away.

[givinguflac]

Don't bother, they clearly don't get it.

[slavik81]

I have to agree. They lack credibility in this discussion. Apple's abandonment of open standards on the desktop leaves their proposal of related web standards looking very cynical.

[madeofpalk]

...but Vulcan wouldnt run in a web browser anyway so whether Apple platforms support Vulcan or not is kind of beside the point, isnt it?

[saurik]

That's like saying "OpenGL doesn't run in a web browser"... and then it did, because someone understood that having 99% the same API and shader language support in a web browser as what is used in native applications is extremely high value.

[MrScruff]

It runs in a web browser sitting on top of different underlying apis though. Which is basically what's being suggest here.

[saurik]

Many of the people in this thread are looking for the analogous solution to WebGL for Vulkan, and the primary argument for not doing it from the WebKit engineers is that Vulkan is a lower-level API than Metal and DirectX 12, which makes it difficult to impossible to simulate efficiently on top of those APIs; but, this is actually only a problem because Apple refuses to implement Vulkan.

[Nullabillity]

> We're not complaining, we're explaining the lay of the land.

No, you're stating your own company's ambition.

[dman]

While I have your attention - what can be done to improve the state of Vulkan and OpenGL on the mac - its the single biggest reason for me to ragequit the OSX platform every time I try to give it a shot.

[om2]

I think you'll want to talk to Apple Developer Relations and see if they can put you in touch with the teams responsible for the GPU-level stuff. We as the browser team can't do much with this feedback.

[dman]

I will try do do this, though I remain sceptical that this will lead to anything. Not supporting external graphics APIs and Apple effectively controlling the drivers seems to be more of a business decision to me than a decision from a tech / dev relations team. Unless someone high up at Apple takes a call that supporting something like Vulkan / OpenGL is the path forward I doubt that this can be solved in a bottom up manner.

[EdSharkey]

Hi om2, this is completely off-topic, but I'm so intrigued that Safari devs are actually chatting openly about their product, I figured what the heck I'd ask something.

A few years ago, I tried my hand at making an HTML5 application using the apple-mobile-web-app-capable, apple-mobile-web-app-status-bar-style, apple-touch-icon-precomposed META tags and the apple-touch-startup-image LINK tag.

It was so slick how the iPhone put my webapp's icon on the home screen and had a very beautiful startup splash screen as well. It felt very native and I could feel Jobs' influence on the way that presented, especially because it reminded me of his original iPhone reveal where he hinted that one would write apps for the iPhone using HTML5 (this was prior to the appstore.)

Ultimately, I had to give up on offering my webapp as a homepage app because of differing behaviors of my page in application mode versus in Safari.

For one, if the user switched applications and switched away from my html5 application, it would fully unload. Whereas the same web page would only pause/suspend if safari lost focus (I assume this is iff there is enough memory to keep the tab alive/passivated, which is of course reasonable.)

I can't have my webpage unload/reload on focus changes because it's a single-page webapp and keeps a lot of transient state.

Second, if I recall correctly, there was some oddities about the browser chrome that differed between application mode and safari mode whereby you stole some extra screen real-estate in application mode with an opaque bar and I needed that space for my layout. This second issue I think would be already addressed because your devices post iPhone5 have larger screens.

It would be so neat if these limitations were lifted on HTML5 applications and I could offer it to my users! Are there new/recent improvements to the system that you can share with me? Are there any super secret toggles I might add to my meta tags to tell the iPhone to preserve my HTML5 app's context as aggressively as Safari?

Thanks for talking even though people here are dogging on your proposal!

[om2]

I appreciate the list of issues affecting home screen web apps on iOS. We're looking into improving how they work. I can't promise any specific set of improvements or timeline but we are aware of the issues you mention.

[EdSharkey]

Appreciate the willingness to address it, it would be the completest thing if HTML5 Apps worked as well as safari tabs. Very empowering thing for you to do for us web devs, thanks!

If you can share any history or stories about the origins of that feature landing on the iPhone, I would be grateful. I find it all fascinating.

[sipos]

It is a serious problem for the future of Apple that they have almost completely lost the support of software developers. It used to be that most software developers had MacBook Pros and, the ones that didn't wished they did. Now software developers are generally buying non-Apple machines and running Linux or Windows. In the short term, this is only a tiny market so the loss of sales is irrelevant but, these people are people that other people look to when they are deciding what to buy and, they are people that develop software that other people use. If there is no decent software for Mac OS because none of the developers who would otherwise write it and release it use it anymore, it will make it much harder for other people to use. Both of these are long term effects and, it is too soon to show their effect on sales but, they are important. Since the release of Mac OS X, it has been an attractive platform for developers but, this has completely changed in the last couple of years and, the only reason to use it now is for iOS development IMHO.

Windows has done an awful lot to make itself more attractive to developers recently because they get that it is vital for their future. I hate Windows but, even I have to admit, it has got way way better.

Apple's decision to stop producing things like AirPort Extreme or monitors is a stupid decision in the long run too. Even if these don't make any money on their own, part of what makes Apple an attractive platform to people is that they can buy everything from Apple and it work together so, even if these lose a bit of money, they make sense to do.

There are an awful lot of reasons to not use Mac OS so, it has to get the reasons to use it right and, it is quickly losing them. Fair enough, most of their money comes from selling iPhones but, sales of these will be seriously harmed in the long run if Apple can't sell other systems that integrate well with them. For example, Microsoft would not have to port or update Office on iOS if there wasn't the possibility that it could weaken their hold on the market if there was a Mac and iOS Office alternative. As it is, they would be insane not to support it on iOS but, without Mac OS and Macs, not doing so would be an option and, it would be a serious selling point for Windows phones. Apple's strategy is seriously broken and, it is going to be a serious problem for the company in the long term if it doesn't fix it soon, if it isn't already too late.

[Gorbzel]

Oh please. Stop claiming every pet issue you have is shared by every developer and that it's "already too late."

[sipos]

Where do I point to any "pet issues"?

I don't say it is already too late, I say it might be. That may be overly dramatic but, unless you refute that there is a problem with an actual argument, you are hardly arguing against that.

[Xixi]

Not the person to whom you are asking, but this is my perception of Apple.

The state of OpenGL will never improve: if you've followed Apple at any point over the last 25 years, it's pretty clear that they disengage very quickly from any technology that is starting to look deprecated/not the future. It works for hardware and software: first iMac with only USB and Ethernet, dropping the floppy drive, dropping CD/DVD drives, avoiding Blue-Ray entirely [1], only USB-C on last MacBook Pro, flash, etc. So my opinion is that OpenGL will never be developed further at Apple. They will probably drop all OpenGL support at some point in the next few years.

The other thing that is clear is that Apple doesn't like having their hands tied by third parties. The lack of adequate Kaby Lake processors for the launch of the last MacBook Pro, and the subsequent heat/hatred directed towards Apple because of it [2], is probably making quite a few people think that at some point they will really have to move the whole Mac line to Apple made ARM processors.

Apple started to ship a working Metal implementation to iOS developers before Vulkan was more than a draft [3]. This freedom to move at their own pace is worth a lot to Apple. Vulkan is a great piece of technology, but I don't have high hopes for it to be supported by Apple anytime soon.

[1] There were some licensing issues there, but had Apple thought the future of media consumption to be BR I'm sure they would have found a comprise. Instead they found an excuse to promote streaming / the Apple TV.

[2] Including on HN, where I would have thought the average reader to be a little bit more sophisticated on these technical matters.

[3] I don't have the exact timeline in head, so I might be wrong.

Edit: typo

[yellowapple]

"We're not complaining, we're explaining the lay of the land."

The "lay of the land" is that the rest of the world is adopting Vulkan, and therefore the right target for WebGPU is very obviously Vulkan. Even macOS and iOS can (theoretically) support it thanks to MoltenVK [0], and Vulkan is already available on Windows. Trying to wrap all three "major" native APIs is pointless when there's already one that works everywhere and does so reasonably well.

[0]: https://moltengl.com/moltenvk/

[om2]

Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS. We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.

[modeless]

> Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS.

This is not materially different than the situation with OpenGL, and yet I hope you'll agree that basing WebGL on OpenGL was the right decision, rather than inventing a new API based largely on a lower level API proprietary to a single company's platforms.

[om2]

As it happens, OpenGL was so high level that supporting it on top of DirectX was feasible. A number of Windows browsers use the DirectX back end to ANGLE, so users don't have to download OpenGL drives.

Unfortunately, that doesn't work as well for Vulkan. Vulkan is the lowest-level of the three APIs, so it's hard to support on top of Metal or DirectX 12.

[modeless]

Since WebGL was released, Microsoft has demonstrated a new willingness to support Web graphics. They joined Khronos, and now ship a WebGL implementation of their own with Windows. I have confidence that if the industry moved toward a WebVulkan standard that this new Microsoft would make platform changes to better support it. Unfortunately I have no such confidence about Apple.

[dman]

I would much prefer hardware vendor supplied drivers since they have an active interest in adding support for newer versions of graphics apis. OS vendors have proven to have a very poor track record supporting newer versions of graphics apis that they did not create themselves. (Microsoft support for OpenGL on Windows and OpenGL/Vulkan support on Mac). Calling driver vendors "unofficial" seems a bit backwards to me.

[Rusky]

You're leaving out the "official" counterpart- Direct3D drivers. Microsoft and hardware vendors both have an active interest in adding support for new versions there.

[vetinari]

Microsoft has interest for pushing new versions only in new OS releases and uses that to push these new OS releases - see DirectX since 10.

GPU vendors do not care, they will give you API to their hardware for any OS version that moves their wares. That's why I would trust more GPU vendors than OS vendor.

[cmiles74]

Is it your position that the only drivers worth using are those produced by the operating system's vendor? While I suppose this would make sense to Apple, it sounds entirely crazy to me. IMHO, it makes much more sense for the hardware vendor to write the drivers.

[MrScruff]

The web is supposed to be a universal platform. It doesn't make much sense to limit a feature to the subsection of web users who install graphics drivers.

[yellowapple]

In the case of Windows, the operating system installs proper drivers automatically. I don't recall if these are the exact same ones from, say, the NVIDIA or AMD or Intel website, but I'd be very surprised if these drivers didn't nonetheless ship with Vulkan support.

On the flip-side of that, the web is supposed to be a universal platform. It doesn't make much sense to limit a feature to the subsection of web users who have hardware that supports 3D acceleration. :)

[cmiles74]

I'm not saying that operating system provided drivers should be ignored, but that it makes no sense to ignore vendor provided drivers either. In this case we have all the major GPU vendors on board with the standard, yet Apple claims that since the OS vendor (i.e. Apple themselves) doesn't produce the driver, it shouldn't be depended upon.

[int_19h]

What do you mean by "unofficial drivers"? Looking at the support matrix on Wikipedia, it seems that both NVIDIA and ATI support it in their official Windows drivers.

[Strom]

I guess he means that Microsoft isn't aggressive enough in distributing these drivers via Windows Update. Definitely the case with older Windows versions like Windows 7 where Windows Update doesn't seem to offer GPU driver updates at all if you have manually installed something like the driver cd that was in the GPU box. However with Windows 10 they have gotten more aggresive in updating these drivers. [1] Still, a lot of people on older Windows versions where the GPU drivers are likely out of date enough not to contain Vulkan.

[1] http://winsupersite.com/windows-10/stop-automatic-driver-upd...

[yellowapple]

"Still, a lot of people on older Windows versions where the GPU drivers are likely out of date enough not to contain Vulkan."

My guess would be that these same drivers would be out of date enough not to contain DX12, so if that's really the target, then there needs to be a fallback to OpenGL and/or an older DirectX.

[MBCook]

I believe he means unofficial as in not provided by Microsoft. Microsoft works to make sure Direct3D works and I imagine they have lots of tests and compatibility suites there. I'm guessing they don't have any tests or standards were requirements around Vulcan.

[vetinari]

> I believe he means unofficial as in not provided by Microsoft.

Microsoft is only middle-man, the drivers are written by GPU vendors in the first place. Why should I prefer middle-man to the original source?

Historically, the drivers provided by Microsoft via Windows Update were worse (older) than those provided by GPU vendors directly.

> Microsoft works to make sure Direct3D works and I imagine they have lots of tests and compatibility suites there.

So do Khronos group and GPU vendors for Vulkan.

[21]

NVIDIA/AMD drivers with Vulkan support pass through WHQL, which is as official as a 3rd party driver can get.

So calling them unsupported/unofficial is quite a stretch.

[MBCook]

Does WHQL actually include any Vulcan tests? The driver may be officially certified but is the featur in question?

[ioquatix]

What's probably more relevant is that those drivers pass the Vulkan conformance tests.

[jra101]

Intel's drivers may be beta but official NVIDIA and AMD GPU drivers both fully support Vulkan on Windows.

[ioquatix]

> We don't think it's right to depend on this even if it's theoretically possible.

Care to elaborate on that?

In the worst case, someone could implement Vulkan on top of the "supported" API. Or, the OS developers could get with the times and ship a modern, functional system?

[yellowapple]

I'd hardly call the drivers distributed both via Windows Update and via the vendors' own websites "unofficial". They're about as official as it gets.

[vetinari]

> Vulkan on Windows is all based on unofficial drivers

Drivers from GPU vendors are as official as it gets.

[Nullabillity]

> We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.

Then focus on fixing that, instead of wasting time on bullshit like this.

[nothrabannosir]

As an outsider, I'm very curious as to why this was downvoted. Is it incorrect? I know nothing about 3D platforms.

[pharrington]

You say Vulkan drivers will, for the forseeable future, be of lower quality than D3D12 drivers and lack official support. Lets assume I blindly accept this faith-based argument. WebGPU than, must be implemented on top of D3D12 and Metal, two already very different APIs. What, than, makes a hypothetical WebVulkan unfeasible in contrast to WebGPU?

[ioquatix]

Keep in mind that DX12 doesn't support Windows 7 or 8, so that cuts out a significant portion of the existing market.

[pjmlp]

Still higher than GNU/Linux will ever be.

[algo_cheese]

Not if you take Android into account.

[pjmlp]

Which is why I have precisely written GNU/Linux.

Android is a Java based OS, which happens to use Linux as kernel, Google can very easily change it to something else.

Only these set of C and C++ libraries are available to native applications on Android, which happen to be compiled to a .so anyway, to be loaded inside ART/Dalvik.

https://developer.android.com/ndk/guides/stable_apis.html

Trying to link into any other GNU/Linux library that happens to be on the devices, but isn't part of that list, will trigger an app termination, starting with Android 7.

https://developer.android.com/about/versions/nougat/android-...

Also, many POSIX APIs have been removed from the kernel and require extra wrapper libraries, if they can be emulated at all.

https://roxanageambasu.github.io/publications/eurosys2016pos...

https://thesai.org/Downloads/Volume4No7/Paper_15-POSIX.1_con...

[Rusky]

A hypothetical WebVulkan is tied to an API that it is guaranteed to have to translate from. A hypothetical WebGPU could simply be tweaked to better support its multiple target APIs.

[pharrington]

The straightforward translation and predictability of a hypothetical WebVulkan is a strong point in its favor. WebGPU's JavaScript interface can be changed arbitrarily, yes; there is nothing simple about that process.

[Rusky]

Vulkan (and similar APIs) are straightforward as translation targets, not so much as sources.

[AlphaSite]

Vulkan is a lower level API, so implementing it on higher level APIs becomes problematic.

[kristofferR]

Why is DirectX support needed? Isn't Vulkan supported on the same platforms as DirectX anyway?

[om2]

We expect DirectX 12 drivers to be more complete, more performant, and more likely to be available out of the box without a separate install. We expect Windows browsers will want to build on top of DirectX, not Vulkan.

[om2]

https://www.lunarg.com/faqs/microsoft-support-vulkan/

Microsoft won't support Vulkan officially, and apps would have to install their own Vulkan drivers.

[Kubuxu]

Not true, Vulcan drivers are included in drivers of the GPU manufacturer.

[MBCook]

No, Nvidia and AMD including Vulcan drivers. Intel isn't and said they don't plan to. Intel has a HUGE market share thanks to integrated graphics. There are other companies too.

[cmiles74]

I don't see why this would be the case. The vendors (i.e. NVidia) are providing the drivers, I see no reason why they would porposely cripple them.

[TazeTSchnitzel]

It's the current reality with OpenGL on Windows, which is why Windows browsers do not implement WebGL with OpenGL, but rather by translating to Direct3D.

Maybe it'll be different for Vulkan, but that would be a surprise.

[Rusky]

Because they have been doing so with OpenGL (an identical situation) for years.

Besides, "purposefully cripple" is inaccurate. They just put more effort into Direct3D because there's no reason to support OpenGL as fully.

[pjmlp]

Including the SDKs, AMD and NVidia SDKs for a long time used to have better DirectX tooling than OpenGL.

[ioquatix]

Care to back up those assertions with real world evidence?

[spatulon]

Chrome and Firefox felt there were sufficient problems with OpenGL driver availabity that they implemented WebGL using DirectX (via the ANGLE project), despite the more obvious mapping to OpenGL.

Is there any reason to believe that, unlike OpenGL, Vulkan drivers will be sufficiently widespread for browser vendors to use it on Windows?

[ioquatix]

That's really fascinating and I didn't know that.

[mrpippy]

Intel has no stated intention of releasing production-quality Vulkan drivers for Windows. Forum statement from August:

The current Plan Of Record is that Intel® is not supporting Vulkan on Windows drivers. The drivers that were made available on Developer.com are intended for Vulkan developers.

So, it is expected that some Vulkan drivers may not work for end users.

[ioquatix]

A quick google finds an Intel representative providing clarification: https://software.intel.com/en-us/forums/developing-games-and...

So, they ARE planning full Vulkan support on Intel iGPUs.

[obl]

xbox

[corysama]

Concrete example: The PS4 dashboard is actually WebGL via Chromium (https://www.youtube.com/watch?v=sIhtcUvi0BQ&t=55m25s) I don't think PS4 supports OpenGL, DX or Vulkan. Sony has their own API.

[snuxoll]

Sony has historically supported a variant of OpenGL on the PS3 (in addition to their low level API) - I would be surprised if they don't have one for the PS4.

[corysama]

I worked on PS3. PSGL is the half-truth rumor that refuses to die. It was an experimental GLES1.0 with Nvidia's Cg shaders as an extension. I don't think any games actually used it.

https://en.m.wikipedia.org/wiki/PSGL

[pjmlp]

Besides what corysama replied, there are a few game blogs that described how bad it was, but I cannot link to them as I am behind a proxy currently.

[snarfy]

If Vulkan doesn't have enough security features to support the web, you'd think Apple would work with Khronos to get them implemented, instead of rolling their own API.

It's yet more 'not invented here syndrome' from Apple.

[AsyncAwait]

Are you familiar with https://xkcd.com/927 ?

[microcolonel]

While Microsoft hasn't committed to supporting Vulkan first-party, every major Windows(and macOS) graphics vendor has a compliant Windows Vulkan driver which performs well, most vendors have two or three independent implementations. There are real applications being built today under the assumption that these drivers will continue to work.

Also, given that Windows versions other than ten still make up more than half of the PC market, Direct3D 12 is not even an option for most PCs, but Vulkan is.

So if we're being honest, it's not really "all three", but Apple vs. literally every other platform.

Obviously web applications can't simply be trusted not to crash an exposed driver, but "will result in a better API for the web." is exactly the opposite of what you would expect, given the history of high-level graphics APIs. Any layer of abstraction or heuristic other than those required for security reasons, will ultimately increase the number of implementation inconsistencies, that would be objectively worse.

Then consider just the shader language. It would be considerably easier and less error-prone to just support SPIR-V shader programs; but with this there will have to be even more levels of translation, even more places for things to go wrong, and a need to make completely new tooling to generate shader binaries.

Furthermore, driver bugs are a given, but Vulkan makes the skills to debug and report driver bugs portable across vendors and operating systems. If I'm an ISV and users are experiencing issues on Metal on OS X on an AMD card, I don't have layers, I largely don't know where to shim the library, and even if I could figure that out, why should I have to figure it out for every system?

[pjmlp]

Sony and Nintendo don't support it as well.

Sony doesn't has official plans to ever doing it, as the PS4 APIs are better anyway.

Nintendo is only supporting Vulkan for easing bringing in titles to the Switch, because they actually have a better API called NVN that exposes all the graphics hardware features.

[MrScruff]

Intel doesn't have a production quality Vulcan driver as of now.

Considering that browsers implemented WebGL on top of DirectX, why would it be any different for a proposed new API?

In which case it's reasonable to at least have a discussion about what this new API might look like.

[vbezhenar]

> Also, given that Windows versions other than ten still make up more than half of the PC market, Direct3D 12 is not even an option for most PCs, but Vulkan is.

What hardware Nvidia and AMD will support with Vulkan? It might turn out, that they will support relatively new hardware and Windows 7 usually used with older hardware, so it might be unavailable even for Windows 7. And if those users will upgrade to Windows 10, they'll have working DirectX 12.

[microcolonel]

They support mostly the same hardware with Vulkan, and they already ship Vulkan drivers by default through Windows Update. If they're on Windows 7, they'll have working Vulkan. If they move to Windows 10, they'll still have it.

NVIDIA provides Vulkan back to Fermi (April 2010). AMD provides Vulkan on all GCN models (January 2012). They provide this support on all supported versions of Windows. For Fermi cards, I believe NVIDIA may have shipped Vulkan drivers all the way back to Windows XP (though I think they stopped doing XP releases in June last year).

[mwkaufma]

Seriously, even fricken Nintendo is on board with Vulkan: http://www.gamasutra.com/view/news/287995/Nintendo_Switch_to...

[pjmlp]

Kind of, they have their own API that has better capabilities to expose the graphics hardware called NVN.

[fooey]

I don't know why Apple thinks they're going to have any sway over the people working on 3D graphics. Their hardware support for 3d graphics has been so awful for so long, I have a hard time imagining there's a very big user base they can leverage to get their way. So far as I can tell, what Apple wants here is almost completely irrelevant to the industry.

[errantspark]

I don't get it either. Apple graphics support has always been bad and it doesn't seem to have gotten better recently. Blizzard, a company that's always released their games for both Mac and PC, long before Apple even had a particularly relevant userbase was unable/unwilling to put in the effort to release their latest game (Overwatch) on Macs because they weren't able to garner satisfactory performance on Apple hardware.

Some relevant quotes:

“It was a result of not having all the technological support we needed to make the game viable on Mac systems.” says Kaplan, referring to Apple’s policies with OSX. “We have a real love and dedication for Mac players, they’ve been extremely loyal to us and we love giving them Blizzard games.

“But when dealing with the PC, the Xbox One and the PS4 - all of which are extremely welcoming to the technological needs to run a next-generation shooter - in a lot of ways we felt left behind, that we weren’t given the support we needed to make a great product on the Mac.”

[xenadu02]

Apple is proposing an open working group collaborate to agree on an open standard for low-level 3D graphics and compute workloads that all browsers can support.

What part of that is "leverage to get their way"?

The post explicitly states that they don't expect the WebKit syntax to be the accepted syntax; it is merely one implementation that can help inform the discussions.

If you want to vent your rage about 3D graphics on the mac go file a radar.

[tambourine_man]

Because iOS is incredibly relevant (many users willing to buy apps) and the A series chip actually has great graphics performance compared to the mobile competition.

[botverse]

IMHO you are underestimating the leverage that Apple has given that macs are the tool of choice for most web developers. Apple is probably aware of this and this move looks like an anticipation.

[unsoundInput]

IMHO you overestimate the use of macs as development machines, doubly so in parts of our industry that works on projects where high performance GPU APIs are actually needed (games, cad, simulations)

[vetinari]

I would be interested to know, where is such a place.

OSX support for OpenGL is several versions behind, with low performance and you definitely are not going to write AZDO OpenGL code there.

[sipos]

Macs used to be popular with developers but, this has basically changed IMHO. Perhaps they are popular with web designers still but, developers seem to be using Macs no more than the rest of the population to me now. It is Apple's complete lack of support for them that has brought this about IMHO and, I think it will be the end of Apple in the (very) long run (it will be the end of them as anything other than a phone manufacturer sooner and eventually completely I think).

[jolux]

>Macs used to be popular with developers but, this has basically changed IMHO.

Hedging almost-baseless assertions about verifiable facts by calling them opinions does little to hide the fact that you can't prove this and know you can't. IMHO, Macs are still very popular with developers, and the reason hasn't changed: a great GUI and a *nix command line. I personally would use Linux before Windows though because I hate both the Windows GUI and the Windows command line but I only hate the Linux GUI and could probably adjust to xmonad quickly and possibly even gain productivity. Granted I suppose I could use "Bash on Ubuntu on Windows" if I absolutely had to, however I think that name itself is an adequate synecdoche for my issues with the OS as a whole.

For what it's worth I feel pretty well supported as a Rust and Haskell developer in the Mac ecosystem, and Microsoft will have to do a lot better than give me bash to make me switch. It is a necessary but not sufficient condition for my computer usage ;)

[pjmlp]

I hate that being a developer requires me to be a FOSS UNIX guy from HN view on the world!

Not all developers care about it.

[abtinf]

The unstated point of leverage is iOS Safari. I would assume that at some point, they will deprecate webGL on iOS Safari.

[vbezhenar]

You are thinking about desktop AAA games. There're mobile games too and Apple produces very performant mobile devices.

[coldcode]

Why is Vulcan so magical that everyone in this thread thinks it is the only choice?

[eddieh]

Your question seems rhetorical, but here are my thoughts anyway...

This is the new normal, coinciding with the death of expertise.

The WebKit developers clearly are not working in a vacuum, if one bothers to read the blog post:

> Our proposal has been received positively by our colleagues at other browser engines, GPU vendors, and framework developers.

Not to mention that the WebKit developers are pretty much the forefathers of all modern web tech. So the WebKit developers and their colleagues are the experts. And the expert consensus is the successor to WebGL will be something new, something that can be implemented in DirectX 12+, Metal, and Vulkan.

But all the non-experts have heard of Vulkan, and are armed with the simplistic notion that Vulkan is the "next generation of OpenGL". They erroneously conclude that WebGL's successor must also be a Vulkan based solution.

The non-experts will justify this belief with all manner of ridiculous conspiracy-esque conclusions to reinforce their bias. Like "Apple is trying to force the standard", "Apple wasted their time developing Metal", "Apple is a closed-source walled garden", "Apple is expensive". All of which is is essentially the tech version of "libtard" based arguments.

RIP expertise.

[zamalek]

> WebKit developers are pretty much the forefathers of all modern web tech.

IE4 was the forefather of modern web tech[1].

> They erroneously conclude that WebGL's successor must also be a Vulkan based solution. [...] All of which is is essentially the tech version of "libtard" based arguments.

No, people are sick of working against 3 different APIs. One of which is a standard. It's Microsoft doing their own thing with IE all over again. A safe subset of Vulkan would be familiar and would have existing documentation. All designed by GPU experts.

[1]: https://en.m.wikipedia.org/wiki/Dynamic_HTML

[eddieh]

Except, as I quoted, the GPU experts and the other browser vendors are onboard with this. This isn't Apple going at it alone like MS did. You're reenforcing my point. Thank you for that.

[pjmlp]

Except for game consoles that HN keeps forgetting.

[om2]

I appreciate this comment.

We did indeed discuss this widely. No one thought that an API which only works on top of Vulkan was right, everyone in the relevant sector thinks it has to support the big three. Very few thought modeling the API closely on Vulkan was the best technical path.

I honestly don't understand why everyone here is so obsessed with Vulkan. Cloning it on the web won't make it more successful in the market. Building a Web API that is able to work on top of it (without mandating it) will likely help Vulkan in the end.

[AlphaSite]

I think you mistake is that you're conflating an angry, vocal (and frankly somewhat belligerent), minority with the opinions of the majority.

I suspect part of the issue is that since video games intersect so heavily with graphics APIs it will bring out the angry gamer crowds and with your being an Apple employee, it brings out the extreme anti Apple crowds. There will be people with legitimate claims, but I think they're being drowned out by the noise.

[jolux]

A voice of reason in a cacophony of wailing elephants.

[erikpukinskis]

It has three things going for it:

1) It's currently the fastest (unlike DirectX)

2) It's not controlled by an OS company (unlike DirectX and Metal)

3) It reflects recent developer and hardware concerns (unlike OpenGL)

[MBCook]

1) Compared to Metal or the low level thing MS has (don't they have one?)

2) Apple is proposing an open standard here, they're not making WebMetal

3) Why do you think Apple's proposal doesn't?

[dkersten]

1) The low level thing MS has is DirectX 12. I saw some benchmarks across multiple graphics cards that showed it was slower than Vulkan, but I can't seem to find it now... so its unclear to me if it is or isn't slower.

2) I think the people here would rather it be developed by an independent group like Khronos Group. For example, Apple created OpenCL as an open standard too and then abandoned it.

[MBCook]

On one, ok. I haven't followed DirectX too closely. I knew 12 was designed to match modern GPUs much closer but I didn't know if that was sort of 'medium' between DX 11 and Vulcan, there being something even lower from MS.

Thanks.

[dkersten]

Im sure it was probably just early drivers and its faster now (or at least getting faster).

[UnoriginalGuy]

And does it make security assurances making it suitable to expose to the web?

I know a bit about DirectX and OpenGL, and I wouldn't expose a direct interface to either of them on the web. Does Vulcan make security and isolation assurances? If not then it is useless.

[erikpukinskis]

Obviously there has to be a ground up rethink with security in mind. The standard won't be the same API, just like WebGL isn't the same as OpenGL. It's just, where it's possible to, you use the same API. The point is why not start with a starting point you can use on potentially every platform?

There's no way Apple would ever allow Metal proper to be ported to PlayStation or Windows, so you're limiting yourself to at best two platform coverage targeting this new standard. Vulcan will, hopefully, work on every platform. At least subsets of it, with shims. No way Metal ever gets there.

[vetinari]

Vulkan has validation layers - that are transparent to both app using the API on one side and to the driver on the other end.

[hornetblack]

The WebGPU code there looks a lot like vulkan. Just no big struct's or vk prefixes.

[tyoverby]

Apples handling of Vulcan / Metal should be a colossal embarrassment.

[philipp-spiess]

I doubt it's up to the webkit team to make this decision. Anyway, Apple adopting would make things easier

[microcolonel]

I've submitted this as the first GitHub issue regarding the charter.

https://github.com/gpuweb/admin/issues/1

[paulddraper]

To be fair, they are proposing a JS API, not a native one.

Though I do agree.

[dkonofalski]

Pardon my ignorance, but what do you mean by "not supporting Vulkan on their platforms"? I thought Vulkan was an API that software developers used for graphics... Isn't that a part of OpenGL? Is Apple actively blocking something or have they just left something out?

[fnord123]

Vulkan is a new API distinct from OpenGL. It's lower level but has a nicer API in some respects. https://en.wikipedia.org/wiki/Vulkan_(API)

Apple decided to not support Vulkan as it had been developing a competing API called Metal at around the same time. I don't know why they don't also support Vulkan.

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

[dkonofalski]

But Microsoft isn't supporting Vulkan in Windows either, so why is there only a fuss about Apple's support for it? Both companies have competing API's (Direct X and Metal), but Apple is the only one getting flack for it. Why is that?

[detaro]

For Windows I install a graphics driver by the GPU maker and get Vulkan support (according to wikipedia that is the case for Nvidia, AMD and Intel), since Windows allows drivers to offer such APIs without any specific support by Microsoft. With a Mac all the drivers come via Apple, without support for it.

[fnord123]

Not just Mac. A big deal is ios' missing support.

[cwyers]

Two major reasons:

1) Windows allows the GPU manufacturers to ship their own Vulkan support; AMD, Nvidia and Intel all do this, which covers 99.99999999999999% of all Windows machines where this is an issue. It's not as good as native support, but it's good enough.

2) Windows has over 90% market share on desktop. macOS has far, far less. It's a lot easier to get people to support your API when you have that kind of market share. iOS doesn't have enough market share for devs to ignore Android.

[fnord123]

>which covers 99.99999999999999% of all Windows machines where this is an issue.

TIL Matrox only has <00.00000000000001% of the market. :(

[threeseed]

Apple allows GPU manufacturers to ship their own Vulkan support as well.

It's likely not worth the vendor's effort but still.

[jolux]

If they were, say, actively revoking the certs of people trying to do this then it would be a different question, but it seems like the answer is the same for why anything gaming-related works worse or doesn't work at all on macOS: most gamers use Windows.

[liuliu]

Saying it is around the same time is to ignore the history.

Metal is available since Jun 2014. Vulkan announced on 2015 and the initial release is on 2016.

[fnord123]

You're right. And Vulkan is based on Mantle which was already available in 2013 (in drivers; with api docs available in 2015 for some reason[1]). Why Kronos/Valve/etc didn't use Metal as a starting point, I don't know.

[1] http://www.anandtech.com/show/9095/amd-mantle-api-programmin...

[vetinari]

Metal in 2014 is a different animal than Metal in 2016.

In 2014, it assumed that the GPU has unified memory architecture, for example (i.e. the GPU can access a memory buffer that you have a pointer to). That's why it was introduced on iOS only.

[Fej]

I love how they mention Direct3D and Vulkan in the same breath as Metal.

[pjmlp]

You are forgetting Sony and Microsoft.