11 ms·

Learn WebGPU

243 points by ibobev 4y ago

wheelerof4te 4y ago
Great guide that introduces people to a overcomplicated, redundant feature-creep.
- KeplerBoy 4y ago
  GPUs are getting ridiculously powerful and having proper API to utilize them is important. People want to have powerful apps in their browser, so there's clearly a need to have access to compute shaders from JS and WASM.
  - wheelerof4te 4y ago
    "People want to have powerful apps in their browser" There is something rotten in that statement. No, you absolutely don't have to use such power in the browser. There is a reason we have a thing called an operating system.
    - skitter 4y ago
      With browsers being operating systems that do sandboxing by default. If I know I want to run an app, I prefer a native version, but browsers are superior for trying things out.
    - devmor 4y ago
      If every system has a web browser that handles WASM and program develop paradigms shift to primarily utilize it, then programs by default are cross-platform and memory sandboxed. Sounds a lot better than today.
      - horsawlarway 4y ago
        I mean - to be fair, you have this already today. It's just limited to html/js/css as the tooling. Which is actually a-ok for the vast majority of use-cases. Honestly, I really don't want companies to be making GUIs using WASM/WebGPU. Html/css/js solve that domain fairly well already, and the "canvas-only" wasm implementations I've seen so far are pretty damn monstrous. Outside of being a completely opaque box to me, the user, they're also usually not terribly performant, break all sorts of expected behavior, and have cross platform issues. I'm interested in seeing if webGPU enables more ML possibilities on the web, especially ML that's running client side and not over the wire. But really - that's about it. GUI tasks seem like a bad pick for this. They're literally several steps backwards from where we are right now, and they completely remove the ability to inspect the running application as the user. And that last point is a really, really big deal. Personally, I like a web that supports things like 3rd party integrations, ad-blockers, user-agent css styling, etc. I don't want a fucking canvas riddled with ads that I cannot interact with.
        danShumway 4y ago
        This is my one fear with GPU stuff. I'm using Canvas when I build games on the web, and that's about it. And even there I'm regularly trying to think "isn't there some way I could represent this application state as a tree?" There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. I want people to be able to build more powerful stuff on the web, but I don't want them to start looking at the DOM as if it's just some inconvenient quirk of the platform rather than a really seriously integral part of the web's success as a platform. Yes, it's often inconvenient to build fancy effects on top of the DOM, yes you have to worry about updates and performance -- because your entire application state is not supposed to be in the DOM 100% of the time; the DOM should be treated as a render target presenting the application state and controls that are relevant to the user right now. The DOM forces you to represent your current app's interface as a pure-text XML tree;that is the common denominator for all of your users no matter what device or features or settings they have enabled. Targeting that common denominator is good practice because in most (not all but most) cases if you can't sit down and write out your app's current interface as presented to the user on a sheet of paper by hand as an XML tree, probably something in your interface has gone wrong or gotten too complicated and you ought to be rethinking the UX anyway.
        beebeepka 4y ago
        But bypassing DOM is the main point when you have to draw and animate a lot of stuff quickly. I say let the browsers use these low level API for speeding up DOM and CSS. But also allow people to bypass this layer. Back in the day I migrated (more like recreated) a web RTS from DOM to canvas and getting rid of all that HTML and CSS was a massive relief. Deleted so much markup, styles and js all while improving performance massively.
        danShumway 4y ago
        I'm using WebGL for game development right now (and am somewhat looking forward to WebGPU) -- I'm not saying everything needs to be in the DOM. Just most things. It shouldn't really be the default for application frameworks to target Canvas (and multiple frameworks do treat it like the default rendering target). Like I said: > There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. An RTS may be an exception to that because for most RTS games you can't sit down and describe what's going on in the game in a clear way using a pure-text tree or interactive document. But "exception" is the important word there. Most web apps aren't games, most web apps shouldn't be laying out complicated 2D/3D graphical scenes.
      - timw4mail 4y ago
        Just makes the browser the level that has to be up to date, which determines what hardware is still usable. If Chromebooks are anything to go by, this will just end up making more hardware unusable for new software.
    - KeplerBoy 4y ago
      Telling people that the thing they want is stupid, won't stop them from wanting it.
      - wiz21c 4y ago
        Alas. Three times alas...
    - flohofwoe 4y ago
      The post is actually about using WebGPU as native library in native applications (outside the browser or Electron). (but apart from that there seems to be a growing schism between people who see the browser as a document viewer, and others who see it as an application platform, I'm definitely in the platform camp ;)
    - dragonelite 4y ago
      Yet they all though it to be worth the engineering time to deliver this utility. While i agree with you i know a lot of people that find interaction via a browser more natural than a desktop application. A bit like some emacs jokes go and say the operating system is just their bootstrapper for emacs.
    - notjustanymike 4y ago
      Heaven forbid a doctor be able to share a link of a 3D visualization for a procedure so patients have a better understanding of the decisions they have to make. That'd be way too convenient!
    - danShumway 4y ago
      I'd be more sympathetic to this statement if any of the modern operating systems had halfway decent sandboxing. Insert inevitable reference to "the Birth and Death of Javascript" but native platforms should be copying the web more in general. The DOM is just structured CLI output, with all of the advantages that CLIs have. Seriously, as a user nearly every native app on my machine ought to (in a better world) be rendering its interface to a structured text format that I can inspect and modify on the fly and pipe into other applications or dynamically restyle as I see fit. Because of that structure, most web-apps can be extended arbitrarily with user extensions. The sandboxing on the web is... okay it's not great, but it's better than what anybody else is doing. The delivery platform for apps is better specifically because the sandboxing is better, which allows me to try out apps quickly without giving them a lot of unnecessary access to my computer. People are building apps in the browser because browsers offer capabilities that native operating systems don't offer. The few platforms where browser dominance doesn't hold true (iOS, Android) largely maintain native dominance by severely limiting what web browsers can do. That's the wrong way to move forward; offer a native experience that's as good as the web and people won't need to build apps on the web. Even just good application sandboxing alone would be a good start, and yet whenever something like Flatpak tries to make progress in that direction, people are constantly complaining about it and explaining that sandboxing is the wrong way to approach app security. It's not really surprising then that people look at that discussion and take away from it that maybe the desktop isn't a good fit for their app. ---- My only critique of the webGPU direction is people bypassing the DOM, which... is usually the result of native developers and native frameworks trying to bring native development patterns to the web instead of rallying behind the idea of user-inspectable pure-text interfaces in the DOM. In that regard, and very specifically in that regard, I do kind of agree that the web is becoming too much like a native operating system. In the sense that it is repeating the same exact mistakes that native operating systems made. But in regards to people just generally building apps in browsers... good. Honestly, progressive web apps are a safer, more user-respecting way to deliver functionality than native OSes are.
      - shortrounddev 4y ago
        > if any of the modern operating systems had halfway decent sandboxing What qualifies as "halfway decent"? For servers, Linux seems to have a good set of utilities (taken advantage of by docker). Windows doesn't seem to have as good system calls (like chroot, for example), but UWP apps seem to be decent enough for a sandboxed app. What would be a good example of sandboxing for you? Personally I think that websites are the most popular way to distribute applications because it only requires a single link or URL to download the software and have it run immediately as required. No other cross-platform computing VM (JVM, CLR) can boast about that kind of ease of distribution. Additionally, HTML + CSS + JS have proven to be the most popular UI platforms. XAML just doesn't come close to the flexibility provided by these tools, and non-declarative UI is just out of the question for the majority of people designing websites in HTML, who are not software engineers
    - deleted 4y ago
      [deleted]
  - pjmlp 4y ago
    Some of us wouldn't consider design by committee APIs as proper.
    - deleted 4y ago
      [deleted]
supernikio2 4y ago
It's really interesting how the natural ecosystem for wgpu and wasm seems to be Rust, when C++ is also a prime candidate. Could this be the recency bias associated with Rust being the new kid in the block?
- flohofwoe 4y ago
  It's probably as simple as 'cargo vs cmake'. wgpu-native is a regular cargo package which is straightforward to integrate and build. Google's libdawn is a mix of cmake and Google depot tools, which makes the same process anything but trivial. I don't agree with your take on WASM though. Emscripten does a pretty good job of making developer's life easier. (there's also a real need for a medium-level cross-platform GPU API which abstracts over D3D12, Vulkan and Metal, and WebGPU seems to be the most robust option for this at the moment)
- pjmlp 4y ago
  The natural ecosystem is the browser. There is Dawn for C++, also shipped alongside node.
  - CyberDildonics 4y ago
    Yes I agree, the natural ecosystem is webasm in the browser now that for the first time in history everyone has a good fast and general jit vm they can use. I'm surprised something like webasm didn't happen sooner but at least it is here now.
    - pjmlp 4y ago
      WebGPU doesn't have anything to do with WASM. Anyone that wants to use it productively is also better off with BabylonJS, PlayCanvas, Threejs.
      - CyberDildonics 4y ago
        Yes I'm agreeing that the natural ecosystem of the browser is because of thing like webgpu and webasm now that it has been invented.
cormacrelf 4y ago
With reference to the section on how difficult it is to build wpgu-native and how you basically have to use a precompiled binary, there appears to be an easier way to integrate a Cargo library into a CMake project: https://github.com/corrosion-rs/corrosion https://github.com/corrosion-rs/corrosion
kypro 4y ago
As someone who's very recently been looking into using WebGPU on a project, why must it be so complicated to execute some simple instructions on a GPU? All of the code I was looking at seems to use (and require from the API) a lot of graphics terminology like "shaders", etc. Additionally it seemed to require a bizarre amount of boilerplate code to create compute "pipelines" and other things. Is there some reason that running code on a GPU must be so difficult? Why is there no API I can call like, `GPU.exec(() => 2 * 2);` Sorry for the dumb question. I'll definitely be taking a look through this guide later.
- Chabsff 4y ago
  TL;DR; It has to work blazingly fast on all kinds of GPUs, which are not nearly as homogeneous as you might expect. The complex setup is the "lowest common denominator" of that ecosystem. GPUs are stupendously good at ridiculously wide parallel processing, yet you still need to sequence these operations. Modern Graphics API setups like Vulkan and WebGPU are the currently best known way to write such systems. Shaders express the parallel algorithms, and the pipelines binds and synchronizes them together. It's just legitimately the best way, as far as we know, to get the most bang out of your buck for that hardware while remaining vendor-agnostic. Anyways, a higher-level abstraction can always be built on top that provides you with the UX you desire, and we will see a bunch of them for WebGPU soon enough.
- overthrow 4y ago
  WebGPU is a low-level interface close to the hardware. If you don't care about having control over those details, it's not the right API to use. You'd have better luck with either a high-level wrapper or something else like WebGL.
  - kypro 4y ago
    WebGL still requires shader code I believe, and also uses graphic-specific terminology. My understanding is that there is no high-level native API for compute-specific use-cases. You are currently forced to use an API intended for graphics and then create abstracts for compute yourself. I believe GPU.js exists to fill this void and facilitate simple GPU compute on the web without the need for all of the graphic-specific terminology and boiler plate code. But why a 3rd party library is needed for this makes little sense to me since a high-level native GPU (or hybrid) compute API seems like a great way to optimise many JS projects on the web today. I must be missing something though because this seems like such a no brainer that if it was possible it would already be a thing.
oytis 4y ago
This is the first WebGPU guide I've seen that shows how to make shaders do something useful, really appreciate that.
vrglvrglvrgl 4y ago
[dead]
seabass-labrax 4y ago
From https://eliemichel.github.io/LearnWebGPU/getting-started/hello-webgpu.html https://eliemichel.github.io/LearnWebGPU/getting-started/hel...: > Since wgpu-native is written in rust, we cannot easily build it from scratch so the distribution includes pre-compiled libraries Isn't this the wrong way round? Building from source seems to be the default for Rust programs, as they are typically statically linked.
- pjmlp 4y ago
  Being statically linked works just as well with binary libraries in compiled languages.
- steveklabnik 4y ago
  Given that this article seems to be coming from a “you’re writing C++” perspective, I read this as “you probably don’t have a rust compiler installed so it’s not as easy for you to build from source as a C++ library would be.”
  - seabass-labrax 4y ago
    Ah, that makes sense! The author is also using CMake, which I imagine doesn't have much integration with Cargo.
seabass-labrax 4y ago
From https://eliemichel.github.io/LearnWebGPU/_images/rhi.png https://eliemichel.github.io/LearnWebGPU/_images/rhi.png, it looks like on FOSS systems that Vulkan is the supported graphics library for interfacing with the GPU. This is in contrast with WebGL, which specifically targets OpenGL ES, without support for Vulkan or the various proprietary graphics libraries. Am I right in this evaluation?
- IvanK_net 4y ago
  BTW. For the last 15 years, all web browsers on Windows do WebGL on top of DirectX (using the Angle library https://github.com/google/angle https://github.com/google/angle).
cmovq 4y ago
Syntax discussions are hardly ever productive but the `vec4<f32>` syntax is truly awful in shaders. HLSL solved this ages ago with `float4`, `int4`. And even GLSL which uses `vec4` to mean float makes sense given you are almost always dealing with floats in shaders.
adam_arthur 4y ago
Will be interesting to see if WebGPU opens the door to viable WASM/WebGPU first driven Web UIs. I guess the main downside at the moment are limitations like not being able to issue http requests from within the wasm sandbox, and payload size of the wasm itself. Of course UI rendering code can and should be separated out from business logic... but then the level of complexity of maintaining JS/WASM together makes it all seem not very worthwhile... I'd rather just do it all within a single language. Still, likely to get widespread adoption for DataViz style widgets/games.

Learn WebGPU

243 points by ibobev 4y ago

wheelerof4te 4y ago

Great guide that introduces people to a overcomplicated, redundant feature-creep.

KeplerBoy 4y ago
GPUs are getting ridiculously powerful and having proper API to utilize them is important. People want to have powerful apps in their browser, so there's clearly a need to have access to compute shaders from JS and WASM.
- wheelerof4te 4y ago
  "People want to have powerful apps in their browser" There is something rotten in that statement. No, you absolutely don't have to use such power in the browser. There is a reason we have a thing called an operating system.
  - skitter 4y ago
    With browsers being operating systems that do sandboxing by default. If I know I want to run an app, I prefer a native version, but browsers are superior for trying things out.
  - devmor 4y ago
    If every system has a web browser that handles WASM and program develop paradigms shift to primarily utilize it, then programs by default are cross-platform and memory sandboxed. Sounds a lot better than today.
    - horsawlarway 4y ago
      I mean - to be fair, you have this already today. It's just limited to html/js/css as the tooling. Which is actually a-ok for the vast majority of use-cases. Honestly, I really don't want companies to be making GUIs using WASM/WebGPU. Html/css/js solve that domain fairly well already, and the "canvas-only" wasm implementations I've seen so far are pretty damn monstrous. Outside of being a completely opaque box to me, the user, they're also usually not terribly performant, break all sorts of expected behavior, and have cross platform issues. I'm interested in seeing if webGPU enables more ML possibilities on the web, especially ML that's running client side and not over the wire. But really - that's about it. GUI tasks seem like a bad pick for this. They're literally several steps backwards from where we are right now, and they completely remove the ability to inspect the running application as the user. And that last point is a really, really big deal. Personally, I like a web that supports things like 3rd party integrations, ad-blockers, user-agent css styling, etc. I don't want a fucking canvas riddled with ads that I cannot interact with.
      - danShumway 4y ago
        This is my one fear with GPU stuff. I'm using Canvas when I build games on the web, and that's about it. And even there I'm regularly trying to think "isn't there some way I could represent this application state as a tree?" There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. I want people to be able to build more powerful stuff on the web, but I don't want them to start looking at the DOM as if it's just some inconvenient quirk of the platform rather than a really seriously integral part of the web's success as a platform. Yes, it's often inconvenient to build fancy effects on top of the DOM, yes you have to worry about updates and performance -- because your entire application state is not supposed to be in the DOM 100% of the time; the DOM should be treated as a render target presenting the application state and controls that are relevant to the user right now. The DOM forces you to represent your current app's interface as a pure-text XML tree;that is the common denominator for all of your users no matter what device or features or settings they have enabled. Targeting that common denominator is good practice because in most (not all but most) cases if you can't sit down and write out your app's current interface as presented to the user on a sheet of paper by hand as an XML tree, probably something in your interface has gone wrong or gotten too complicated and you ought to be rethinking the UX anyway.
        beebeepka 4y ago
        But bypassing DOM is the main point when you have to draw and animate a lot of stuff quickly. I say let the browsers use these low level API for speeding up DOM and CSS. But also allow people to bypass this layer. Back in the day I migrated (more like recreated) a web RTS from DOM to canvas and getting rid of all that HTML and CSS was a massive relief. Deleted so much markup, styles and js all while improving performance massively.
        danShumway 4y ago
        I'm using WebGL for game development right now (and am somewhat looking forward to WebGPU) -- I'm not saying everything needs to be in the DOM. Just most things. It shouldn't really be the default for application frameworks to target Canvas (and multiple frameworks do treat it like the default rendering target). Like I said: > There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. An RTS may be an exception to that because for most RTS games you can't sit down and describe what's going on in the game in a clear way using a pure-text tree or interactive document. But "exception" is the important word there. Most web apps aren't games, most web apps shouldn't be laying out complicated 2D/3D graphical scenes.
    - timw4mail 4y ago
      Just makes the browser the level that has to be up to date, which determines what hardware is still usable. If Chromebooks are anything to go by, this will just end up making more hardware unusable for new software.
  - KeplerBoy 4y ago
    Telling people that the thing they want is stupid, won't stop them from wanting it.
    - wiz21c 4y ago
      Alas. Three times alas...
  - flohofwoe 4y ago
    The post is actually about using WebGPU as native library in native applications (outside the browser or Electron). (but apart from that there seems to be a growing schism between people who see the browser as a document viewer, and others who see it as an application platform, I'm definitely in the platform camp ;)
  - dragonelite 4y ago
    Yet they all though it to be worth the engineering time to deliver this utility. While i agree with you i know a lot of people that find interaction via a browser more natural than a desktop application. A bit like some emacs jokes go and say the operating system is just their bootstrapper for emacs.
  - notjustanymike 4y ago
    Heaven forbid a doctor be able to share a link of a 3D visualization for a procedure so patients have a better understanding of the decisions they have to make. That'd be way too convenient!
  - danShumway 4y ago
    I'd be more sympathetic to this statement if any of the modern operating systems had halfway decent sandboxing. Insert inevitable reference to "the Birth and Death of Javascript" but native platforms should be copying the web more in general. The DOM is just structured CLI output, with all of the advantages that CLIs have. Seriously, as a user nearly every native app on my machine ought to (in a better world) be rendering its interface to a structured text format that I can inspect and modify on the fly and pipe into other applications or dynamically restyle as I see fit. Because of that structure, most web-apps can be extended arbitrarily with user extensions. The sandboxing on the web is... okay it's not great, but it's better than what anybody else is doing. The delivery platform for apps is better specifically because the sandboxing is better, which allows me to try out apps quickly without giving them a lot of unnecessary access to my computer. People are building apps in the browser because browsers offer capabilities that native operating systems don't offer. The few platforms where browser dominance doesn't hold true (iOS, Android) largely maintain native dominance by severely limiting what web browsers can do. That's the wrong way to move forward; offer a native experience that's as good as the web and people won't need to build apps on the web. Even just good application sandboxing alone would be a good start, and yet whenever something like Flatpak tries to make progress in that direction, people are constantly complaining about it and explaining that sandboxing is the wrong way to approach app security. It's not really surprising then that people look at that discussion and take away from it that maybe the desktop isn't a good fit for their app. ---- My only critique of the webGPU direction is people bypassing the DOM, which... is usually the result of native developers and native frameworks trying to bring native development patterns to the web instead of rallying behind the idea of user-inspectable pure-text interfaces in the DOM. In that regard, and very specifically in that regard, I do kind of agree that the web is becoming too much like a native operating system. In the sense that it is repeating the same exact mistakes that native operating systems made. But in regards to people just generally building apps in browsers... good. Honestly, progressive web apps are a safer, more user-respecting way to deliver functionality than native OSes are.
    - shortrounddev 4y ago
      > if any of the modern operating systems had halfway decent sandboxing What qualifies as "halfway decent"? For servers, Linux seems to have a good set of utilities (taken advantage of by docker). Windows doesn't seem to have as good system calls (like chroot, for example), but UWP apps seem to be decent enough for a sandboxed app. What would be a good example of sandboxing for you? Personally I think that websites are the most popular way to distribute applications because it only requires a single link or URL to download the software and have it run immediately as required. No other cross-platform computing VM (JVM, CLR) can boast about that kind of ease of distribution. Additionally, HTML + CSS + JS have proven to be the most popular UI platforms. XAML just doesn't come close to the flexibility provided by these tools, and non-declarative UI is just out of the question for the majority of people designing websites in HTML, who are not software engineers
  - deleted 4y ago
    [deleted]
- pjmlp 4y ago
  Some of us wouldn't consider design by committee APIs as proper.
  - deleted 4y ago
    [deleted]

supernikio2 4y ago

It's really interesting how the natural ecosystem for wgpu and wasm seems to be Rust, when C++ is also a prime candidate. Could this be the recency bias associated with Rust being the new kid in the block?

flohofwoe 4y ago
It's probably as simple as 'cargo vs cmake'. wgpu-native is a regular cargo package which is straightforward to integrate and build. Google's libdawn is a mix of cmake and Google depot tools, which makes the same process anything but trivial. I don't agree with your take on WASM though. Emscripten does a pretty good job of making developer's life easier. (there's also a real need for a medium-level cross-platform GPU API which abstracts over D3D12, Vulkan and Metal, and WebGPU seems to be the most robust option for this at the moment)
pjmlp 4y ago
The natural ecosystem is the browser. There is Dawn for C++, also shipped alongside node.
- CyberDildonics 4y ago
  Yes I agree, the natural ecosystem is webasm in the browser now that for the first time in history everyone has a good fast and general jit vm they can use. I'm surprised something like webasm didn't happen sooner but at least it is here now.
  - pjmlp 4y ago
    WebGPU doesn't have anything to do with WASM. Anyone that wants to use it productively is also better off with BabylonJS, PlayCanvas, Threejs.
    - CyberDildonics 4y ago
      Yes I'm agreeing that the natural ecosystem of the browser is because of thing like webgpu and webasm now that it has been invented.

cormacrelf 4y ago

With reference to the section on how difficult it is to build wpgu-native and how you basically have to use a precompiled binary, there appears to be an easier way to integrate a Cargo library into a CMake project: https://github.com/corrosion-rs/corrosion https://github.com/corrosion-rs/corrosion

kypro 4y ago

As someone who's very recently been looking into using WebGPU on a project, why must it be so complicated to execute some simple instructions on a GPU? All of the code I was looking at seems to use (and require from the API) a lot of graphics terminology like "shaders", etc. Additionally it seemed to require a bizarre amount of boilerplate code to create compute "pipelines" and other things. Is there some reason that running code on a GPU must be so difficult? Why is there no API I can call like, `GPU.exec(() => 2 * 2);` Sorry for the dumb question. I'll definitely be taking a look through this guide later.

Chabsff 4y ago
TL;DR; It has to work blazingly fast on all kinds of GPUs, which are not nearly as homogeneous as you might expect. The complex setup is the "lowest common denominator" of that ecosystem. GPUs are stupendously good at ridiculously wide parallel processing, yet you still need to sequence these operations. Modern Graphics API setups like Vulkan and WebGPU are the currently best known way to write such systems. Shaders express the parallel algorithms, and the pipelines binds and synchronizes them together. It's just legitimately the best way, as far as we know, to get the most bang out of your buck for that hardware while remaining vendor-agnostic. Anyways, a higher-level abstraction can always be built on top that provides you with the UX you desire, and we will see a bunch of them for WebGPU soon enough.
overthrow 4y ago
WebGPU is a low-level interface close to the hardware. If you don't care about having control over those details, it's not the right API to use. You'd have better luck with either a high-level wrapper or something else like WebGL.
- kypro 4y ago
  WebGL still requires shader code I believe, and also uses graphic-specific terminology. My understanding is that there is no high-level native API for compute-specific use-cases. You are currently forced to use an API intended for graphics and then create abstracts for compute yourself. I believe GPU.js exists to fill this void and facilitate simple GPU compute on the web without the need for all of the graphic-specific terminology and boiler plate code. But why a 3rd party library is needed for this makes little sense to me since a high-level native GPU (or hybrid) compute API seems like a great way to optimise many JS projects on the web today. I must be missing something though because this seems like such a no brainer that if it was possible it would already be a thing.

oytis 4y ago

This is the first WebGPU guide I've seen that shows how to make shaders do something useful, really appreciate that.

vrglvrglvrgl 4y ago

[dead]

seabass-labrax 4y ago

From https://eliemichel.github.io/LearnWebGPU/getting-started/hello-webgpu.html https://eliemichel.github.io/LearnWebGPU/getting-started/hel...: > Since wgpu-native is written in rust, we cannot easily build it from scratch so the distribution includes pre-compiled libraries Isn't this the wrong way round? Building from source seems to be the default for Rust programs, as they are typically statically linked.

pjmlp 4y ago
Being statically linked works just as well with binary libraries in compiled languages.
steveklabnik 4y ago
Given that this article seems to be coming from a “you’re writing C++” perspective, I read this as “you probably don’t have a rust compiler installed so it’s not as easy for you to build from source as a C++ library would be.”
- seabass-labrax 4y ago
  Ah, that makes sense! The author is also using CMake, which I imagine doesn't have much integration with Cargo.

seabass-labrax 4y ago

From https://eliemichel.github.io/LearnWebGPU/_images/rhi.png https://eliemichel.github.io/LearnWebGPU/_images/rhi.png, it looks like on FOSS systems that Vulkan is the supported graphics library for interfacing with the GPU. This is in contrast with WebGL, which specifically targets OpenGL ES, without support for Vulkan or the various proprietary graphics libraries. Am I right in this evaluation?

IvanK_net 4y ago
BTW. For the last 15 years, all web browsers on Windows do WebGL on top of DirectX (using the Angle library https://github.com/google/angle https://github.com/google/angle).

cmovq 4y ago

Syntax discussions are hardly ever productive but the `vec4<f32>` syntax is truly awful in shaders. HLSL solved this ages ago with `float4`, `int4`. And even GLSL which uses `vec4` to mean float makes sense given you are almost always dealing with floats in shaders.

adam_arthur 4y ago

Will be interesting to see if WebGPU opens the door to viable WASM/WebGPU first driven Web UIs. I guess the main downside at the moment are limitations like not being able to issue http requests from within the wasm sandbox, and payload size of the wasm itself. Of course UI rendering code can and should be separated out from business logic... but then the level of complexity of maintaining JS/WASM together makes it all seem not very worthwhile... I'd rather just do it all within a single language. Still, likely to get widespread adoption for DataViz style widgets/games.