The bit about network transparency is the most interesting one IME (which, in this case, assumes the "network" is essentially a collection of intercommunicating system processes, not nodes), as well as the bits about how Vulkan exposes too much of the vendor model to the programmer, which also isn't their goal. But it's a very sensible goal for Vulkan itself on the desktop.
If anything, the work on the gfx-rs means that WebGPU might actually end up as a more low-ish-level "portable" graphics API than Vulkan itself if you want to target every major platform + the web. In particular, gfx-hal is a non-Vulkan abstraction layer on top of D3D12/Metal/Vulkan, and webgpu-native/wgpu-rs provide WebGPU APIs for desktop platforms (in C/Rust) based on gfx-hal. Eventually you should be able to target WebGPU+WebAssembly too. I just ran a wgpu-rs demo yesterday on my mac with Metal and on my Windows desktop with DX12 with no changes! Pretty good stuff so far. And if you're a die hard Vulkan fan and don't care about WebGPU, then gfx-portability will let you program against Vulkan while building on gfx-hal, all the same, so you can still target Windows/Mac. (It would be interesting to ask how gfx-rs overcomes the problems outlined in the above design doc.)
The shading language will probably end up being the most contentious point in the end, but ultimately I think the overall tool quality/available for desktop is impressive, and WebGPU will probably end up as a good offering in the design space.
This is not about being a Vulkan fan.
Not even about portability.
The real issue is the one no one talk about.
Webgpu is the intersection of features from Vulkan, directX 12 and metal.
Which means that webGPU is a subset of Vulkan, metal and DX, by design it is less powerful than metal, less powerful than DX and less powerful than metal.
By being an intersection, by design they've created a sub-par, non evolutive api.
As a consequence, performance reachable on desktop, and expressivity of possible software and graphical features will be inferior on the web which is deeply sad
Nobody understanding and stating that is another sad thing.
WebGPU is for the Web. You're expected to be able to put up a webpage and have it run everywhere (as much as is possible). Vulkan is designed so you have to make paths for every differen type of hardware. That's a non-starter for the web
The intersection of hardware features is greater than the intersection of Vulkan, dx12 and metal features.
Moreover, hardware features should be queryable at runtime
That's why it's versioned..
Webgpu could start from Vulkan 1.1 or the latest Vulkan version could be bumped to Vulkan 1.2 for marking it's the one used for webgpu.
Turns out that the intersection is already a huge advance over WebGL, and that much of the stuff outside the intersection is of marginal value or even outright regrettable.
I have followed the WebGPU CG discussions about differences between the APIs and what features one has that the other doesn't. The initial goal of the API is to have a solid core, and not rely on extensions for important functionality. But it does have an extension facility so I'm sure some things will make it in as extensions over time.
Yes, thanks Apple. Vulkan is rather awful to use, compared to D3D12 and especially compared to Metal.
Metal, in my opinion, strikes the best balance between performance and low-level control.
With Vulkan the intention is that you have multiple codepaths for every vendor for good performance. This is way too much effort for an API that is already of little relevance.
I think that with AZDO-style extensions to OpenGL/WebGL you would've gotten 95% of the performance benefit without adapting a whole new rendering API (and shading language). Unfortunately, AMD could never get a proper OpenGL driver going so they pushed for Mantle which ultimately turned into Vulkan.
Metal also is quite different between mobile and desktop, so it's not solving this portability issue completely. It has the benefit of standardizing more of the limits/capabilities in the feature tables as a part of the "spec". This is much better than querying everything about the physical device at run/init time and making decisions from there.
Where Metal is really different, in a good way, is that it has progressive complexity. You can use the basic commands and get pretty far, allowing the driver to manage lifetimes for you and not caring about multi-threading too hard. But then there are ways to get more control, gradually, which you can opt into later. This is very different from Vulkan's all-or-nothing approach.
For the Web, it seems to me that having the same property would work best.
