Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wgpu-rs on the web

gfx-rs.github.io

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Wgpu-rs on the web

#41

Post by red2awn »

brabel wrote: post #16

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…

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

Re: Wgpu-rs on the web

#42

Post by [deleted] »

satvikpendem wrote: post #35
olah_1 wrote: post #29

Earlier quoted context omitted.

> a fully native framework that eschews the DOM by compiling directly onto a canvas Wouldn't that essentially be the death of accessibility on the web, though?

I see this concern a lot with Flutter or similar WASM -> canvas frameworks, and I think it's unfounded. Just because it's a canvas doesn't mean there's no accessibility. Indeed, even desktop apps are canvas like in that one cannot view the source and they can render using similar frameworks like Skia, or even Skia itself, yet they still have accessibility. Flutter's developers have specifically included accessibility…

[deleted]

Re: Wgpu-rs on the web

#43

Post by neutronicus »

echelon wrote: post #4

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 l…

I don't know.

Rust's most successful UI story appears to be "punt and delegate to JS via Electron, RPC, etc." There might be some client-side wasm Model written in Rust that the JS is calling into, but the making of widgets and whatnot is in JS.

Note that this parallels all the hipster languages of yesteryear, which invariably answered questions about the GUI story with one of "punt and delegate to C via a thin wrapper over WxWidgets or what have you" or "punt and delegate to the browser via some combination of JavaScript and HTTP."

The path for Rust to overtake JS in browser land is something like "compile an already-existing Qt-in-Rust to wasm with some browser-API-specific back end."

But Qt-in-Rust doesn't even exist.

Re: Wgpu-rs on the web

#44

Post by MrBuddyCasino »

twic wrote: post #6

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,…

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

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

Re: Wgpu-rs on the web

#45

Post by pjmlp »

flohofwoe wrote: post #37
pjmlp wrote: post #24

Earlier quoted context omitted.

Not really, because WASM doesn't do bounds checking on linear memory access, while Rust, C++ (with STL data types) do it.

WASM provides enough memory safety so that memory corruption errors in the WASM heap can't be used to escape the sandbox (assuming there's no exploitable bug in the sandbox itself of course). It doesn't protect from memory corruption inside the WASM heap of course.

A fun exercise would be compiling the Heartbleed version of OpenSSL into WASM.

Exploits can escape the sandbox, via functions exported from WASM that change their behaviour due to internal memory corruption, or callbacks that get called with unexpected parameters from the WASM code due to the internal memory corruption that changed the execution logic.

For example, a security system that would grant higher credentials than it was supposed to.

Re: Wgpu-rs on the web

#46

Post by brabel »

chrismorgan wrote: post #20
flohofwoe wrote: post #18

Earlier quoted context omitted.

TBH, I doubt it, writing "high level" Rust requires a too big "runtime portion" (in the same sense of "runtime" as the stdlib in C++, which also tends to bloat up executables), while "embedded style" minimal Rust without such a "runtime part" is so low-level you could just as well write C code (which is also "memory safe" in that environment because of WASM). And even in the best case, a WASM blob still has a hard ti…

Are you in the habit of using Rust + WASM? From how you’re wording this, I suspect not. Rust really doesn’t require a large runtime (until you do something that requires Unicode tables, then you pay a certain tax), and the difference between high-level and embedded styles is normally small to nothing—the whole concept of zero-cost abstractions is normally talking about performance, but correlates extremely strongly w…

> because WASM does have a tendency to make big code blobs easier to produce, especially if you’re using generics liberally.

WASM was designed to be compiled to very small binaries. The big code blobs you see are produced by the Rust compiler and are not a characteristic of WASM... just check the output of the Rust compiler for a hello world project in WAT format and you'll see it consists almost entirely of the memory allocator that's included in the binary...if you write the same code in WAT directly, or something like AssemblyScript[1], which is designed to use WASM primitives, it's going to be a few bytes for your typical WASM hello world.

[1] https://docs.assemblyscript.org/

Re: Wgpu-rs on the web

#47

Post by kvark »

MrBuddyCasino wrote: post #44
twic wrote: post #6

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,…

So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs Anyone has an idea how much performance those layers of abstraction cost?

It's really hard to estimate without implementing alternative paths that are more direct and yet fairly optimized. For example, since Intel and AMD have open-source drivers on Linux, somebody could write respective wgpu-core implementations directly on top of the drivers. That's a lot of work, and without a clear prospect of being much faster.

Re: Wgpu-rs on the web

#48

Post by 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.

Re: Wgpu-rs on the web

#49

Post by grovesNL »

MrBuddyCasino wrote: post #44
twic wrote: post #6

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,…

So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs Anyone has an idea how much performance those layers of abstraction cost?

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.

Re: Wgpu-rs on the web

#50

Post by rl3 »

kvark wrote: post #32
twic wrote: post #6

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,…

I drew this on the whiteboard within Mozilla a few times, and I agree it would be nice to make it more accessible and hosted at gfx-rs repository or the blog. There is a few scattered sub-diagrams on the topic, buried in the various slide decks I made: https://github.com/kvark/slides/blob/master/BuildingWebGPUwi... https://github.com/kvark/slides/blob/master/IntroductionToWe... https://github.com/kvark/slides/blob/ma…

I like the diagram that has "Google's Dawn" and "Apple's something" side by side. :)

Thanks for all your hard work on gfx-rs! I've been following its progress for a few years now, and despite the major architecture redesign, the project appears to be stronger than ever now. Bravo. Your work is much appreciated.

Post reply on HN