by "network", what they really mean is interprocess communication, right?
Re:WebGPU and WSL in Safari
by The_rationalist on Thursday September 12, 2019 @05:38PM
(#20956758)
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
Re:WebGPU and WSL in Safari
by The_rationalist on Friday September 13, 2019 @03:59AM
(#20960101)
The intersection of hardware features is greater than the intersection of Vulkan, dx12 and metal features.
Moreover, hardware features should be queryable at runtime
With extensions count growing every week.
Good luck making sense of Vulkan in 10 years time.
Re:WebGPU and WSL in Safari
by The_rationalist on Friday September 13, 2019 @07:36AM
(#20961146)
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.
Except that OpenGL and WegGL already proven that there is what the paper says, what the driver states and what the GPGPU actually does.
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.
Re:WebGPU and WSL in Safari
by The_rationalist on Friday September 13, 2019 @04:00AM
(#20960107)
How can you make such a massive claim?
Did you read all of Vulkan extensions?
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.
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.