4 ms·

It supports SPIR-V everywhere I believe. I'm not sure if Apple is trying to sabotage this effort, I actually honestly believe that they just think they have a n

It supports SPIR-V everywhere I believe. I'm not sure if Apple is trying to sabotage this effort, I actually honestly believe that they just think they have a nice way of doing things and want to tell the world about it. I think they have made some very good choices in WebGPU as well as WSL.

shmerl 7y ago
So WebGPU with SPIR-V will work in Apple's browsers, or you mean they should be ignored as crippled for WebGPU support?
- adamnemecek 7y ago
  The question of browsers is secondary. WebGPU goes way beyond the web. There are WebGPU implementations that you can use say for desktop games. It's a standard say for shaders and GPGPU programming. WebGPU supersedes all of CUDA, Vulkan, DirectX, OpenGL, Metal, OpenCL, WebGL. Maybe not all, but most of it. For me, the browser is a nice to have, WebGPU is a good standard regardless.
  - shmerl 7y ago
    Why would you use WebGPU for desktop games vs Vulkan directly, or a wrapper like gfx-rs? It's a more comfortable level of abstraction? I don't see WebGPU superseding Vulkan really.
    - pcwalton 7y ago
      wgpu/WebGPU is way less verbose. I don't want to write gfx-rs or Vulkan directly when experimenting with new techniques, unless I absolutely need maximum performance when testing. Only when I want to deploy something to production will I write in those low-level APIs.
      - adamnemecek 7y ago
        Do you think there will be much to gain from using Vulkan as opposed to WebGPU?
        pcwalton 7y ago
        Probably highly workload dependent and impossible to answer in a general way.
      - shmerl 7y ago
        That sounds reasonable. So you see WebGPU becoming the good general purpose higher level API built on top of good foundation (like Vulkan) that Khronos mentioned was missing in the Vulkan effort?
        adamnemecek 7y ago
        I definitely do. Like you can get to 90% perf using a cross-platform API. And to fine tune, you can probably just contribute some perf improvements to the implementation instead of rewriting it.
        Jasper_ 7y ago
        The buffer mapping strategy is still a big perf pitfall, but it could be solved with an extension.
        pcwalton 7y ago
        I certainly hope so!
        shmerl 7y ago
        Is it feasible to implement it for GNM / PlayStation, for instance through adding that target for gfx-rs? I've heard for example Godot engine can't even target it, due to it being very hostile towards anything open (requiring NDA for any kind of integration).
    - adamnemecek 7y ago
      It's a simpler API. Vulkan takes maybe 3x as many lines of code to express the same thing. Also if you want to run on macOS or Windows, you will use the native platforms. You can also target the web from the same codebase.
      - shmerl 7y ago
        gfx-rs does that, or you can use still Vulkan and through the same gfx-rs compat or MoltenVK target MacOS too. The only outlier is probably OrbisOS with its obscenely locked and NDA'ed GNM.
        adamnemecek 7y ago
        gfx-rs is not an open standard. gfx-rs is a little too hairy, so is rendy.
  - Jasper_ 7y ago
    WebGPU does not supercede Vulkan, Metal, or DirectX, and especially not OpenCL/CUDA. Please at least try using CUDA before claiming WebGPU even approaches anything near its functionality. WebGPU has tradeoffs and issues like anything else. AAA game engines, like the ones I work on, are still going to continue to have to support console platforms without WebGPU support, and will still have their own platform interfaces around stuff like that. Don't get me wrong, WebGPU is a very nicely designed API, but it is still lowest-common-denominator, and is about 2 years behind schedule.
- giornogiovanna 7y ago
  > So WebGPU with SPIR-V will work in Apple's browsers Yes, I think the idea is to embed a SPIRV-to-Metal compiler inside the browser. At least, that's what it looks like https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu is doing right now.
  - shmerl 7y ago
    So Apple agreed after all? They were resisting it in the past.
    - giornogiovanna 7y ago
      Never mind, I have no idea what Apple is doing. It looks like they're inventing yet another shading language. https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/ https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/
      - shmerl 7y ago
        That's what I thought. They still want to sabotage SPIR-V usage in the browser.
        pjmlp 7y ago
        Yeah, that is why the only working WebGPU implementation for Chrome, from Google, only works on the Mac and Windows platforms, using Metal and DirectX, your favourite APIs.
        shmerl 7y ago
        In Chrome may be, but that's not Apple's browser. And on iOS that won't work already, due to Apple's anti-competitive ban on browser engines that aren't theirs. And if anything - those are your favorite APIs. You always flame (like a shill) about how lock-in is good for developers.
        7y ago

shmerl 7y ago

So WebGPU with SPIR-V will work in Apple's browsers, or you mean they should be ignored as crippled for WebGPU support?

adamnemecek 7y ago
The question of browsers is secondary. WebGPU goes way beyond the web. There are WebGPU implementations that you can use say for desktop games. It's a standard say for shaders and GPGPU programming. WebGPU supersedes all of CUDA, Vulkan, DirectX, OpenGL, Metal, OpenCL, WebGL. Maybe not all, but most of it. For me, the browser is a nice to have, WebGPU is a good standard regardless.
- shmerl 7y ago
  Why would you use WebGPU for desktop games vs Vulkan directly, or a wrapper like gfx-rs? It's a more comfortable level of abstraction? I don't see WebGPU superseding Vulkan really.
  - pcwalton 7y ago
    wgpu/WebGPU is way less verbose. I don't want to write gfx-rs or Vulkan directly when experimenting with new techniques, unless I absolutely need maximum performance when testing. Only when I want to deploy something to production will I write in those low-level APIs.
    - adamnemecek 7y ago
      Do you think there will be much to gain from using Vulkan as opposed to WebGPU?
      - pcwalton 7y ago
        Probably highly workload dependent and impossible to answer in a general way.
    - shmerl 7y ago
      That sounds reasonable. So you see WebGPU becoming the good general purpose higher level API built on top of good foundation (like Vulkan) that Khronos mentioned was missing in the Vulkan effort?
      - adamnemecek 7y ago
        I definitely do. Like you can get to 90% perf using a cross-platform API. And to fine tune, you can probably just contribute some perf improvements to the implementation instead of rewriting it.
        Jasper_ 7y ago
        The buffer mapping strategy is still a big perf pitfall, but it could be solved with an extension.
      - pcwalton 7y ago
        I certainly hope so!
        shmerl 7y ago
        Is it feasible to implement it for GNM / PlayStation, for instance through adding that target for gfx-rs? I've heard for example Godot engine can't even target it, due to it being very hostile towards anything open (requiring NDA for any kind of integration).
  - adamnemecek 7y ago
    It's a simpler API. Vulkan takes maybe 3x as many lines of code to express the same thing. Also if you want to run on macOS or Windows, you will use the native platforms. You can also target the web from the same codebase.
    - shmerl 7y ago
      gfx-rs does that, or you can use still Vulkan and through the same gfx-rs compat or MoltenVK target MacOS too. The only outlier is probably OrbisOS with its obscenely locked and NDA'ed GNM.
      - adamnemecek 7y ago
        gfx-rs is not an open standard. gfx-rs is a little too hairy, so is rendy.
- Jasper_ 7y ago
  WebGPU does not supercede Vulkan, Metal, or DirectX, and especially not OpenCL/CUDA. Please at least try using CUDA before claiming WebGPU even approaches anything near its functionality. WebGPU has tradeoffs and issues like anything else. AAA game engines, like the ones I work on, are still going to continue to have to support console platforms without WebGPU support, and will still have their own platform interfaces around stuff like that. Don't get me wrong, WebGPU is a very nicely designed API, but it is still lowest-common-denominator, and is about 2 years behind schedule.
giornogiovanna 7y ago
> So WebGPU with SPIR-V will work in Apple's browsers Yes, I think the idea is to embed a SPIRV-to-Metal compiler inside the browser. At least, that's what it looks like https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu is doing right now.
- shmerl 7y ago
  So Apple agreed after all? They were resisting it in the past.
  - giornogiovanna 7y ago
    Never mind, I have no idea what Apple is doing. It looks like they're inventing yet another shading language. https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/ https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/
    - shmerl 7y ago
      That's what I thought. They still want to sabotage SPIR-V usage in the browser.
      - pjmlp 7y ago
        Yeah, that is why the only working WebGPU implementation for Chrome, from Google, only works on the Mac and Windows platforms, using Metal and DirectX, your favourite APIs.
        shmerl 7y ago
        In Chrome may be, but that's not Apple's browser. And on iOS that won't work already, due to Apple's anti-competitive ban on browser engines that aren't theirs. And if anything - those are your favorite APIs. You always flame (like a shill) about how lock-in is good for developers.
        7y ago