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

351–360 of 405 posts

Re: Chrome ships WebGPU

#351

Post by johnfn »

slimsag wrote: post #151

This is very welcome and a long time coming! If you're eager to learn WebGPU, consider checking out Mach[0] which lets you develop with it natively using Zig today very easily. We aim to be a competitor-in-spirit to Unity/Unreal/Godot, but extremely modular. As part of that we have Mach core which just provides Window+Input+WebGPU and some ~19 standalone WebGPU examples[1]. Currently we only support native desktop pl…

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!

Re: Chrome ships WebGPU

#352

Post by epolanski »

pier25 wrote: post #281
lima wrote: post #251

Earlier quoted context omitted.

VDOMs were created precisely because the native DOM was too slow. This is no longer the case and a tiny web component framework like Lit significantly outperforms[1] React relying entirely on the browser DOM and template literals for re-rendering... so what you're asking for, has already happened :-) But even the big frameworks are really fast thanks to modern JIT JS engines. [1]: https://www.thisdot.co/blog/showcase…

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

Re: Chrome ships WebGPU

#353

Post by winter_blue »

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…

Does the Rust compile to WebAssembly? I’m guessing that means WebGPU is fully accessible from WebAssembly, and one can go a zero JS route?

Re: Chrome ships WebGPU

#354

Post by simlevesque »

phendrenad2 wrote: post #350

Maybe I'm dumb but what does WebGPU get you in reality that WebGL doesn't currently get you? I don't think we're going to see browser games any time soon (because it's trivial to just install a game and run it, and also the browser audio API sucks). And most visualizations on the web would be perfectly fine with plain old WebGL.

> And most visualizations on the web would be perfectly fine with plain old WebGL.

It's not made to make visualizations that weren't possible before, this explains that.

Re: Chrome ships WebGPU

#355

Post by lightbendover »

johnfn wrote: post #351
slimsag wrote: post #151

This is very welcome and a long time coming! If you're eager to learn WebGPU, consider checking out Mach[0] which lets you develop with it natively using Zig today very easily. We aim to be a competitor-in-spirit to Unity/Unreal/Godot, but extremely modular. As part of that we have Mach core which just provides Window+Input+WebGPU and some ~19 standalone WebGPU examples[1]. Currently we only support native desktop pl…

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.

Re: Chrome ships WebGPU

#356

Post by kllrnohj »

tormeh wrote: post #335
kllrnohj wrote: post #240

Earlier quoted context omitted.

Vulkan & GLES are both the obvious competition here, I don't know why you seem to be ignoring them?

Vulkan doesn't run on Apple platforms. And Apple refuses to upgrade their OpenGL drivers. So no, they don't count. Then there are the consoles, which also have their own APIs. Expecting all vendors to implement a common API is a fool's errand, and we should stop trying. The vendors don't want this, and we can't force them. Any common GPU API must be an abstraction over vendor-specific ones.

MoltenVK exists and runs Vulkan on Apple devices perfectly fine. Almost certainly better than WebGPU does even. Vulkan is already a common API both in theory and in practice.

It's not a nice API, but it is common and vendor neutral all the same. A lot moreso than WebGPU is, even, since Khronos has a much more diverse set of inputs than the web does. See eg all the complaints about Chrome dominating the web discussion, and even beyond that you only really need 3 companies on board. Khronos has significantly more at the table than that.

Re: Chrome ships WebGPU

#357

Post by mlsu »

johnfn wrote: post #351
slimsag wrote: post #151

This is very welcome and a long time coming! If you're eager to learn WebGPU, consider checking out Mach[0] which lets you develop with it natively using Zig today very easily. We aim to be a competitor-in-spirit to Unity/Unreal/Godot, but extremely modular. As part of that we have Mach core which just provides Window+Input+WebGPU and some ~19 standalone WebGPU examples[1]. Currently we only support native desktop pl…

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!

I appreciate the candor of this article. And I'm not making any judgements.

But that calendar. That calendar is wild.

Re: Chrome ships WebGPU

#358

Post by mattdesl »

phendrenad2 wrote: post #350

Maybe I'm dumb but what does WebGPU get you in reality that WebGL doesn't currently get you? I don't think we're going to see browser games any time soon (because it's trivial to just install a game and run it, and also the browser audio API sucks). And most visualizations on the web would be perfectly fine with plain old WebGL.

Basically, an improved API that targets a more modern graphics pipeline and has better support outside of browsers. You can write a graphics engine or custom renderer in Rust and have it ship across desktop and web. See Vello for example:

https://github.com/linebender/vello

Re: Chrome ships WebGPU

#359

Post by acchow »

codedokode wrote: post #136
Timja wrote: 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.

"Be kind. Don't be snarky. Converse curiously. Please don't sneer"

HN Guidelines

https://news.ycombinator.com/newsguidelines.html

Post reply on HN