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

Chrome ships WebGPU

developer.chrome.com

Post reply on HN
Print view View original

281–290 of 405 posts

Re: Chrome ships WebGPU

#281

Post by pier25 »

lima wrote: post #251
pier25 wrote: post #232

Earlier quoted context omitted.

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

VDOMs were created precisely because the native DOM was too slow. This is no longer the case and a tiny web component framework like Lit significantly outperforms[1] React relying entirely on the browser DOM and template literals for re-rendering... so what you're asking for, has already happened :-) But even the big frameworks are really fast thanks to modern JIT JS engines. [1]: https://www.thisdot.co/blog/showcase…

Yes, I know Lit exists, and yes it's fast. But I think you're missing the point.

I'm not talking about one JS implementation vs another or if JS solutions are fast enough from the end user perspective.

The fastest JS solution (VDOM, Svelte, Lit, whatever) will still be bottlenecked by the browser. If JS could send a single function call to mutate/morph a chunk of the DOM, and that was solved natively, we'd see massive efficiency wins. When you consider the massive scale of the web with billions of users, this surely will have an impact in the emissions of the electricity needed to run all that JS.

And (again) even if there were no perf improvements possible, you're avoiding the JS size argument. Lit still can be improved. Svelte generally produces smaller bundles than Lit. Eg see:

https://krausest.github.io/js-framework-benchmark/current.ht...

But, again, if all the DOM mutation was solved natively there would be huge savings in the amount of JS shipped globally.

Re: Chrome ships WebGPU

#282

Post by topaz0 »

cyral wrote: post #272
topaz0 wrote: post #243

I'd rather not have websites soak up my compute resources, thanks. They are already doing that many times too much for my taste.

Ironically by hardware accelerating those resources, they will be less noticeable.

What do you think there will be more of: a) existing functionality moves to more efficient implementation on gpu, or b) "hey, we can use gpus now, let's shove some more compute-intensive features into this app that add nothing but make it seem more innovative".

Re: Chrome ships WebGPU

#283

Post by mschuetz »

topaz0 wrote: post #264
mschuetz wrote: post #258

Earlier quoted context omitted.

You're free to disable features you don't like. For others, this is good news.

Incredible insight, but I fear it won't work out well: when the option is there and ubiquitous, websites will rely on it, so disabling features is basically choosing to save some of my resources in exchange for a broken web experience.

Since I'm doing 3D graphics in Web Browsers, I consider not having 3D graphics APIs in Web Browsers a broken web experience. The browser is the easiest and safest way to distribute applications with virtually no entry barrier to users. I don't trust downloading just any binary and therefore I won't execute them unless they are from a trusted source. But with 3D in browsers, I can trust any web site not do damage my system and try a large amount of experiences that others create and upload.

Re: Chrome ships WebGPU

#284

Post by notatoad »

illiarian wrote: post #185
codedokode wrote: post #148

Earlier quoted context omitted.

Yes instead of IP address the API now provides Apple DNS hostname. But a proper solution would be to put this unnecessary API behind a permission.

There are too many APIs that need to put behind permissions for permissions to be useful. No idea how to solve this though.

i want the chrome apps model to come back - put your permission requests in a manifest, and when the user clicks and install button the app gets its permissions. so "web apps" that the user cares enough about to install get useful features, but pages that you just visit briefly don't.

Re: Chrome ships WebGPU

#285

Post by osigurdson »

debacle wrote: post #224
osigurdson wrote: post #222

Suppose you have a massive 3D model stored in the cloud, which weighs in at 100GB and requires most of the computation to be handled on the server side. In this scenario, would utilizing something like WebGPU be beneficial, given its primary responsibility for the final 2D projection?

You'd probably implement something that does culling server-side, and then pass the culled model to the client.

Would that work with vtk?

Re: Chrome ships WebGPU

#286

Post by korijn »

MuffinFlavored wrote: post #255
korijn wrote: post #213

Earlier quoted context omitted.

FYI you can already use webgpu directly in python, see https://github.com/pygfx/wgpu-py for webgpu wrappers and https://github.com/pygfx/pygfx for a more high level graphics library

I think I meant to ask "how is machine learning support for things like neural networks instead of graphical 2D/3D operations with WebGPU"?

Well, you could implement that on top of the wrappers as well I guess. Anyway!

Re: Chrome ships WebGPU

#287

Post by eachro »

raphlinus wrote: post #249

This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from. WebGPU…

Suppose you're a ML practictioner. Would you still recommend learning WebGPU, over say spending more time on CUDA?

Re: Chrome ships WebGPU

#288

Post by skybrian »

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…

Who is using web components? It seems like frameworks that don’t use them are a lot more popular?

Re: Chrome ships WebGPU

#289

Post by illiarian »

jefftk wrote: post #146
illiarian wrote: post #41

Earlier quoted context omitted.

> Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...

Google doesn't benefit because Google has committed not to fingerprint for ad targeting, but their competitors do.

You've got it backwards.

Re: Chrome ships WebGPU

#290

Post by tehsauce »

FL33TW00D wrote: post #135

This is very exciting! (I had suspected it would slip to 114) WebGPU implementations are still pretty immature, but certainly enough to get started with. I've been implementing a Rust + WebGPU ML runtime for the past few months and have enjoyed writing WGSL. I recently got a 250M parameter LLM running in the browser without much optimisation and it performs pretty well! ( https://twitter.com/fleetwood___/status/16384…

It’s better to compare against an ML framework than to maximum theoretical flops because sometimes it’s not possible to reach. These models are often limited by memory bandwidth rather than flop capability.
Post reply on HN