[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?

[om2]

Do you have any evidence for your claim that Vulkan is best? Metal and D3D 12 are also low-level APIs designed for performance. I've seen no evidence that Vulkan is better on platforms where there are drivers for two different APIs.

[Rusky]

There's nothing subjective about it. Take a look at the APIs, they operate at the same level and are designed around the same principles.

As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.

[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.

[om2]

We did evaluate the option of using Vulkan. So have others. It's not even necessarily off the table, we just don't think it is the best design approach.

If you are very interested in the details of API design choices, then I'd suggest joining the Community Group. Anyone can join!

[pjmlp]

Which is a good example why I don't have any issues with native code on OpenGL ES 3.x mobiles, while Chrome with WebGL is just choppy and dropping frames left and right.

[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.

[Rusky]

Validation layers were created so drivers could remove checks to improve performance. And regardless, properly handling adversarial input is much more involved than just a validation layer.

[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?

[lapfelix]

> Are apps compatible between platforms

That would be an awful experience for the consumers, UI/UX-wise.

[MBCook]

Consumers don't appear to be bothered by any of those missing freedoms.

[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.

[xenadu02]

Yes, I do. I'm also slightly familiar with OpenGL and Metal.

I think Metal has a better API. You are free to disagree of course.

[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.

[mixedCase]

>In the case of web standards, the null hypothesis is "no new API"

Thanks to Apple's bone-headed decision to not support Vulkan, this is what it has come down for me when it comes to graphical APIs. For me it's either "no new graphical APIs, keep being forced to use OpenGL" or "drop macOS/iOS support".

[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.

[om2]

Serious question, have you ever written any nontrivial code using Vulkan?

Everyone I know who's ever coded using Vulkan has found it unpleasant, and even Khronos is considering a higher level API (more along the lines of Metal) because Vulkan is just too hard to use.

[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.

[corysama]

To play devil's advocate: Isn't a big focus of web tech the goal of supporting multiple backends for everything? If a new platform wants to support WebGPU but not Vulkan (ex: XBone or PS4) it should be not just theoretically possible, but actively supported by the design of the Web spec.

[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).

[kitsunesoba]

If you're using a newer Nvidia card, you can download and install much more up to date Mac drivers direct from Nvidia's site. Yes, Apple bundles their own drivers but there's nothing stopping hardware vendors from shipping their own Mac drivers.

[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.

[jolux]

macOS is not popular among gamers? I don't understand what the problem is.

[threeseed]

No. Provide a source that Apple actively prevents it.

Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.

[MikusR]

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

[alwillis]

Latest results of the so-called dead platform--"iPhone, Services, Mac and Apple Watch Set All-Time Records"

http://www.apple.com/newsroom/2017/01/apple-reports-record-f...

[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?

[shmerl]

Lack of known good reasons, and their major infamy in perpetuating lock-in in general. They have only themselves to blame for being seen in negative light in this topic by default.

[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.

[shmerl]

It's more like "let's mess everyone else, because we can".

[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.

[ioquatix]

Every time I install a game from Steam, it almost always re-installs the DX runtime for that specific game. Is there a reason for that?

[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.

[om2]

It's likely there will be a need for a C++-level meta-API that can work on top of Vulkan, D3D and Metal. There's already been discussion of making such a thing. It would be nice if that could be exposed to WebAssembly via Emscripten.

[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.

[MrScruff]

The proposal in this case appears to be coming from the safari group rather than the metal one.

Even if that weren't the case, for a standard to be a success then pragmatism is more useful than idealism. Telling the maintainers of most of the worlds desktops to fall in line isn't really practical.

[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.

[guardiangod]

Someone else mentioned that they don't care about Nvidia and AMD both advocating for Vulkan because I'm personally not interested in the big desktop PCs

https://en.wikipedia.org/wiki/Vulkan_(API)#Compatibility

In addition to Nvidia and AMD, Intel, Imagination Technologies, Qualcomm (!!!), and ARM support Vulkan. Hardware wise, there is absolutely no problem whatsoever.

[acqq]

> by all vendors

NVIDIA and ATI are hardly "all" vendors I care about. I'm personally not interested in the big desktop PCs. YMMV of course. But I'm personally very against "winner takes it all" and I'd really like some more universal web API, especially one that consumes less power on the iOS devices.

Edit: the answer to the question below by sydd: I'm honestly and pragmatically interested in iOS and Apple devices, not Microsoft, and not the Google-controlled ones. All these comments are about Apple's proposal for a standard for Web. I'm with the ones having the smaller market share here. I'm still sad Opera Presto is no more. I consider such "smaller" players extremely important for the web.

[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.

[pjmlp]

Not on UWP applications, which are the future.

[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.

[MBCook]

Should they have invented a different place holder (and all the work that would require) just to throw it away and be all data they weren't using the shader language that Vulcan uses?

The post was VERY clear that that was temporary while working on the other basics and a real decision would be made later.

[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.

[Baeocystin]

FWIW, I agree with you. The most recent macbook 'pro' release has caused a majority of the devs I know say 'screw this' and trade their macbooks in for surfaces. Not exaggerating. Apple should be concerned.

[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.

[om2]

Why don't you ask Microsoft what they think about this proposal instead of speculating?

[MrScruff]

Shipping WebGL is not the same as shipping OpenGL support, which they don't do. WebGL on Windows browsers is built on DirectX. Apple ship a WebGL enabled browser.

[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.

[Strom]

DirectX 12 is only available on Windows 10, so that's the case regardless of drivers.

[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...

[johnsmith21006]

It has the Linux kernel you just bring the GNU or whatever you need. But Google now supports containers on ChromeOS so if access you can just run in a container and the use Android X Windows server on same box.

If Google would gives this away have my perfect development solution. I can play my Android games on my 2 in 1 and then use full Linux when in laptop mode. But I can also debug my containers on my laptop as native.

But when needed I have sold browser and other core things can never be touched. Basically give me a iPad and a Chromebook and a full Linux development machine. Well no kernel dev on Linux but most things, native, shared read, etc.

But I want an extra SSD that is separate from the kernel SSD. I think this can be done and even keep read share from boot dev and something running as a container.

[algo_cheese]

Correct, Android is not GNU/Linux, I responded too fast. As the parent comment spoke about DirectX support, I should have phrased it 'Android is also in the camp of "Doesn't support DirectX" and counts for a large number of devices.'

[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.

[saurik]

> https://software.intel.com/en-us/blogs/2016/03/14/new-intel-...

"DATE: March 11, 2016" "-NEW- Intel® Vulkan BETA 15.40.20.4404 Graphics Driver for Windows® 7/8.1/10 [15.40]"

> https://software.intel.com/en-us/blogs/2016/06/29/new-intel-...

"DATE: June 24 2016" "-NEW- Intel® Graphics Test Driver for Windows® 10 and Windows 7/8.1 [15.40.4473]"

https://software.intel.com/en-us/blogs/2016/06/23/intel-open...

"In his blog published on February 16, 2016, Imad Sousou shared that Intel was selected as one of the leading graphics platform suppliers with Vulkan* 1.0 drivers certified by the Khronos Group Consortium."

https://www.youtube.com/watch?v=bsOTVpepS44

"We are demoing Intel’s implementation of the API available on the latest hardware from Intel on 3 major operating systems: Windows, Linux and Android." Intel Engineer: "This really shows the industry is moving towards Vulkan."

https://www.khronos.org/conformance/adopters/conformant-prod...

Intel sure seems to have been making sure all of their chips are now Vulkan capable. All I can find for "they don't plan to" are what seems like rumors on one forum that are spawned by the current drivers being "unsupported" (but given that they are in beta, that makes sense to me: the storyline here is that they were provided for Vulkan developers to start testing their products and likely testing this driver). It really seems like Intel is at worst being "a little slow" to push Vulkan, but they are definitely not unsupportive.

[ioquatix]

According to https://software.intel.com/en-us/forums/developing-games-and... Intel DOES plan on releasing official production quality drivers at some point.

[monocasa]

> There are other companies too.

In addition to what people have said about Intel, Qualcomm, ARM, and IMG are all behind Vulkan. Who else is making GPUs these days?

[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.

[mrpippy]

Good find, it's a shame that the only info is buried in forums and there's no timeline or official statements.

[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).