[om2]

Making a new standard is inevitable. That's not really a choice.

Even if the web platform directly replicated one of the existing APIs, you still have to explain how it binds to JavaScript, as well as memory and GPU resource management details. So bringing a modern graphics API to the web will inevitably create a new standard.

The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.

[shmerl]

> The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.

Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?

[simonh]

Tying the implementation to a single underlying API is just another kind of lock-in. You can be locked in to an open standard just as much as a proprietary one. Suppose this had been proposed 5 years ago and been tied deeply into OpenGL? In the world of today, that would pretty much make it a dead end. It's just not the job of a standard like this to pick and choose winners at a different level of abstraction.

[om2]

We did actually build a standard tied deeply OpenGL, it's called WebGL. And indeed, we foresee the need to move beyond it (though WebGL is still plenty good and not a dead end yet.)

Worth noting also that Khronos is considering a slightly higher-level API than Vulkan as their next iteration. So that's another reason it would be a shame to bind too tightly to Vulkan.

I also find it puzzling how designing to support multiple back ends is "lock-in" but binding tightly to only one underlying API is "open".

[ioquatix]

Platform "lock-in" and "openness" are not mutually exclusive.

Lock-in refers to how that platform affects your options for deployment.

Openness refers to how that platform is being developed.

A platform can be designed in an open way, but if it only works in one environment (e.g. browser) you might consider that to be "locked in". As in, you are "locked" into using a browser for deploying your application.

Vulkan is open, in the sense that it is an open standard. It's managed in a way that allows a wide variety of people/companies to contribute to it's design and implementation.

Vulkan as an API is an abstract model for how a GPU works. Everyone codes to that spec, and they can work on a wide variety of systems. So you are not locked in to a limited set of systems.

In fact, if you wanted to make your own Vulkan implementation you could, and there is a lot of documentation, conformance tests, etc to help with that.

Supporting multiple backends naturally requires an abstract API on top to handle the inconsistencies in the underlying systems. A new API naturally means that existing code would need to be refactored to work with it. If that API only serves the purpose of executing within a specific context, you might consider that to be "lock-in" for that platform.

[ioquatix]

When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.

[shmerl]

Indeed, the question was rhetorical, and more of a poke at using Metal shaders in the initial proposal, instead of going right away with open languages and representations.

[bobajeff]

This brings another question. Would it be better given the likely use cases for WebGPU to be designed as a WebAssembly only API?

[om2]

WebAssembly doesn't currently have a way to expose APIs to it directly. It only has an interface to call JavaScript.

Maybe that will change, but blocking on a major new WebAssembly feature did not seem wise.

[bobajeff]

Oh. I didn't know that.

[staticautomatic]

Why is making a new standard inevitable?