
Wgpu-rs on the web - grovesNL
https://gfx-rs.github.io/2020/04/21/wgpu-web.html
======
echelon
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.

~~~
smichel17
> 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.

I don't, unless certain criteria are met.

There is a consumer-friendly side of apps that is often overlooked in these
types of conversations: generally, I get to decide when to update my apps, and
the developer can't uninstall their app off my phone without my permission.
Moving from apps to the web shifts the balance of power even further from user
to developer.

There are some apps (that require internet access) for which this is not true.
For those, I share your sentiment; spotify has no reason to be an app. It's
also possible to implement this amount of user control with the web, by
caching the full version of a page, when you add it to your home screen (for
example), and only replacing it after an explicit prompt (as a setting, ie
auto-update).

Until that happens, though, I don't wish for the death of app stores.
Especially, f-droid is a great ecosystem.

~~~
Kamshak
Even though I agree with the benefits of having control over updates seeing
how popular SaaS has become I find it quite likely this will happen to (many
kinds of) Apps as well.

------
twic
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.

~~~
MrBuddyCasino
So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs

Anyone has an idea how much performance those layers of abstraction cost?

~~~
grovesNL
Both wgpu and gfx APIs try to avoid any significant CPU usage in hot
rendering/compute paths (e.g. by doing more work upfront instead of during
rendering), so generally the performance cost should be fairly low for most
applications.

The Vulkan API is basically 1:1 with gfx-hal so the performance cost should be
negligible when gfx-hal is running on top of Vulkan. There is some overhead
when running on top of other backends (such as Metal or DX12) versus
implementing separate backends for wgpu, but the design of WebGPU avoids most
places where the overhead would become significant anyway.

Similarly wgpu-rs only adds Rustier bindings to wgpu-core, so any performance
cost should be negligible.

There is some amount of overhead in WebGPU in general (caused by automatic
memory management, additional resource tracking, etc.) versus directly using
raw Vulkan/DX12/Metal, but WebGPU tries to find a good balance here between
security/portability/performance/usability.

------
brabel
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
I was just playing around with Iced yesterday, it is indeed very nice. I wish
it has better docs though.

------
raphlinus
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.

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

~~~
kangz
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
Can you share an example or tutorial?

~~~
grovesNL
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-
starte...](https://developers.google.com/web/updates/2019/08/get-started-with-
gpu-compute-on-the-web)

------
OwnsE
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
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.

------
lachlan-sneff
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.

