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

311–320 of 405 posts

Re: Chrome ships WebGPU

#311

Post by sfink »

isodev wrote: post #149
codedokode wrote: post #140

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…

And if the Chrome team is excited about a feature, then probably it’s good for ads or upselling other Google products.

That's an odd take.

Last I knew, the Chrome team was made out of people. If the people working on a new technology are excited about that technology, it probably means that they are excited about that technology. It doesn't say much about how excited the ad people may or may not be about it, other than indirectly by knowing that the technology people are allowed to spend time on it.

That is the link I believe you're referring to, but my guess is that it's going to be fairly tenuous. The set of things that the technology people get to work on probably has more to do with the set of things that they try to persuade the powers that be are important, and that set is more likely to be driven by their own interests and visions of what could and should be done on the web, than it is to be driven by what will make their paymasters happiest.

Sorry, I'm sure there is a much more brief way to say that.

(nb: I work for Mozilla)

Re: Chrome ships WebGPU

#312

Post by cyral »

topaz0 wrote: post #282
cyral wrote: post #272

Earlier quoted context omitted.

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

If whatever compute intensive feature they come up with wasn't possible on the CPU, I highly doubt it is a bloated useless feature they are adding just for the heck of it.

Re: Chrome ships WebGPU

#313

Post by nailer »

jefftk wrote: post #147
nailer wrote: post #48

Earlier quoted context omitted.

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

What matters is the ROI, not what fraction of active chains use what tech, no?

That's true. But active chains tend to be higher value and Bitcoin mining rewards have halved a few times over the last few years or so.

Re: Chrome ships WebGPU

#314

Post by antimora »

FL33TW00D wrote: post #309
misterdata wrote: post #160

Earlier quoted context omitted.

Looking forward to your WebGPU ML runtime! Also, why not contribute back to WONNX? ( https://github.com/webonnx/wonnx )

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 used to generate source code. A key advantage of this approach is the ease of merging nodes into corresponding operations, since ONNX and Burn don't share the same set of operators.

Re: Chrome ships WebGPU

#315

Post by FL33TW00D »

antimora wrote: post #314
FL33TW00D wrote: post #309

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…

Looks great!

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

Re: Chrome ships WebGPU

#318

Post by adam_arthur »

mike_hearn wrote: post #97
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.

"Webgpu solves the incentives problem where all actors tries to lock you in" Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blockin…

You could say the same about working off a common html, browser, language spec. There are tradeoffs, but industry consensus hasn't really stifled innovation in a meaningful way.

Why can't a common graphics API evolve through well researched and heavily scrutinized proposals? The amount of societal loss of efficiency in having competing specs that do the same thing in slightly different ways, but require immense effort to bridge between is truly vast.

The incentive to innovate comes from limitations with the current spec. That doesn't change just because there's consensus on a common base spec

Post reply on HN