Hacker News new | ask | show | jobs
by Zandikar 3417 days ago
I think we've all gone a bit off the rails here.

Although you and those you've been discussing this with can't agree on which API is better, there's plenty of evidence that Vulcan, Metal and Dx are all quite good. Why then would we introduce yet another "standard" from scratch, as opposed to working to implement one of the existing ones better across platforms (if the desire is truly to build a universal gfx api)?
1 comments
om2 3417 days ago
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.

link
shmerl 3417 days ago
> 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?

link
simonh 3417 days ago
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.
link
om2 3417 days ago
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".

link
ioquatix 3417 days ago
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.

link
ioquatix 3417 days ago
When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.
link
shmerl 3417 days ago
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.
link
bobajeff 3417 days ago
This brings another question. Would it be better given the likely use cases for WebGPU to be designed as a WebAssembly only API?
link
om2 3417 days ago
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.

link
bobajeff 3417 days ago
Oh. I didn't know that.
link
staticautomatic 3416 days ago
Why is making a new standard inevitable?
link