3 ms·

From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all th

From an operational standpoint, however, WebGPU is a much better fit for Vulkan/Metal/DirectX than OpenGL is, since it (mostly) exposes abstractions that all three actually support efficiently (and more generally, was designed with modern GPUs in mind, so unless GPU design fundamentally changes it's unlikely that it will require doubling or tripling the API surface to keep up, unlike OpenGL). That represents a pretty significant improvement over OpenGL (particularly the older versions of OpenGL that you have to use if you actually care about portability), and also over solutions like MoltenVK (it's hard to efficiently implement a lower-level API on top of a higher-level one). This doesn't invalidate your point, I just think when you say "yet another cross-platform abstraction" you're implying that this is an xkcd "now there are 15 standards" situation, when in reality the competition is basically just ancient versions of OpenGL. And OpenGL is effectively deprecated--Khronos has no plans to release any more major updates. Unfortunately, without the browser usecase bringing many of the stakeholders on board, there is not a lot of money in this kind of work, which is why there aren't any serious competitors.

dmitriid 4y ago
It is xkcd though. WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan. They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569 https://github.com/gpuweb/gpuweb/issues/569
- Jweb_Guru 4y ago
  Shader language squabbles and throwaway accusations aside (for my own purposes I don't really care about WGSL, since there are transpilers back and forth to other shader languages for native use, but loop/continue is not exactly an example of some crazy unprecedented language construct), Metal isn't a cross-platform standard of any sort. It pretty much explicitly exists so Apple can control it (it would be nice if it was Metal-on-Vulkan instead, but I think that ship has sailed). I don't really see how the existence of Metal is a relevant example of what I'm talking about: a portable modern graphics abstraction that is efficient on modern hardware. It's just not true that there are a bunch of those out there, when you're talking about production-quality stuff there's basically just WebGPU. Even if your argument was that Vulkan was supposed to be that standard (which it isn't in practice), Vulkan is pretty much impossible to use safely without building a higher-level abstraction on top. It was desperately in need of a standard higher level API that programmers with limited resources (i.e. not Epic, browser vendors, etc.), or programmers who need to run in sandboxed environments (mostly browsers) can reasonably target, and I think WebGPU serves that purpose nicely. Exposing Vulkan (or DirectX 12, or any similarly low-level API) directly to browsers would have been pretty much a non-starter from a memory safety perspective, WebGPU does not exist solely because Apple didn't like Vulkan.
  - dmitriid 4y ago
    You're completely missing the point, aren't you? You argued that this isn't the xkcd situation.... and proceeded to literally describe "Situation: There are now 15 standards". But sure, you don't care because "transpilers exist". I wish people cared. > WebGPU does not exist solely because Apple didn't like Vulkan. Apple released first version Metal before Vulkan was even a thing on anyone's radar: - Metal release date: June 2014. - The Khronos Group began a project to create a next generation graphics API in July 2014 But sure, "Apple doesn't like Vulkan". And the whole "WebGPU does not exist solely because Apple didn't like Vulkan" is a sentence that has literally zero sense. Pre-WebGPU prototype was literaly proposed as a joint effort by Apple and Mozilla, and it was Apple's idea to create a working group to work on the new graphics API.
    - Jweb_Guru 4y ago
      I don't think this is likely to be a productive conversation anymore, sorry.

dmitriid 4y ago

It is xkcd though. WebGPU as proposed by Apple was basically Metal. Naturally other vendors weren't keen on implementing this, so they arrived at a compromise which is a bastard child of Metal and Vulkan. They couldn't even adopt an existing shader language and invented a new one. That goes as far as invent new and unprecedented language constructs https://github.com/gpuweb/gpuweb/issues/569 https://github.com/gpuweb/gpuweb/issues/569

Jweb_Guru 4y ago
Shader language squabbles and throwaway accusations aside (for my own purposes I don't really care about WGSL, since there are transpilers back and forth to other shader languages for native use, but loop/continue is not exactly an example of some crazy unprecedented language construct), Metal isn't a cross-platform standard of any sort. It pretty much explicitly exists so Apple can control it (it would be nice if it was Metal-on-Vulkan instead, but I think that ship has sailed). I don't really see how the existence of Metal is a relevant example of what I'm talking about: a portable modern graphics abstraction that is efficient on modern hardware. It's just not true that there are a bunch of those out there, when you're talking about production-quality stuff there's basically just WebGPU. Even if your argument was that Vulkan was supposed to be that standard (which it isn't in practice), Vulkan is pretty much impossible to use safely without building a higher-level abstraction on top. It was desperately in need of a standard higher level API that programmers with limited resources (i.e. not Epic, browser vendors, etc.), or programmers who need to run in sandboxed environments (mostly browsers) can reasonably target, and I think WebGPU serves that purpose nicely. Exposing Vulkan (or DirectX 12, or any similarly low-level API) directly to browsers would have been pretty much a non-starter from a memory safety perspective, WebGPU does not exist solely because Apple didn't like Vulkan.
- dmitriid 4y ago
  You're completely missing the point, aren't you? You argued that this isn't the xkcd situation.... and proceeded to literally describe "Situation: There are now 15 standards". But sure, you don't care because "transpilers exist". I wish people cared. > WebGPU does not exist solely because Apple didn't like Vulkan. Apple released first version Metal before Vulkan was even a thing on anyone's radar: - Metal release date: June 2014. - The Khronos Group began a project to create a next generation graphics API in July 2014 But sure, "Apple doesn't like Vulkan". And the whole "WebGPU does not exist solely because Apple didn't like Vulkan" is a sentence that has literally zero sense. Pre-WebGPU prototype was literaly proposed as a joint effort by Apple and Mozilla, and it was Apple's idea to create a working group to work on the new graphics API.
  - Jweb_Guru 4y ago
    I don't think this is likely to be a productive conversation anymore, sorry.