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

381–390 of 405 posts

Re: Chrome ships WebGPU

#381

Post by lima »

epolanski wrote: post #352
pier25 wrote: post #281

Earlier quoted context omitted.

Yes, I know Lit exists, and yes it's fast. But I think you're missing the point. I'm not talking about one JS implementation vs another or if JS solutions are fast enough from the end user perspective. The fastest JS solution (VDOM, Svelte, Lit, whatever) will still be bottlenecked by the browser. If JS could send a single function call to mutate/morph a chunk of the DOM, and that was solved natively, we'd see massiv…

But Dom manipulation happens in the browser and is implemented in c++.

Right. Something like lit-html simply re-renders the DOM. This is essentially as efficient as it gets.

Re: Chrome ships WebGPU

#383

Post by nextaccountic »

dahart wrote: post #261
pjc50 wrote: post #108

Earlier quoted context omitted.

It's very hard to do tests of the form assert(result == expected) if they're not identical every time. And it can waste a horrendous amount of time if something is non-bit-identical only on a customer machine and not when you try to reproduce it ...

Trying to reproduce is a good point, but at the same time it’s usually a pretty bad idea to do tests of the form assert(result == expected) with a floating point result though. You’re just asking for trouble in all but the simplest of cases. Tests with floating point should typically allow for LSB rounding differences, or use an epsilon or explicit tolerance knob. There’s absolutely no guarantee that a computation wi…

> Order of operations matters, therefore valid code optimizations can change your results.

This is exactly why optimizations that change the order of operations of floating points aren't valid! And many other optimizations, like (I learned this just recently) transforming x + 0.0 into x: those are not the same thing when x is -0.0. In other news, -ffast-math produces broken code.

Current programming languages enable writing 100% deterministic floating point code just fine (even with compiler optimizations, as long as they are not buggy). The trouble is writing cross-platform deterministic floating point code, that works the same in every machine, but with great care it still can be done, as in https://rapier.rs/docs/user_guides/rust/determinism/ (well this project does this for every platform that supports IEEE 754-2008)

Re: Chrome ships WebGPU

#384

Post by abliefern »

pjmlp wrote: post #366
pdpi wrote: post #241

Earlier quoted context omitted.

We live in a bubble where we don't notice it, but desktop as a platform is... not dying exactly, but maybe returning to 90s levels of popularity. Common enough, but something tech-minded people use, and not necessarily for everybody. Mobile is rapidly becoming the ubiquitous computing paradigm we all thought desktop computers would be. In that world, WebGPU is much more important on mobile than on desktop.

Desktop is pretty much alive, it is called laptops. My Thinkpad P80 + docking station doesn't own anything to classical desktops.

Many, many more people own smartphones than laptops.

Re: Chrome ships WebGPU

#385

Post by pjmlp »

abliefern wrote: post #384
pjmlp wrote: post #366

Earlier quoted context omitted.

Desktop is pretty much alive, it is called laptops. My Thinkpad P80 + docking station doesn't own anything to classical desktops.

Many, many more people own smartphones than laptops.

Most don't work on their smartphones.

Re: Chrome ships WebGPU

#386

Post by pier25 »

epolanski wrote: post #352
pier25 wrote: post #281

Earlier quoted context omitted.

Yes, I know Lit exists, and yes it's fast. But I think you're missing the point. I'm not talking about one JS implementation vs another or if JS solutions are fast enough from the end user perspective. The fastest JS solution (VDOM, Svelte, Lit, whatever) will still be bottlenecked by the browser. If JS could send a single function call to mutate/morph a chunk of the DOM, and that was solved natively, we'd see massiv…

But Dom manipulation happens in the browser and is implemented in c++.

Ultimately, yes. But there's a lot of stuff happening in the JS context too.

Re: Chrome ships WebGPU

#387

Post by dahart »

nextaccountic wrote: post #383
dahart wrote: post #261

Earlier quoted context omitted.

Trying to reproduce is a good point, but at the same time it’s usually a pretty bad idea to do tests of the form assert(result == expected) with a floating point result though. You’re just asking for trouble in all but the simplest of cases. Tests with floating point should typically allow for LSB rounding differences, or use an epsilon or explicit tolerance knob. There’s absolutely no guarantee that a computation wi…

> Order of operations matters, therefore valid code optimizations can change your results. This is exactly why optimizations that change the order of operations of floating points aren't valid! And many other optimizations, like (I learned this just recently) transforming x + 0.0 into x: those are not the same thing when x is -0.0. In other news, -ffast-math produces broken code. Current programming languages enable…

Cross-platform bit-matching determinism is a tradeoff. It’s not a correctness or accuracy issue. It’s one of many goals one might have, and it comes with advantages and disadvantages. Like I pointed out above, you may be trading away higher accuracy in order to achieve cross-platform determinism. You also trade away performance almost certainly.

You say “aren’t valid” and “broken code” as though it’s somehow factual, when in reality you’re making opinionated assumptions about your choice of tradeoff. Those opinions are only true if you assume that only bit-matched results are “valid”. This hyperbolic wording breaks down a little once we start talking about the accuracy of floating point calculations and how bit-matching FP calculations on two different machines is just making two wrong values agree, and there’s nothing “exact” about it.

It is 100% absolutely fine to have bit-matching determinism as a goal, and I’m in favor of compilers supporting it. I’m not suggesting anyone shouldn’t, but I hope you recognize your language is implicitly demanding that everyone must care about floating point determinism just because you do. Some people have serious floating point calculations where they want cross-platform determinism, but -ffast-math exists precisely because many people do not need it, or because they simply prioritize performance over bit-matching, or because they engineered with epsilons instead of unrealistic expectations. There are good reasons why Rapier’s cross platform determinism is not the default, right?

Generally speaking, even the people who have strong reasons to want bit-matching results on different hardware, because they understand the nature of floating point and the reality of the hardware landscape, do not depend on it to be true, they still write their tests using tolerances.

Re: Chrome ships WebGPU

#388

Post by slimsag »

lightbendover wrote: post #355
johnfn wrote: post #351

Earlier quoted context omitted.

The Mach project led me to this, uhm, _interesting_ article: https://devlog.hexops.com/2021/i-write-code-100-hours-a-week... What a maniac!

2 years isn’t long enough to really experience burnout. As soon as rewards slow down, it will seep in if nothing else changes.

Closer to 3.5 years now, maybe I'll do an update at 4 years.

The 2.5 year initial duration (when I posted that article) was like working two full-time jobs, 100h/week, 80% writing code.

Past year has been more like 85h/week, my dayjob has required more time (48h -> ~60h), now with only 30% of that being /writing code/. ~25h/week going to my gamedev passion projects, of which a good chunk has also gone to helping others with their code/issues.

The -15h/week 'loss' has gone to caring for pets, and a gentle touch more travel/sleep/gardening.

Re: Chrome ships WebGPU

#389

Post by hot_gril »

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…

That's fine. They can make the special features for native apps (aka video games) while common things on the web get GPU acceleration. Right now the GPU compatibility situation is pretty bad for the average user despite most of the feature sets being essentially the same.

Re: Chrome ships WebGPU

#390

Post by antimora »

lacker wrote: post #364
antimora wrote: post #302

Earlier quoted context omitted.

Oh great! I am one of the contributors for Burn (Rust Deep Learning Framework). We have a plan adding a WebGPU backend ( https://github.com/burn-rs/burn/issues/243 ). Here is more about the framework Burn: https://burn-rs.github.io/

Burn looks interesting... so I notice in the sample code you mention: use burn_tch::TchBackend; I don't see "TchBackend" mentioned in the docs. Is Tch = torch and Burn can be used as a Torch (or tch-rs) wrapper? Or am I imagining too much from a miscellaneous three letter prefix? I've been looking for a good way to do standard modern AI stuff in Rust, and was leaning towards tch-rs because it exists and seems reasona…

That's right, Tch stands for torch. We use tch-rs (bindings to torch++).

The selling point of burn is that it offers the full level of deep learning framework with ability to swap backends. This is useful, for example, I can train with Torch backend on GPUs but if I want to deploy, lets say to embedded device, I can use NDArray backend, which supports pure rust code (also with various BLAS acceleration if needed). You can also use NDArray backend with Accelerate (iOS or MacOS blass). You can even compile for WASM because Burn supports inference with no_std (you can try this online demo https://burn-rs.github.io/demo).

The framework is well written and follows Rust's conventions and best practices. It's still evolving, however.

Give it a try. If you find problems, you can file a ticket or join discord chat.

Post reply on HN