5 ms·
It wasn't just Apple, even several Google engineers working on WebGPU agreed that simply mimicking Vulkan wasn't the right model. There are some notes here: htt
by aseipp 7y ago
It wasn't just Apple, even several Google engineers working on WebGPU agreed that simply mimicking Vulkan wasn't the right model. There are some notes here: https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGUWv_JrkpGizDN0bNq7wY/edit#heading=h.vty7esorrmjf https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU...
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.
- billconan 7y agoby "network", what they really mean is interprocess communication, right?
- The_rationalist 7y agoThis 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.
- om2 7y agoTurns 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.
- The_rationalist 7y agoHow can you make such a massive claim? Did you read all of Vulkan extensions?
- om2 7y agoI 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.
- greggman2 7y agoWebGPU 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
- pjmlp 7y agoWith extensions count growing every week. Good luck making sense of Vulkan in 10 years time.
- The_rationalist 7y agoThat'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.