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

[monocasa]

I mean, that's going to happen anyway.

The whole point of Vulkan/Metal/DX12 is that since GPUs have their own MMUs it's totally OK to seg fault your own process from the GPU side. You just crash your process, but you don't take down the system.

That line of thinking doesn't really translate well to a JS API.

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

[ioquatix]

Intel has (unofficially?) said they will deliver production quality Vulkan drivers for their iGPUs. https://software.intel.com/en-us/forums/developing-games-and...

[microcolonel]

Windows 8 and older power more than half of Windows PCs, so Direct3D 12 is no more widely deployed than Vulkan.

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

[kalleboo]

Intel does not support Vulkan. They had some beta drivers for devs to test on, but no further plans

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

[pjmlp]

Many of the Windows 10 applications like the file explorer and Edge are UWP.

Also the majority of all the new OS APIs are UWP only.

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

[MBCook]

> This shows, that this idea wasn't thought through enough.

Isn't this the way you're supposed to do open source? Post code early and often for comments?

It seems like a ridiculous requirement that to show a sketch of what they think a web API should look like for next generation 3-D graphics they should have to design an entire shader language that's different from the one they already have.

It's just a placeholder. They didn't even SHOW the language. They just referred to its name and said they were using that for expediency during the initial version of the document they were showing.

[givinguflac]

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