Chrome ships WebGPU • Hacker News Board

Re: Chrome ships WebGPU

#41

Post by illiarian » Thu, Apr 06, 2023, 9:27 AM UTC

sebzim4500 wrote: post #33

phh wrote: post #20

Earlier quoted context omitted.

Someone mean would say that this is not a bug, but a feature for the people who are paying for Chrome.

Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. To the contrary, it decreases the value of their browser monopoly.

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

Re: Chrome ships WebGPU

#42

Post by pzo » Thu, Apr 06, 2023, 9:27 AM UTC

senttoschool wrote: post #8

It's good to know that Apple, MS, Firefox, and Google are all onboard. It's great that browsers are finally taking advantage of the underlying hardware. Next up for browsers should be NPUs such as Apple's neural engine.

There is already spec in the making: WebNN [1]. Will be interesting to see if Apple will be on board or not.

[1] https://webmachinelearning.github.io/webnn-intro/

Re: Chrome ships WebGPU

#43

Post by codewiz » Thu, Apr 06, 2023, 9:27 AM UTC

"This initial release of WebGPU is available on ChromeOS, macOS, and Windows."

Not yet available on Linux, perhaps because the Vulkan backend can't be enabled yet: https://bugs.chromium.org/p/dawn/issues/detail?id=1593

Re: Chrome ships WebGPU

#44

Post by selectnull » Thu, Apr 06, 2023, 9:28 AM UTC

d--b wrote: post #32

Chrome _will_ ship WebGPU in the next update... Current is 112, WebGPU is 113. Seriously google, can't you just wait until you actually ship the stuff before you say you shipped it...

Even worse: "This initial release of WebGPU is available on ChromeOS, macOS, and Windows. Support for other platforms is coming later this year."

I guess Linux support will come right after they ship Google Drive client.

Re: Chrome ships WebGPU

#45

Post by sebzim4500 » Thu, Apr 06, 2023, 9:28 AM UTC

BulgarianIdiot wrote: post #3

Now I want to see someone figure out a way to performantly distribute a trillion parameter model on a million smartphones looking at a web page.

The bandwidth would end up costing way more than the compute would.

Re: Chrome ships WebGPU

#46

Post by tormeh » Thu, Apr 06, 2023, 9:29 AM UTC

pl90087 wrote: post #22

mike_hock wrote: post #9

Earlier quoted context omitted.

And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?

I wish all information-leaky browser features were turned off by default and I could easily turn them on on demand when needed. Like, the browser could detect that a webpage accesses one of them and tells me that I am currently experiencing a degraded experience which I could improve by turning this slider on.

I believe the LibreWolf browser does this. It's basically Firefox with all the fingerprintable features turned off.

Re: Chrome ships WebGPU

#47

Post by pjc50 » Thu, Apr 06, 2023, 9:31 AM UTC

nextaccountic wrote: post #35

mike_hock wrote: post #9

Earlier quoted context omitted.

And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?

> all the operations are specified to deterministically produce the same bit-exact results on all hardware, I want this so badly. A compiler flag perhaps, that enables running the same program with the exact output bit for bit on any platform, perhaps by doing the same thing as a reference platform (any will do), even if it has a performance penalty.

I'm surprised people accept non-bit-identical output. Intel did a lot of damage here with their wacky 80-bit floating point implementation, but really it should be the norm for all languages.

Re: Chrome ships WebGPU

#48

Post by nailer » Thu, Apr 06, 2023, 9:32 AM UTC

TheAceOfHearts wrote: post #4

Can this be used to mine cryptocoins by malicious actors?

Yes but keep in mind that most of all the active chains are using proof of stake now.

Re: Chrome ships WebGPU

#49

Post by adrian17 » Thu, Apr 06, 2023, 9:33 AM UTC

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?

> What don't you like about it?

AFAIK: It's a mostly-but-not-100% textual equivalent of SPIR-V that, syntax-wise, is a weird hodgepodge of all the other shader languages. At the same time, it's rare it'll be actually written by hand by humans - it'll mostly be generated from another language at application build time, and then it'll have to be compiled back into bytecode by the browser, which feels like really redundant work.

Further, it's often said that the main reason the language exists in the first place is because Apple veto'd SPIR-V due to their legal disputes with Khronos. I'm assuming that's why the comment above called it "ad-hoc".

Re: Chrome ships WebGPU

#50

Post by ianpurton » Thu, Apr 06, 2023, 9:33 AM UTC

Is it practical to run machine learning algorithms in parallel with this?

I could imagine people loading a webpage to take part in a massive open source training exercise by donating their Gpu time.