6 ms·

Check out wgpu (https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs) the Rust implementation of the WebGPU standard. WebGPU is a nice API, Rust

Check out wgpu (https://github.com/gfx-rs/wgpu-rs https://github.com/gfx-rs/wgpu-rs) the Rust implementation of the WebGPU standard. WebGPU is a nice API, Rust is amazing too. It's the stack of the near future. You can use it on the desktop. WebGPU a fast API on top of the underlying platforms. And it supports spirv, fuck glsl or hlsl. There's also a dedicated wgpu channel on matrix if you want to join. https://matrix.to/#/%23wgpu:matrix.org https://matrix.to/#/%23wgpu:matrix.org

shmerl 7y ago
It would be good for it to support SPIR-V everywhere despite Apple's sabotage of the idea, but wouldn't you still need to use higher level language (HLSL/GLSL) to generate SPIR-V? Writing shaders in SPIR-V assembly directly would be pretty tedious.
- adamnemecek 7y ago
  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
    - 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
- pcwalton 7y ago
  I read the parent comment as against the idea of shipping HLSL/GLSL, not the languages themselves.
  - adamnemecek 7y ago
    Yeah, I want whatever->SPIR-V->platform language.
mrec 7y ago
Minor nitpick - wgpu is the implementation (written in Rust but exposing a C API), wgpu-rs is an idiomatic-Rust wrapper around that implementation. I did a bit of a doubletake the first time I read that, but ultimately I think not giving your own implementation language special treatment sends a good message for potential adopters.
- zozbot234 7y ago
  It's also needed because only C provides a standard ABI, so any linking of binary objects that are not being built by that exact same compiler release has to go through that lowest common denominator. Rust even provides 'bindgen' and 'cbindgen' utilities to make this pattern more workable.
  - mrec 7y ago
    Oh sure, my doubletake was at them going this route rather than the "obvious" one of having the Rust implementation expose a Rust API and then having a separate C-API wrapper around that.

shmerl 7y ago

It would be good for it to support SPIR-V everywhere despite Apple's sabotage of the idea, but wouldn't you still need to use higher level language (HLSL/GLSL) to generate SPIR-V? Writing shaders in SPIR-V assembly directly would be pretty tedious.

adamnemecek 7y ago
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
  - 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
pcwalton 7y ago
I read the parent comment as against the idea of shipping HLSL/GLSL, not the languages themselves.
- adamnemecek 7y ago
  Yeah, I want whatever->SPIR-V->platform language.

mrec 7y ago

Minor nitpick - wgpu is the implementation (written in Rust but exposing a C API), wgpu-rs is an idiomatic-Rust wrapper around that implementation. I did a bit of a doubletake the first time I read that, but ultimately I think not giving your own implementation language special treatment sends a good message for potential adopters.

zozbot234 7y ago
It's also needed because only C provides a standard ABI, so any linking of binary objects that are not being built by that exact same compiler release has to go through that lowest common denominator. Rust even provides 'bindgen' and 'cbindgen' utilities to make this pattern more workable.
- mrec 7y ago
  Oh sure, my doubletake was at them going this route rather than the "obvious" one of having the Rust implementation expose a Rust API and then having a separate C-API wrapper around that.