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

221–230 of 405 posts

Re: Chrome ships WebGPU

#221

Post by lima »

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 thin convenience layer like Lit/lit-html[1] to build clean and modern web applications without VDOM or other legacy technology.

[1]: https://lit.dev

Re: Chrome ships WebGPU

#222

Post by osigurdson »

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?

Re: Chrome ships WebGPU

#223

Post by gardaani »

hutzlibu wrote: post #28
j-pb wrote: post #15

I lost all hope for WebGPU after they decided to roll their own ad-hoc shader language that kinda looks like, but is totally not rust. At least with WebGL you had C. Without SPIR-V support this spec is just another tire on the fire that is the modern web.

"ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?

JavaScript is the programming language for the Web. WGSL syntax should have been based on JavaScript syntax. It would have made writing shaders easier for millions of existing Web developers. Now they have to learn a new syntax.

Re: Chrome ships WebGPU

#224

Post by debacle »

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.

Re: Chrome ships WebGPU

#225

Post by shadowgovt »

illiarian wrote: post #178
codedokode wrote: post #136

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

Just put WebGL/WebGPU behind permission and the problem is solved. Just put WebUSB behind permission and the problem is solved. Just put WebHID behind permission and the problem is solved. Just put WebMIDI behind permission and the problem is solved. Just put Filesystem Access behind permission and the problem is solved. Just put Sensors behind permission and the problem is solved. Just put Location behind permission…

Everything except WebGL and WebGPU allows the system to change more state than what is rendered on a screen.

Users already expect browsers to change screen contents. That's why WebGPU / WebGL aren't behind a permission block (any moreso than "show images" should be... Hey, remember back in the day when that was a thing?).

Re: Chrome ships WebGPU

#226

Post by brrrrrm »

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…

> WebGPU ML runtime

oh cool! will this be numpy-like or will it have autograd as well? We're looking around for a web backend for shumai[1] and the former is really all we need :)

[1]: https://github.com/facebookresearch/shumai

Re: Chrome ships WebGPU

#227

Post by codedokode »

kevingadd wrote: post #188
codedokode wrote: post #136

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

Saturating the user with permissions requests for every single website they visit is a dead-end idea. We have decades of browser development and UI design history to show that if you saturate the user with nag prompts that don't mean anything to them, they will just mechanically click yes or no (whichever option makes the website work).

Permission popups can be replaced with an additional permission toolbar or with a button in the address bar user needs to click. This way they won't be annoying and won't require a click to dismiss.

Re: Chrome ships WebGPU

#228

Post by foldr »

illiarian wrote: post #183
foldr wrote: post #118

Earlier quoted context omitted.

Then why does Chrome contain loads of features to make fingerprinting harder?

Chrome has to walk a fine line between what it does for privacy and what is says it does. So you have the protection against fingerprinting and at the same time you have the FLoC fiasco

The simplest explanation is that the Chrome developers genuinely want to protect privacy and also genuinely want to add features. Every browser has to make that trade off. There are plenty of fingerprinting vulnerabilities in Firefox and Safari too.

The reasoning here seems to be something like "Google is evil; X is an evil reason for doing Y; therefore Google must have done Y because of X". It's not a great argument.

Re: Chrome ships WebGPU

#229

Post by brookst »

shadowgovt wrote: post #220
dist-epoch wrote: post #141

Earlier quoted context omitted.

Think about bindless as raw pointers vs handles. In bindless (pointers) you say "at this GPU memory location I have a texture with this params". In non-bindless you say "API create a texture with these params and give me a handle I will later use to access it". Bindless gives you more flexibility, but it's also harder to use since it's now your responsability to make sure those pointers point at the right stuff.

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.

Re: Chrome ships WebGPU

#230

Post by Timja »

littlestymaar wrote: post #116
Timja wrote: post #90

Earlier quoted context omitted.

Not sure if the workload makes a difference. We would have to make examples of what Computation1 is and what Computation2 is to make a prediction if certain types of workloads will impact the ratio of their performance. Example: s=performance.now(); r=0; for (i=0; i For me, the ratio is consistently larger in Chrome than in Firefox. Which workload would reverse that?

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 reliably when measuring it 10 times.

Post reply on HN