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

131–140 of 405 posts

Re: Chrome ships WebGPU

#131

Post by singularity2001 »

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

Re: Chrome ships WebGPU

#132

Post by flohofwoe »

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…

Aras is right, but the elephant in the room is still shitty mobile GPUs.

Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and one that's pretty decent (but only works on desktop GPUs).

WebGPU cannot afford such a split. It must work equally well on desktop and mobile from the same code base (with mobile being actually much more important than desktop).

Re: Chrome ships WebGPU

#135

Post by FL33TW00D »

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/1638469392794091520)

That said, matmuls are still pretty handicapped in the browser (especially considering the bounds checking enforced in the browser). From my benchmarking I've struggled to hit 50% of theoretical FLOPS, which is cut down to 30% when the bounds checking comes in. (Benchmarks here: https://github.com/FL33TW00D/wgpu-mm)

I look forward to accessing shader cores as they mentioned in the post.

Re: Chrome ships WebGPU

#136

Post by codedokode »

Timja wrote: post #30
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?

There is no way to escape fingerprinting. Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this: computation 1: ** computation 2: **** computation 3: ********** computation 4: ** computation 5: ************** computation 6: ************ computation 7: ********* etc…

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.

Re: Chrome ships WebGPU

#137

Post by hexo »

fulafel wrote: post #128
foldr wrote: post #123

Earlier quoted context omitted.

I'm not sure what you mean. All you need to do is this: function computation() { ... } before = performance.now(); computation(); t = performance.now() - before; (Obviously there will be noise, and you need to average a bunch of runs to get reliable results.)

In this case the runtime would not be able to guarantee that the timing has no externally observable side effects (at least if you do something with t). It would then run in the fixed execution speed mode.

Runtime doesnt have full controll but could introduce a lot of noise in timing and performance. Could it help?

Re: Chrome ships WebGPU

#138

Post by singularity2001 »

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…

How would WebGL matmul fare in comparison?

Re: Chrome ships WebGPU

#140

Post by codedokode »

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 fingerprinting vs number of uses for communication).

Post reply on HN