211–220 of 405 posts
And just 2 weeks ago I launched this WebGPU features and limits tracking website: https://web3dsurvey.com It is modelled after the long defunct webglstats website.
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.
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…
what would it take to python -> wasm -> webgpu for the entire existing webgpu ecosystem (all of the libraries around neural networks, torch, yada yada)
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…
How so?
I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?
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…
> But closer inspection showed that its use was to get user's IP address for better fingerprinting. Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]). [1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(
Would you mind elaborating? In any case WebRTC always needed some kind of third party server to connect the peers together (sure, such a server can be on your local network), and then they replaced the local IP in ICE candidate with mDNS addresses which serve the same purpose and allow for direct P2P communication between the two peers without going through the internet.
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.
Edit:
For example, just consider how many billions of users are downloading and executing JS implementations of a VDOM every single day.
Don't get me wrong, this is supremely cool... but I wish the W3C and browsers solved more real world problems. 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. Edit: For example, just consider how many billions of users are downloading and executing JS implementations of a VD…
Accessing the GPU in this way is something that can't be done without browser-level API support. You're describing a problem already solved in JS. Different category entirely.
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…
> with mobile being actually much more important than desktop How so? I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?
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…
Think about bindless as raw pointers vs handles. In bindless (pointers) you say "at this GPU memory location I have a texture with this params". In non-bindless you say "API create a texture with these params and give me a handle I will later use to access it". Bindless gives you more flexibility, but it's also harder to use since it's now your responsability to make sure those pointers point at the right stuff.
If so, that'd be a non-starter for a web API. Web APIs have to be, first and foremost, secure and protect the user's anonymity.