Chrome ships WebGPU • Hacker News Board

Re: Chrome ships WebGPU

#231

Post by adrian17 » Thu, Apr 06, 2023, 1:57 PM UTC

grishka wrote: post #201

codedokode wrote: post #140

I remember when WebRTC was introduced, it was found that it became very popular and was used by almost every page. But closer inspection showed that its use was to get user's IP address for better fingerprinting. I predict that WebGL/WebGPU will be mainly used for the same purposes. Nobody needs new fancy features, what people really need is more reliable fingerprinting (this is proven by number of uses of WebRTC for…

People tend to forget that the good part about Flash was that it offered all this (there was an API for low-level high-performance 3D graphics, Stage3D), except there was also an explicit boundary between the "document" and the "app" and most browsers offered an option to only load Flash content when you click on its area. I'm thus still convinced that turning browsers themselves into this application platform kind o…

> and most browsers offered an option to only load Flash content when you click on its area

> there is at least one project of an open source Flash player (Ruffle)

Just so you know, Ruffle supports (optionally) autoplay without clicking (this has some restrictions, like no sound until it gets a user interaction) _and_ we do plan to try running on webgpu very soon - so unfortunately we rely on this one way or another :(

(also there are other projects, Ruffle just happened to get the best word-of-mouth PR)

Re: Chrome ships WebGPU

#232

Post by pier25 » Thu, Apr 06, 2023, 2:01 PM UTC

lima wrote: post #221

pier25 wrote: post #217

Don't get me wrong, this is supremely cool... but I wish the W3C and browsers solved more real world problems. Just think how many JS kBs and CPU cycles would be saved globally if browsers could do data binding and mutate the dom (eg: morhpdom, vdom, etc) natively . And the emissions that come with it. Edit: For example, just consider how many billions of users are downloading and executing JS implementations of a VD…

> Just think how many JS kBs and CPU cycles would be saved globally if browsers could do data binding and mutate the dom (eg: morhpdom, vdom, etc) natively. And the emissions that come with it. Browsers are solving these real-world problems. With modern JS engines, frameworks are nearly as efficient as a native implementation would be. And with web components, shadow DOM and template literals, all you need is a very…

> frameworks are nearly as efficient as a native implementation would be

I have a very hard believing that a C++ implementation of eg a VDOM would not be significantly more efficient than a JS one. I'm just doing some benchmarks and even the fastest solutions like Inferno get seriously bottlenecked after trying to mutate about 2000 DOM elements per frame.

And even if the performance was similar, what about the downloaded kBs? How many billions of users download React, Angular, Vue, etc, every single day? Probably multiple times.

Re: Chrome ships WebGPU

#233

Post by shadowgovt » Thu, Apr 06, 2023, 2:03 PM UTC

brookst wrote: post #229

shadowgovt wrote: post #220

Earlier quoted context omitted.

How badly can you wreck state in bindless? Badly enough to see the pointers of another process or detect a lot of high-detail information on what computer is running the program? If so, that'd be a non-starter for a web API. Web APIs have to be, first and foremost, secure and protect the user's anonymity.

All of this is in the context of a browser. If a misbehaving web app uses pointers for memory from another process, that should be blocked by all of the same things that prevent non-privileged apps from doing the same thing.

Agreed, as long as they sandbox properly (because it's also important that you can't use the API to find out information from another tab).

Re: Chrome ships WebGPU

#234

Post by pier25 » Thu, Apr 06, 2023, 2:05 PM UTC

shadowgovt wrote: post #218

pier25 wrote: post #217

Don't get me wrong, this is supremely cool... but I wish the W3C and browsers solved more real world problems. Just think how many JS kBs and CPU cycles would be saved globally if browsers could do data binding and mutate the dom (eg: morhpdom, vdom, etc) natively . And the emissions that come with it. Edit: For example, just consider how many billions of users are downloading and executing JS implementations of a VD…

What would that mean? And what version of "mutate the DOM via databinding" would win, because there are at least three different approaches used in various JS libraries? Accessing the GPU in this way is something that can't be done without browser-level API support. You're describing a problem already solved in JS. Different category entirely.

> What would that mean?

Honestly no idea, but any native implementation would be more useful than a userland JS implementation.

> Accessing the GPU in this way is something that can't be done without browser-level API support.

That's true and it will open the door to many use cases. But still, mutating the DOM as efficiently as possible without a userland JS implementation is orders of magnitude more common and relevant to the web as it is today.

Re: Chrome ships WebGPU

#235

Post by pier25 » Thu, Apr 06, 2023, 2:06 PM UTC

flohofwoe wrote: post #219

pier25 wrote: post #215

Earlier quoted context omitted.

> with mobile being actually much more important than desktop How so? I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?

In general, WebGL has more CPU overhead under the hood than WebGPU, so the same rendering workload may be more energy efficient when implemented with WebGPU, even if the GPU is essentially doing the same work.

Thanks. Good point.

Re: Chrome ships WebGPU

#236

Post by mschuetz » Thu, Apr 06, 2023, 2:09 PM UTC

tormeh wrote: post #6

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.

Unfortunately WebGPU is also an essentially a 5 year old mobile phone graphics API, which means for most desktop features younger than 10 years, you'll still need DirectX, Vulkan, or Metal.

Re: Chrome ships WebGPU

#237

Post by mschuetz » Thu, Apr 06, 2023, 2:11 PM UTC

Ciantic wrote: post #120

This is a comment from Aras Pranckevičius [1]: > WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol) > As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd itera…

Yeah, WebGPU unfortunately ended up becoming an outdated mobile phone graphics API on arrival. Still better than WebGL, but not quite what I would have liked it to be.

Re: Chrome ships WebGPU

#238

Post by littlestymaar » Thu, Apr 06, 2023, 2:15 PM UTC

Timja wrote: post #230

littlestymaar wrote: post #116

Earlier quoted context omitted.

Fingerprinting in the usual sense the term isn't about distinguishing Chrome from Firefox, it's about distinguishing user A from user B , … user X reliably in order to be able to track the user across website and navigation sessions. Your example is unlikely to get you far. Edit: in a quick test, I got a range between 8 and 49 in Chrome, and between 1.27 and 51 (!) on Firefox, on the same computer, the results are ve…

Chrome and Firefox here are an example for "Two users who use exactly the same hardware but different software". To distinguish between users between of a larger set, you do more such tests and add them all together. Each test adding a few bits of information. To make the above code more reliable, you can measure the ratio multiple times: https://jsfiddle.net/dov1zqtL/ I get 9-10 in Firefox and 3-4 in Chrome very rel…

> Chrome and Firefox here are an example for "Two users who use exactly the same hardware but different software".

But it's also the most pathological example one can think of, yet the results are extremely noisy (while being very costly, which means you won't be able to make a big number of such test without dramatically affecting the user's ability to just browse your website).

Re: Chrome ships WebGPU

#239

Post by kllrnohj » Thu, Apr 06, 2023, 2:17 PM UTC

singularity2001 wrote: post #131

tormeh wrote: post #6

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.

the best way to code cross-platform graphics outside the browser. so WebGPU is a bit like WebAssembly which might really shine outside the Web (on the Edge, as universal bytecode format, for plugins …)

Except unlike WebAssembly this one is actually useful. WASM enters a domain full of existing universal bytecodes that all failed to become truly universal because the actual assembly is never the hard part to get portable, it's the API surface. Which WASM doesn't even pretend to attempt to handle, unlike a Java or C# which ship pretty fat bundled libraries to abstract most OS differences.

Meanwhile on the GPU front you don't have much in the way of large, good middlewares to abstract away the underlying API. OpenGL used to be OK at this, but now neither platforms nor Khronos wants to touch it. Vulkan is "portable" but it's like writing assembly by hand, it's ludicrously complicated. WebGPU fills the role of essentially just being GLES 4.0. It won't be fast, it won't be powerful, but it doesn't actually need to for the long tail of things that just want to leverage a GPU for some small workloads.

Re: Chrome ships WebGPU

#240

Post by kllrnohj » Thu, Apr 06, 2023, 2:19 PM UTC

tormeh wrote: post #36

gostsamo wrote: post #21

Earlier quoted context omitted.

or it will be yet another standard

Not really. I don't see how any of the vendors could break it without being extremely overt about it. And it has no direct competition. Nothing else runs on any OS and any GPU, except WebGL, which is abandoned.

Vulkan & GLES are both the obvious competition here, I don't know why you seem to be ignoring them?