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

251–260 of 405 posts

Re: Chrome ships WebGPU

#251

Post by lima »

pier25 wrote: post #232
lima wrote: post #221

Earlier quoted context omitted.

> Just think how many JS kBs and CPU cycles would be saved globally if browsers could do data binding and mutate the dom (eg: morhpdom, vdom, etc) natively. And the emissions that come with it. Browsers are solving these real-world problems. With modern JS engines, frameworks are nearly as efficient as a native implementation would be. And with web components, shadow DOM and template literals, all you need is a very…

> frameworks are nearly as efficient as a native implementation would be I have a very hard believing that a C++ implementation of eg a VDOM would not be significantly more efficient than a JS one. I'm just doing some benchmarks and even the fastest solutions like Inferno get seriously bottlenecked after trying to mutate about 2000 DOM elements per frame. And even if the performance was similar, what about the downlo…

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-react-vs-lit-element-re...

Re: Chrome ships WebGPU

#252

Post by mastax »

codedokode wrote: post #168
azangru wrote: post #162

Earlier quoted context omitted.

Who decides what's unnecessary?

Everything that can be used for fingerprinting should be behind a permission. Almost all sites I use (like Google, Hacker News or Youtube) need none of those technologies.

So CSS should be behind a permission?

Re: Chrome ships WebGPU

#253

Post by dcow »

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…

Honestly I wish we just had a good fingerprinting API that people could opt in to so that we didn't poison all these other good use cases with cringy “it’s gotta be anonymous so I can troll” requirements.

Re: Chrome ships WebGPU

#255

Post by MuffinFlavored »

korijn wrote: post #213
MuffinFlavored wrote: post #191

Earlier quoted context omitted.

what would it take to python -> wasm -> webgpu for the entire existing webgpu ecosystem (all of the libraries around neural networks, torch, yada yada)

FYI you can already use webgpu directly in python, see https://github.com/pygfx/wgpu-py for webgpu wrappers and https://github.com/pygfx/pygfx for a more high level graphics library

I think I meant to ask "how is machine learning support for things like neural networks instead of graphical 2D/3D operations with WebGPU"?

Re: Chrome ships WebGPU

#256

Post by jayd16 »

flohofwoe wrote: post #132
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 on…

Can you explain what the split is supposed to be? I'm fairly confused because mobile GPUs (tile based) are creeping into the desktop space. The Apple Silicon macs are closer to tile based mobile GPUs than traditional cards.

What APIs are supposed to be separate, why, and what side of the fence is the M1 supposed to land on?

Re: Chrome ships WebGPU

#257

Post by jayd16 »

miohtama wrote: post #163
flohofwoe wrote: post #132

Earlier quoted context omitted.

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

I think it unrealistic management of expectations that desktop and mobile must or should be equal. There is plenty of web applications use cases one would like to run on a desktop, but they are irrelevant for mobile, for many other reasons as well. E.g. think editing spreadsheets.

This is an odd analogy. We should reduce the API space for mobile so devs don't make mobile spreadsheets? I mean...what is this arguing exactly? UX is different, sure, but how does that translate into something this low level?

Re: Chrome ships WebGPU

#259

Post by flohofwoe »

jayd16 wrote: post #256
flohofwoe wrote: post #132

Earlier quoted context omitted.

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

Can you explain what the split is supposed to be? I'm fairly confused because mobile GPUs (tile based) are creeping into the desktop space. The Apple Silicon macs are closer to tile based mobile GPUs than traditional cards. What APIs are supposed to be separate, why, and what side of the fence is the M1 supposed to land on?

These are good posts to answer your question I think:

- https://www.yosoygames.com.ar/wp/2023/04/vulkan-why-faq/

- https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are...

In places where Vulkan feels unnecessarily restrictive, the reason is mostly some specific mobile GPU vendor which has some random restrictions baked into their hardware architecture.

AFAIK it's mostly not about tiled renderers but about resource binding and shader compilation (e.g. shader compilation may produce different outputs based on some render states, and the details differ between GPU vendors, or bound resources may have all sorts of restrictions, like alignment, max size or how shader code can access them).

Apple's mobile GPUs are pretty much top of the crop and mostly don't suffer from those restrictions (and any remaining restrictions are part of the Metal programming model anyway, but even on Metal there are quite a few differences between iOS and macOS, which even carried over to ARM Macs - although I don't know if these are just backward compatibility requirements to make code written for Intel Macs also work on ARM Macs).

It's mostly on Android where all the problems lurk though.

Re: Chrome ships WebGPU

#260

Post by dagmx »

marktangotango wrote: post #212
teruakohatu wrote: post #2

In case you confused this with webgl as I did: > WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU.

So someone can put javascript in a page to compute equihash, autolykos, cuckoo cycle, etc? Is there a way to limit this?

They could already do that though?
Post reply on HN