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

[DLudwig]

But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?

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

[mrpippy]

Intel has only released beta/test drivers for Windows, and this was their statement as of 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.

Intel GPUs power at least 50% of Windows PCs, and I'd guess the number is closer to 70%. Unless this situation changes, Vulkan is not the single cross-platform answer.

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

[sydd]

Then which vendors do you care about from the Microsoft ecosystem (which this thread is about)? Vulkan is supported by Nvidia, AMD and Intel, I think this covers >99% of the Windows landscape. Windows phone? or Xbox? Hololens?

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

[douche]

They've been saying that for a few years, but nobody seems to be buying it. The store is still a wasteland of mobile-style shovelware, and none of the real Windows applications have made the jump, far as I have seen.

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

[shmerl]

This shows, that this idea wasn't thought through enough. And coming from Apple, it raises a concern naturally. These things should have solid foundations from the start.

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