Live data from Hacker News

Chrome ships WebGPU

developer.chrome.com

321–330 of 405 posts

Re: Chrome ships WebGPU

#321

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…

I guess all the AI type use cases are front seat here but the performance boost increase to Immersive Web (WebXR) and general moves towards webpages as 3D UI/UX for applications -- that is where I hope to see expansion into new creative territory.

Re: Chrome ships WebGPU

#322
post #260

Earlier quoted context omitted.

They could already do that though?

But not using the client side gpu!

I believe webGL "cryptojacking" as it's called, indeed is a thing. Not sure on prevalence though or to what extent this introduction makes it more viable for malicious actors.

I'm not sure if lots of hashing algos are gpu-ready or optimized either.

Re: Chrome ships WebGPU

#323

Earlier quoted context omitted.

Hi Tommy! I sent you an email a few weeks back - would be great to chat! WONNX is a seriously impressive project. There is a few reason I didn't just contribute back to WONNX: 1. WONNX does not parse the ONNX model into an IR, which I think is essential to have the freedom to transform the model as required. 2. When I started, WONNX didn't seem focused on symbolic dimensions (but I've seen you shipping the shape infe…

I'm presently working on enhancing Burn's ( https://burn-rs.github.io/ ) capabilities by implementing ONNX model importation ( https://github.com/burn-rs/burn/issues/204 ). This will enable users to generate model source code during build time and load weights at runtime. In my opinion, ONNX is more complex than necessary. Therefore, I opted to convert it to an intermediate representation (IR) first, which is then us…

Actually WONNX also transforms to an IR first (early versions did not and simply translated the graph 1:1 to GPU shader invocations in topographically sorted order of the graph). In WONNX the IR nodes are (initially) simply (copy-on-write references to) the ONNX nodes. This IR is then optimized in various ways, including the fusion of ONNX ops (e.g. Conv+ReLU->ConvReLU). The newly inserted node still embeds an ONNX node structure to describe it but uses an internal operator.

Re: Chrome ships WebGPU

#324

Earlier quoted context omitted.

I'm presently working on enhancing Burn's ( https://burn-rs.github.io/ ) capabilities by implementing ONNX model importation ( https://github.com/burn-rs/burn/issues/204 ). This will enable users to generate model source code during build time and load weights at runtime. In my opinion, ONNX is more complex than necessary. Therefore, I opted to convert it to an intermediate representation (IR) first, which is then us…

Looks great! ONNX is 100% more complex than necessary. Another format of interest is NNEF: https://www.khronos.org/nnef

Also see the recently introduced StableHLO and its serialization format: https://github.com/openxla/stablehlo/blob/main/docs/bytecode...

Re: Chrome ships WebGPU

#325

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.

Something more than 30 years ago, I had the privilege of working as a young compiler writer for [a supercomputer designer]'s penultimate start-up. I once naively asked him why the machine he was working on couldn't have more memory bandwidth, since the floating-point functional units were sometimes starved for operand data and it was hard to hit the peak Flop/sec figures. And his response has stuck with me ever since; basically, it makes better sense for the memory to be fully utilized, not the floating-point units, because the memory paths were way more expensive than the floating-point units. And this was something you could actually physically see through the transparent top of the system's case. I guess the lesson would be: Don't let a constraint that would be fairly cheap to overdesign be the limiting factor in a system's performance.

Re: Chrome ships WebGPU

#326

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 use level of detail structures, like google earth does.

Re: Chrome ships WebGPU

#327
post #87

Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?

One reason is that WebGL isn't a 2010s technology, but more of a 2005 technology (it doesn't even have compute shaders). WebGPU will finally bring the Web to the state of 2010.

Re: Chrome ships WebGPU

#328

Earlier quoted context omitted.

I think browsers should distinguish more aggressively between "web application", "web site", and "user hostile web site". Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no". Collect opt-in telemetry. We…

Clearly if we knew how to perfectly identify user hostile websites we'd not need permissions dialogs at all. Distinguishing between site and app, e.g. via an installation process, is equivalent to a permissions dialog, except that you're now advocating for one giant permission dialog instead of fine-grained ones, which seems like a step backwards.

Yes, if we knew how to do it perfectly, we wouldn't need them. But we can identify some known-good and known-bad cases with high confidence. My proposal mainly addresses the "fatigue" aspect: it allows apps to use some of the more powerful features without letting every web site use them, and it prevents random web sites from declaring themselves an app and spamming users with the permission request just so they can abuse the users more.

The new permission dialog wouldn't grant all of the finer-grained permissions - it would be a prerequisite to requesting them in the first place.

Re: Chrome ships WebGPU

#329
This is an exciting day! I have been dreaming about WebGPU to ship in Chrome/Edge for as long as I can remember.

Now hoping Safari won’t take another decade to ship proper support…because until then there is only very limited use cases :(

Re: Chrome ships WebGPU

#330
post #30

Earlier quoted context omitted.

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.

They probably can understand these concepts, but privacy and anonymity are not their main priorities.
Post reply on HN