Live data from Hacker News

WebGPU Fundamentals

webgpufundamentals.org

121–130 of 211 posts

Re: WebGPU Fundamentals

#121
post #116
post #101

This looks heavily geared towards graphics. I’m interested in the compute capabilities of WebGPU to build an in-browser simulator (e.g. physics/quantum). Anyone know of any good resources for that? (Samples, best practices, etc.)

This is usually done with shaders and a circle of buffers which maintain state.

Total graphics / shaders / GPU noob here. Does that mean you'll essentially get free visualisations (albeit non-sensical ones) as a byproduct of your computations?

Re: WebGPU Fundamentals

#122
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

> Because after seeing WebUSB and WebGPU I think my personal limit has been reached. Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached. Multiply this by every vendor, developer and u…

Tangentially in the WebMIDI topic, I wonder how DAWs will react with things going to browser and generative audio scaling quickly.

Re: WebGPU Fundamentals

#123
post #85

Earlier quoted context omitted.

I want to be able to interact with synths over MIDI in the browser Help me understand why this is. Is it because there aren't native programs for the platform you're using? Is it to allow plug-ins or other abilities that wouldn't otherwise be available? Is it so that you can sync up with other musicians and play together in a way that wouldn't be possible without a browser? choose a browser that doesn't implement tho…

Because it's really cool to try out experimental instruments other poeple have made by simply opening a webpage, without having to execute untrusted native code that could have bad consequences.

Instead, you're executing untrusted browser code, which is hardly better.

Re: WebGPU Fundamentals

#124

Earlier quoted context omitted.

Browsers are just “standardised” OS at this point. Really, what is the difference? It seems to me that people basically wants a 1 to 1 mapping between every OS feature to browsers. I wouldn’t be surprised if this standard will fall apart in the next decade once Chrome runs everything. That is to say Chrome is the standard. I am already seeing websites drop support for Firefox and won’t even load using it.

> I am already seeing websites drop support for Firefox Examples?

Firefox has a better plugin ecosystem, and it's plugins that cause a lot of site issues.

It's a very clear trade-off in the hands of the user, which is correct.

Re: WebGPU Fundamentals

#125
post #101

This looks heavily geared towards graphics. I’m interested in the compute capabilities of WebGPU to build an in-browser simulator (e.g. physics/quantum). Anyone know of any good resources for that? (Samples, best practices, etc.)

I think Steven Wittens’s work at acko.net and https://usegpu.live/ is your best bet here. I’ve been working for a couple of years on building a computer algebra / physics system in Clojure and integrating it with Steven’s previous work on MathBox, with some in-progress demos like this:

https://emmy-viewers.mentat.org/dev/examples/simulation/quar...

https://emmy-viewers.mentat.org/dev/examples/simulation/toro...

Use.GPU looks like it will be close to a drop-in replacement for MathBox, running on WebGPU. Maybe someday I’ll actually be able to build my general relativistic ray tracer, with explorable symbolic physics all the day down…

Re: WebGPU Fundamentals

#126
post #119

Earlier quoted context omitted.

No, distributed training is one of these holy grails nobody has quite figured out yet. You can split training across multiple GPUs in the same computer, or multiple computers in close proximity connected by infiniband, but that's about as much latency as we can handle right now. We need some breakthrough to make it possible for internet-connected computers to usefully collaborate. If it did work we wouldn't be waitin…

Pardon my naivety. The only reason individuals would willingly participate at a large scale, would be for an open source AI project. Does that mean once the problem is solved, everybody will likely be able to run their own state of the art AI, or are the real-time calculations too intensive for a single server?

As a reference point, the large version of facebook's LLaMA was originally designed to be run on 4 server-grade GPUs, but after it was leaked people managed to make it run on a normal computer with just a CPU and 40GB RAM or so, though it's somewhat slow when running that way. GPT 3 is about 3 times larger than that. But at least for LLMs we have mostly explored how to either make really big models with the best capabilities (OpenAI etc) or models that are faster to train for comparable capabilities (facebook etc). There's comparative little work done so far on models that are able to run with the least amount of resources possible, though there are indications that you can invest more resources in training to get models that are much easier to run (training a small model for really long to get the same capabilities as a larger model). That might be a great route for an open source project, spending great combined effort to make something everyone can more easily run at home.

Of course that's mostly LLMs, for image generation you can easily run Stable Diffusion on any somewhat decent GPU, and being able to collaboratively train better models might be a huge boon there too.

Re: WebGPU Fundamentals

#128
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

> Because after seeing WebUSB and WebGPU I think my personal limit has been reached. Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached. Multiply this by every vendor, developer and u…

I'm not going to argue against these features, but I find that last argument you raise to be a rather dull and useless one. Yeah, I'll just go ahead and pick from one of the hundreds of competing implementations to find one that doesn't. Oh, wait, they don't exist.

It's like saying "if you don't like the laws(/taxes/whatever) where you live, go somewhere else" and acting as if I can just hop on over to Mars. I can't.

Re: WebGPU Fundamentals

#129
post #94

Earlier quoted context omitted.

AKA laziness. yes, lets please bloat of the scope of browsers until they are no longer recognizable, so that you dont have to install some software.

You oversaw the untrusted part, this is the only reason I prefer web over native really. If there was a way to run native apps with that level of isolation, I would prefer native.

Snap, Flatpack, iOS sandbox, Android sandbox, UWP/Windows sandbox,...

Re: WebGPU Fundamentals

#130
post #116

Earlier quoted context omitted.

This is usually done with shaders and a circle of buffers which maintain state.

Total graphics / shaders / GPU noob here. Does that mean you'll essentially get free visualisations (albeit non-sensical ones) as a byproduct of your computations?

I think it depends, but given an arbitrary compute pipeline, you should be able to write the results (or intermediary results) to the screen with minimal effort.
Post reply on HN