8 ms·

Wgpu-rs on the web

232 points by grovesNL 6y ago

OwnsE 6y ago
This is really cool. I've been excitedly watching how wgpu is developing. I don't have much graphics experience outside of one ogl but it looks like it's turning into something seriously neat.
- royjacobs 6y ago
  Definitely. The last time I did any truly serious graphics programming was in the early noughts and the fact that I can now toy around with a really modern graphics stack in a reasonably straightforward, cross-platform yet still performant way is really wonderful. I've been enjoying my time with wgpu-rs so far and I intend to keep doing so.
snissn 6y ago
Can it do sha3 hashing in a web browser on the gpu?
- kangz 6y ago
  Yes, so does WebGL and with the same efficiency. Partial hash inversion is an embarrassingly parallel problem: computing a hash from a random number is independent from the other random numbers you want to compute hashes for, also it is a computation bound problem and not memory bound. It means you can build a fairly efficient partial inverse finder by running many fragment shaders ("pixels") in parallel and only drawing the one that finds it. This is doable in WebGL today. A key feature of WebGPU is compute shaders which sound like they can compute stuff so they would be better at hashing. But actually compute shaders give more flexibility which makes it possible to handle problems that are a bit less parallel, and they help optimize memory-bound programs (but don't help for computation bound programs). So compute shaders make it slightly less code to do a partial inverse finder, but do not make it dramatically more efficient. So to answer your implicit point: no WebGPU won't unlock capabilities that will lead to a rise in ads mining Bitcoin. (though it could maybe help for Ethereum mining)
  - snissn 6y ago
    Can you share an example or tutorial?
    - grovesNL 6y ago
      There are some resources for wgpu-rs linked from the blog post (such as https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/). There are also some tutorials available that demonstrate how to use the browser API directly: - Raw WebGPU https://alain.xyz/blog/raw-webgpu https://alain.xyz/blog/raw-webgpu - Get started with GPU Compute on the Web https://developers.google.com/web/updates/2019/08/get-started-with-gpu-compute-on-the-web https://developers.google.com/web/updates/2019/08/get-starte...
echelon 6y ago
This is why Rust is going to eventually eat Javascript's lunch on the browser. I'm willing to longbets that by 2025 we see a Rust framework as the top browser toolkit. I'd even be willing to bet that there are popular frameworks in use by major websites that discard the DOM altogether for something simpler and faster. There's a reason why this has to happen, too. My sincere hope is that Mozilla and the Rust/Browser luminaries will develop cross-platform APIs for full device hardware abstraction. If we can get Rust/WASM to be able to access the same system calls, hardware resources, payment APIs, native windowing routines, etc. as the iOS and Android SDKs, then we can potentially build a cross-platform native web that is just as snappy as the two shitty walled gardens we have today. I really hope the performant web slays the app store. That's the dumbest trap we ever fell for. I'd love to visit a website and be playing native Minecraft in seconds. Sans Google Play or the App Store, with no bullshit monopoly tax. That would address one of the major problems in our industry.
- pornel 6y ago
  I wish it was true, and maybe the web would be better off if it happened… but I don't see it happening. The JS ecosystem is huge and thriving. TypeScript is good enough that there's no burning need to replace it.
- twic 6y ago
  "Top" measured how, and how much would you like to bet?
- deleted 6y ago
  [deleted]
- p1necone 6y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... This is becoming (somewhat) more true every day.
- chrismorgan 6y ago
  What do you mean by “browser toolkit”? If you mean “thing that people make web apps with” (like React or like you might imagine Qt being, though it’s not for the web platform), there is not a chance that this will happen by 2025. Zero. For starters, Rust: Rust is just too complex to be the most popular language when something like JavaScript exists which is faster and easier to get started with, and generally good enough. It has niche usage and will steadily grow, but it’s not going to take over the space any time soon, and probably never will. I say this as a Rust developer for seven years and a web developer for more than fifteen years. Then the other part, discarding the DOM altogether: there are way too many pieces of functionality that the browser provides that currently cannot be implemented in web user space, for this to become mainstream any time soon. For example: correct scrolling, standard keyboard and mouse event handling, and accessibility. The idea that you would go from quite a few pieces of major functionality completely non-existent in browsers and specs (most of these issues aren’t even being talked about) to mastery of the space within five years is unreasonable. For further shared abstractions, many web APIs are developed and continue to be developed. Other experiments like WASI exist. WebAssembly has scope to be a solid foundation for this sort of thing. But applying all of the interesting web APIs to desktop and mobile platforms, that’s not really something that Mozilla, Rust or browser developers can or should do anything about. They have somewhere between no and extremely limited clout in such spaces.
twic 6y ago
I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bindings. Here's what i think: 1. Vulkan is an API for doing graphics which is modern and standard 2. Direct3D (part of DirectX, the names are sometimes used interchangeably), Metal, and OpenGL are APIs for doing graphics which are modern or standard 3. Vulkan, Direct3D, Metal, and OpenGL are all implemented by graphics card drivers and operating systems working together - this is pretty much the bottom of the software stack 4. gfx-hal (along with gfx-backend-*) is a Rust library which abstracts over Vulkan, Direct3D, Metal, and OpenGL; its API is similar to Vulkan, but not identical 5. The Vulkan portability bindings implement Vulkan (the "universally portable subset") on top of gfx-hal (to an extent - it seems like there are lots of little bits that can't be implemented for each backend) 6. WebGPU is an API for doing graphics which is modern, standard, and easier than Vulkan 7. WebGPU is (or soon will be) implemented directly by browers, on top of who knows what, Direct3D etc i suppose 8. wgpu-core is an implementation of (a Rust projection of) WebGPU on top of gfx-hal 9. wgpu-native is a C API on top of wgpu-core 10. wgpu-rs is a nice Rust API on top of WebGPU, which can (now!) use either a browser's WebGPU, or wgpu-native gfx-rs is the name of the overall project. I'm sticking to text mode.
- DagAgren 6y ago
  1. Vulkan, Direct3D, Metal, and OpenGL are all native 3D APIs on different platforms. 2. WebGPU is a new 3D API, designed to be used in browsers (but not limited to them) and implemented on top of one or more of the native APIs. 3. wgpu-native is Mozilla's implementation of WebGPU, built in Rust on top of gfx-hal, which is a Rust-specific abstraction on top of native APIs. 3. wgpu-rs is a convenience wrapper to make the API more Rust-like, which either uses wgpu-native directly, or when compiled for a browser, the browser's own WebGPU implementation. 4. Dawn is Google's implementation of WebGPU, in C++, which similarly can be used directly or through a browser.
  - DagAgren 6y ago
    The nice side effect here is that even if you are not targeting browsers, if you want a modern, fast, usable and cross-platform 3D API, there now is one, which hasn't been the case for a long time. And there are at least two different implementations of it.
brabel 6y ago
One of the things that use wgpu-rs is Iced[1], a cross-platform GUI Library inspired by the Elm Architecture. Although the project started around May 2019 and is still highly experimental, it looks like they got a lot of progress made and things look promising! The interest seems incredible: they have 5.4K stars on GitHub (amazing for such a young project) and there are lots of impressive examples[2]. As someone who just learned about the project: hope this takes off!!! A lightweight, simple to use GUI toolkit that can run on the browser and desktop is really something developers desperately want. [1] https://github.com/hecrj/iced https://github.com/hecrj/iced [2] https://github.com/hecrj/iced/tree/master/examples https://github.com/hecrj/iced/tree/master/examples
- red2awn 6y ago
  I was just playing around with Iced yesterday, it is indeed very nice. I wish it has better docs though.
raphlinus 6y ago
This is very cool stuff. I'm waiting a bit for it to become more mature, then I'd like to use it as the basis for druid, a native Rust UI toolkit. As noted in another comment, iced is already doing that. One of the reasons I'm excited is that I believe I can get very high performance, and high quality 2D rendering using an evolution of the techniques explored in the piet-metal prototype. This work extensively uses GPU compute capabilities, which are not available in older versions of OpenGL or in WebGL.
lachlan-sneff 6y ago
I think that wasm potentially has a great future for cross-platform binaries. Eventually, hopefully, the same code that can run in a browser will be able to run natively on linux or macos without recompiling. A major blocker for this is that wasm applications are slower than native ones. There are a few reasons for this, and some of them, like simd support, are slowly being fixed, but an important one in my opinion is that memory in wasm requires bounds checks. Now, there are hacks to make that fast, but they work for wasm32 and not wasm64. I think architectures adding instructions for lightweight memory sandboxing would go a long way to alleviate this problem.

232 points by grovesNL 6y ago

This is really cool. I've been excitedly watching how wgpu is developing. I don't have much graphics experience outside of one ogl but it looks like it's turning into something seriously neat.

royjacobs 6y ago
Definitely. The last time I did any truly serious graphics programming was in the early noughts and the fact that I can now toy around with a really modern graphics stack in a reasonably straightforward, cross-platform yet still performant way is really wonderful. I've been enjoying my time with wgpu-rs so far and I intend to keep doing so.

snissn 6y ago

Can it do sha3 hashing in a web browser on the gpu?

kangz 6y ago
Yes, so does WebGL and with the same efficiency. Partial hash inversion is an embarrassingly parallel problem: computing a hash from a random number is independent from the other random numbers you want to compute hashes for, also it is a computation bound problem and not memory bound. It means you can build a fairly efficient partial inverse finder by running many fragment shaders ("pixels") in parallel and only drawing the one that finds it. This is doable in WebGL today. A key feature of WebGPU is compute shaders which sound like they can compute stuff so they would be better at hashing. But actually compute shaders give more flexibility which makes it possible to handle problems that are a bit less parallel, and they help optimize memory-bound programs (but don't help for computation bound programs). So compute shaders make it slightly less code to do a partial inverse finder, but do not make it dramatically more efficient. So to answer your implicit point: no WebGPU won't unlock capabilities that will lead to a rise in ads mining Bitcoin. (though it could maybe help for Ethereum mining)
- snissn 6y ago
  Can you share an example or tutorial?
  - grovesNL 6y ago
    There are some resources for wgpu-rs linked from the blog post (such as https://sotrh.github.io/learn-wgpu/ https://sotrh.github.io/learn-wgpu/). There are also some tutorials available that demonstrate how to use the browser API directly: - Raw WebGPU https://alain.xyz/blog/raw-webgpu https://alain.xyz/blog/raw-webgpu - Get started with GPU Compute on the Web https://developers.google.com/web/updates/2019/08/get-started-with-gpu-compute-on-the-web https://developers.google.com/web/updates/2019/08/get-starte...

echelon 6y ago

This is why Rust is going to eventually eat Javascript's lunch on the browser. I'm willing to longbets that by 2025 we see a Rust framework as the top browser toolkit. I'd even be willing to bet that there are popular frameworks in use by major websites that discard the DOM altogether for something simpler and faster. There's a reason why this has to happen, too. My sincere hope is that Mozilla and the Rust/Browser luminaries will develop cross-platform APIs for full device hardware abstraction. If we can get Rust/WASM to be able to access the same system calls, hardware resources, payment APIs, native windowing routines, etc. as the iOS and Android SDKs, then we can potentially build a cross-platform native web that is just as snappy as the two shitty walled gardens we have today. I really hope the performant web slays the app store. That's the dumbest trap we ever fell for. I'd love to visit a website and be playing native Minecraft in seconds. Sans Google Play or the App Store, with no bullshit monopoly tax. That would address one of the major problems in our industry.

pornel 6y ago
I wish it was true, and maybe the web would be better off if it happened… but I don't see it happening. The JS ecosystem is huge and thriving. TypeScript is good enough that there's no burning need to replace it.
twic 6y ago
"Top" measured how, and how much would you like to bet?
deleted 6y ago
[deleted]
p1necone 6y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... This is becoming (somewhat) more true every day.
chrismorgan 6y ago
What do you mean by “browser toolkit”? If you mean “thing that people make web apps with” (like React or like you might imagine Qt being, though it’s not for the web platform), there is not a chance that this will happen by 2025. Zero. For starters, Rust: Rust is just too complex to be the most popular language when something like JavaScript exists which is faster and easier to get started with, and generally good enough. It has niche usage and will steadily grow, but it’s not going to take over the space any time soon, and probably never will. I say this as a Rust developer for seven years and a web developer for more than fifteen years. Then the other part, discarding the DOM altogether: there are way too many pieces of functionality that the browser provides that currently cannot be implemented in web user space, for this to become mainstream any time soon. For example: correct scrolling, standard keyboard and mouse event handling, and accessibility. The idea that you would go from quite a few pieces of major functionality completely non-existent in browsers and specs (most of these issues aren’t even being talked about) to mastery of the space within five years is unreasonable. For further shared abstractions, many web APIs are developed and continue to be developed. Other experiments like WASI exist. WebAssembly has scope to be a solid foundation for this sort of thing. But applying all of the interesting web APIs to desktop and mobile platforms, that’s not really something that Mozilla, Rust or browser developers can or should do anything about. They have somewhere between no and extremely limited clout in such spaces.

twic 6y ago

I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bindings. Here's what i think: 1. Vulkan is an API for doing graphics which is modern and standard 2. Direct3D (part of DirectX, the names are sometimes used interchangeably), Metal, and OpenGL are APIs for doing graphics which are modern or standard 3. Vulkan, Direct3D, Metal, and OpenGL are all implemented by graphics card drivers and operating systems working together - this is pretty much the bottom of the software stack 4. gfx-hal (along with gfx-backend-*) is a Rust library which abstracts over Vulkan, Direct3D, Metal, and OpenGL; its API is similar to Vulkan, but not identical 5. The Vulkan portability bindings implement Vulkan (the "universally portable subset") on top of gfx-hal (to an extent - it seems like there are lots of little bits that can't be implemented for each backend) 6. WebGPU is an API for doing graphics which is modern, standard, and easier than Vulkan 7. WebGPU is (or soon will be) implemented directly by browers, on top of who knows what, Direct3D etc i suppose 8. wgpu-core is an implementation of (a Rust projection of) WebGPU on top of gfx-hal 9. wgpu-native is a C API on top of wgpu-core 10. wgpu-rs is a nice Rust API on top of WebGPU, which can (now!) use either a browser's WebGPU, or wgpu-native gfx-rs is the name of the overall project. I'm sticking to text mode.

DagAgren 6y ago
1. Vulkan, Direct3D, Metal, and OpenGL are all native 3D APIs on different platforms. 2. WebGPU is a new 3D API, designed to be used in browsers (but not limited to them) and implemented on top of one or more of the native APIs. 3. wgpu-native is Mozilla's implementation of WebGPU, built in Rust on top of gfx-hal, which is a Rust-specific abstraction on top of native APIs. 3. wgpu-rs is a convenience wrapper to make the API more Rust-like, which either uses wgpu-native directly, or when compiled for a browser, the browser's own WebGPU implementation. 4. Dawn is Google's implementation of WebGPU, in C++, which similarly can be used directly or through a browser.
- DagAgren 6y ago
  The nice side effect here is that even if you are not targeting browsers, if you want a modern, fast, usable and cross-platform 3D API, there now is one, which hasn't been the case for a long time. And there are at least two different implementations of it.

brabel 6y ago

One of the things that use wgpu-rs is Iced[1], a cross-platform GUI Library inspired by the Elm Architecture. Although the project started around May 2019 and is still highly experimental, it looks like they got a lot of progress made and things look promising! The interest seems incredible: they have 5.4K stars on GitHub (amazing for such a young project) and there are lots of impressive examples[2]. As someone who just learned about the project: hope this takes off!!! A lightweight, simple to use GUI toolkit that can run on the browser and desktop is really something developers desperately want. [1] https://github.com/hecrj/iced https://github.com/hecrj/iced [2] https://github.com/hecrj/iced/tree/master/examples https://github.com/hecrj/iced/tree/master/examples

red2awn 6y ago
I was just playing around with Iced yesterday, it is indeed very nice. I wish it has better docs though.

raphlinus 6y ago

This is very cool stuff. I'm waiting a bit for it to become more mature, then I'd like to use it as the basis for druid, a native Rust UI toolkit. As noted in another comment, iced is already doing that. One of the reasons I'm excited is that I believe I can get very high performance, and high quality 2D rendering using an evolution of the techniques explored in the piet-metal prototype. This work extensively uses GPU compute capabilities, which are not available in older versions of OpenGL or in WebGL.

lachlan-sneff 6y ago

I think that wasm potentially has a great future for cross-platform binaries. Eventually, hopefully, the same code that can run in a browser will be able to run natively on linux or macos without recompiling. A major blocker for this is that wasm applications are slower than native ones. There are a few reasons for this, and some of them, like simd support, are slowly being fixed, but an important one in my opinion is that memory in wasm requires bounds checks. Now, there are hacks to make that fast, but they work for wasm32 and not wasm64. I think architectures adding instructions for lightweight memory sandboxing would go a long way to alleviate this problem.