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

[Zandikar]

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

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

[ioquatix]

Well, I guess you know all this but you've asked me to elaborate. So, in terms of compatibility you have:

DX12: Windows only. Metal: macOS/iOS only. Vulkan: cross-platform and cross-vendor. Windows 7/8/10, Android, Linux, MoltenVK supports iOS/macOS with a wrapper. That's a big win for Vulkan IMHO. Valve also agrees with this assertion.

In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. w.r.t. Vulkan vs DX, from what I've seen it's pretty close, with Vulkan usually coming out ahead by a few performance points but of course it depends a lot on the implementation when it's at that level. Vulkan has been shown to be systematically better than OpenGL.

[MrScruff]

It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. The discussion is not about what platform will run VR the best.

In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.

[ioquatix]

> It makes no sense to judge the quality of an API by the power of the available hardware it might be running on.

I didn't make any such judgement or even mention VR a single time!

But, looking at the points you've raised, I can say with confidence that Vulkan has been designed, taking into considering these issues.

Vulkan has been carefully engineered from the ground up not to alienate tile-based renderer hardware. So, it's just as suitable for mobile GPUs as desktop GPUs. https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-ma...

As such, it's already supported by many mobile GPU hardware vendors.

> In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.

The GPU in the iPhone 7 uses a custom version of the PowerVR GT7600 GPU. While this is purely speculation, PowerVR does support Vulkan in their other offerings, so it's not that much of a stretch to assume that the hardware is at least capable of it.

NVidia, AMD and Intel power all of Apple's desktop graphics, in addition, they collectively power almost all of Windows and Linux setups too (excepting other mobile and SFF computers)

[Angostura]

You did make such a judgement- you wrote:

> In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel.

[mickronome]

Obviously you can interpret the parents statement in more than one way. My interpretation was as a rather pragmatic statement that the probability that Metal is a high performance design (and implementation) is lowered by the fact that it to date only has targeted lower performance hardware, and thus there could be several undiscovered bottlenecks present. It is generally the case with any code that high performance on less powerful hardware not always imply high performance on more powerful hardware, especially when there are high levels of parallelism and multiple optimised fast paths to choose from.

[ioquatix]

I said:

> In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel.

The response was:

> It makes no sense to judge the quality of an API by the power of the available hardware it might be running on.

You are right, that my statement is not very clear.

The key point here is that I'm not judging the quality of an API by the power of the available hardware, but the quality of APIs relative to how much overhead they add, and that's quite a different proposition.

Given my intimate frustration with the state of Mac hardware and GPUs, I brushed off macOS as being somewhat ancient w.r.t. modern hardware and benchmarks. You can't go out and buy a Mac with a GTX 1080 for example. In fact, even the best Mac hardware you can buy is ridiculously outclassed by PCs costing significantly less.

However, back to the specific point of interest:

The overhead of APIs can be measured if you run the same benchmark, on the same hardware, with the different API. On Windows, it's possible to compare, say, DX9, DX11, DX12, OpenGL and Vulkan within the same benchmark. It's not possible to test Metal this way.

Specifically though, Vulkan is a C based API which is essentially as fast as it gets, in terms of actual function calls and so on. In comparison, Metal uses Objective-C. If you are familiar with Objective-C, you'll know that it doesn't have the fastest message dispatch (quasi-function call).

Basically, it would be really interesting to compare them, holding all other things equal. But, doing this with off the shelf GPUs simply isn't possible AFAIK. macOS hardware is simply too far behind. You might be able to jury-rig something using an external GPU, but it's still not a good comparison. My past experience of the graphics stack in macOS tells me it's unlikely to be great.

[AlphaSite]

You need to provide some evidence that function dispatch is a limiting factor for Metal, if you're going to argue that it is a limiting factor.

Also you seem to be under the impression that because a machine is expensive it is destined for gaming.

[foobiekr]

It does, though.

Many times bottlenecks and missteps are not really visible until you can see how your decisions and assumptions encounter reality especially when every other chokepoiht has been removed.

Unless they did their development on Windows or on hardware that has never shipped, Apple isn't really in the position to have evaluated how well Metal works in reality.

I would add that the awkwardness of some "good" API designs is often not revealed until much later (and this is doubly true in the graphics space where there is ample evidence of API choices revealing themselves to be stuck with what turned out to be bad choices some times later).