Use.GPU

https://usegpu.live

by andsoitis • 4 years ago

259 78 4 years ago

usegpu.live

m00dy• 4 years ago

looks like they don't care about compute-pipeline.

iTokio• 4 years ago

They do. A very detailed article was posted not long ago :

https://acko.net/blog/the-gpu-banana-stand/

paulgb2• 4 years ago

Cool, Steven Wittens is behind this. The header at https://acko.net/ is one of the first examples of WebGL I remember seeing in the wild, and still one of the cleanest. Looking forward to seeing where this goes!

kllrnohj2• 4 years ago

The first practical usage of WebGL in the wild I can think of would be Google Maps, although it's easy to forget about the switch from the old server-side tiles to the vector WebGL thingy ( https://www.youtube.com/watch?v=X3EO_zehMkM ).

The still strikes me as one of the very few useful usages of WebGL that exists even today. There's other usages of course, like figma, sketchup, etc... But those rarely (if ever) benefit from the web's primary advantages of ephemeral & linkability, and would work perfectly fine as just classic desktop apps. Kinda like an awful lot of tools in those spaces still are.

Majority usage of webgl still seems to otherwise be ads & shopping. It seems likely that webgpu is going to be much of the same, although it has a chance of graduating out of the web platform as a potentially useful middleware abstraction for native apps that want to use the GPU.

starburst3• 4 years ago

How can you forget about games? The reason GPU exists in the first place.

flyteuk2• 4 years ago

I'm not sure if I'm understanding what you mean about "linkability", but when I'm writing up something on Notion, I'm able to refer to specific elements of a Figma drawing and have the preview rendered right there in Notion. As far as I'm aware, it also updates along with the Figma drawing.

gfxgirl• 4 years ago

meet and other video messaging apps use the GPU to blur or replace your background before streaming you video to their services

JusticeJuice• 4 years ago

Oh man, I remember finding this site years ago, I had completely forgot about it. What a piece of internet nostalgia.

Pulcinella2• 4 years ago

Page doesn’t load on mobile Safari.

Elidrake42• 4 years ago

It's mentioned at the top of the page that WebGPU isn't enabled by default in _any_ browser. The linked^1 caniuse page mentions this as well, while available in Safari, it has to be enabled in the developer config.

[1] https://caniuse.com/webgpu

Pulcinella2• 4 years ago

How was I suppose to see the page saying web GPU isn’t enabled by default if the page itself wasn’t loading?

Seems back up now, might have been HN hug of death.

devmunchies• 4 years ago

you can enable webgpu in your settings > safari under experimental features

planb• 4 years ago

Slightly OT: I never heard of webGPU before. So, in theory it will be feasible in a few years to run models like Stable Diffusion on my GPU through the browser without fighting with conda, pip and drivers? Or did I get the scope of this wrong?

Tade0• 4 years ago

It's a replacement for WebGL, but the key difference is that it supports compute shaders.

boppo1• 4 years ago

Is it a replacement? It looks more like a framework that lives on top of webgl.

irate2942• 4 years ago

WebGL2 also supports them! And now that Apple finally added support (like half a year ago(?)) to it, it can be fairly safely used

unconed6• 4 years ago

It also supports many more features in rendering which previously were unavailable or so badly supported you couldn't use them. It's basically like going from 2005 to 2015 in terms of capabilities.

There are still notable gaps, like no bindless resources or raytracing though. So don't expect e.g. unreal engine to run on WebGPU without some significant compromises.

carpenecopinum• 4 years ago

In principle, yes. With webGPU (but also WebGL2) we get access to compute shaders, which makes it feasible/easier to evaluate a model like Stable Diffusion.

The biggest issue I see is that those models (or rather their trained parameters) are usually pretty large (several GiB). So it'll take a while to set up in the browser before the evaluation can actually start. It'll also require a lot of bandwidth on both ends.

A lot of those things should already be doable with the fragment shaders we get from WebGL and a lot of hackery, like clever (ab)use of textures. So the actual issue that we're not seeing a lot of this is probably not due to it being impossible right now...

capableweb• 4 years ago

The biggest issue I see is that those models (or rather their trained parameters) are usually pretty large (several GiB). So it'll take a while to set up in the browser before the evaluation can actually start. It'll also require a lot of bandwidth on both ends.

Might not be feasible due to memory constraints (I'm not sure), but browsers can load data from disk into memory without having to touch the network. So you could in theory ask the users to download the model separately, then ask them to select it from a file picker, and the browser can have access to it that way.

krona• 4 years ago

WebGL2 doesn't support compute shaders.

modeless4• 4 years ago

You can already run ML models with GPU acceleration in WebGL using tensorflow.js and other libraries. WebGPU will make things better for sure, but I think the major obstacles to running large models like Stable Diffusion will not be solved by WebGPU.

WebGPU will not expose Nvidia-specific tensor cores, at least initially. But the main issues are with loading and processing gigabytes of data in browsers, which aren't addressed by WebGPU at all. You'll have difficulty downloading and storing all that data and quickly run into out of memory crashes.

esperent• 4 years ago

I read through the really long technical article about this from last week and it looks very interesting.

But the proof is in the pudding, as they say, so it's cool to see it's a real product that you can try.

Has anyone taken the time to experiment with this yet? What's your feedback?

amelius2• 4 years ago

I know this is hacker news, but I think the idea of hacking general purpose compute infrastructure on top of graphics/gaming hardware is starting to get out of hand.

When will we flip it around?

nerdponx• 4 years ago

What's wrong with it?

It turns out that graphics hardware is perfect for certain kinds of non-graphical scientific computing. Dedicated GPGPU hardware already exists, but people don't have those at home and/or on their regular computers that they use.

amelius2• 4 years ago

What is wrong with it can be summed up by Henry Ford's quote: “If I would have asked people what they wanted, they would have said faster horses.”

(In this analogy horse=GPU, car/truck=general purpose compute hardware)

pjc50• 4 years ago

How? And who is we? So long as the GPU remains closed and proprietary, we can't port a general purpose OS to it and have it take over the boot.

Cthulhu_2• 4 years ago

When will we flip it around?

Do you mean software rendering? Or more like baking GPUs into CPUs (already done decades ago, see SoC or integrated graphics hardware).

tormeh• 4 years ago

It has already. Chips that are ostensibly for graphics are containing more and more silicon dedicated to general purpose workloads. Turns out doing it like this this is usually cheaper than manufacturing dedicated parallel processors and GPUs separately, since the requirements have so much overlap.

unconed6• 4 years ago

GPUs are already pretty generic. The main diff is that a GPU will execute N threads in lockstep, where N = 32 or 64, like a very wide and always-on SIMD.

The dedicated render pipeline still exists, and is still needed for things like Z buffering and interpolation, but you'd be surprised how much of what used to be fixed hardware is being emulated by the driver.

cal85• 4 years ago

Can't run the demos on my M1 Mac - I can't find the #enable-unsafe-webgpu flag in chrome://flags. Anyone know a workaround? Or is it just not available on Apple Silicon?

Edit: I didn't read it properly - the flag is only available on the Chrome dev channel [0] (and presumably also Canary). The demos work great on my M1 now.

[0] https://www.google.com/chrome/dev/?platform=mac&extra=devcha...

macshome• 4 years ago

Even if I enable WebGPU and change my user agent to Chrome it won't let me through to the demos with Safari.

Some demos I find work and others don't. Assuming that the feature state is still early days on all browsers.

gen_greyface• 4 years ago

i've no clue why, but doesnt work even if i set the flag in config.

firefox dev latest on intel mac.

modeless4• 4 years ago

I think Firefox's WebGPU implementation is a little behind Chromium's at the moment.

jiyinyiyong3• 4 years ago

Chrome Canary only I suppose.

gnarbarian• 4 years ago

I've been waiting for something like this for a long time. I've been using GPU.js and this looks like a huge leap forward. can't wait to dig in!

built_with_flux• 4 years ago

If anyone is looking for something more production ready (that uses webGL), I highly recommend https://github.com/pmndrs/react-three-fiber

we use it to built https://flux.ai

unconed6• 4 years ago

For anyone wondering what the difference is between R3F and Use.GPU:

R3F is a react reconciler for three.js. You manipulate a three.js scene, which the classic non-reactive renderer then draws.

Use.GPU does not have a non-reactive model nor does it have a notion of a scene. Components just compose and expand to produce lambdas which make calls to the GPU.

It's basically React without a DOM, where components can _only_ render other React components.

The docs go into detail of how this is accomplished and what it means.

JoCms22• 4 years ago

My experience is the opposite. I found react-fiber to be a leaky and more importantly unnecessary abstraction. It is very easy to embed https://threejs.org/ in any frontend framework and use it directly without any wrapper.

nextaccountic• 4 years ago

https://usegpu.live/docs/guides-shaders
Use.GPU has a powerful WGSL shader linker. It lets you compose shaders functionally, with closures, using syntactically correct WGSL. It provides a real module system with per-module scope.
The shader linker is very intentionally a stand-alone library, with no dependencies on rest of the run-time. It has minimal API surface and small size.
Every shader is built this way. Unlike most 3D frameworks, there is no difference between built-in shaders and your own. There is no string injection or code hook system, and no privileged code in shader land. Just lots of small shader modules, used à la carte.

I see this project is written in Typescript and Rust, so.. is this shader linker written in Rust?

Could I, in principle, reuse it for running everything in Rust, with no Typescript in the frontend?

What I actually want to do: use this with https://sycamore-rs.netlify.app/

That is,

https://acko.net/blog/the-gpu-banana-stand/
To recap, I built a clone of the core React run-time, called Live, and used it as the basis for a set of declarative and reactive components.

Replace Live with Sycamore

unconed6• 4 years ago

No, the only part that's Rust is the truetype font renderer, which uses ab_glyph. But even the conversion to SDFs is in Typescript.

Moving data in and out of WASM is still kind of slow, relatively speaking (until GC lands), and Rust's ergonomics are not a good fit for the API design which has a ton of optionals.

The shader linker uses a Lezer grammar rather than the official WGSL tree sitter grammar so the AST node structure is more optimized for quick unconditional consumption.

modeless4• 4 years ago

Wow, you have a custom WGSL parser? Very interesting, I may have a use for this...

modeless4• 4 years ago

WebGPU is only available for developers, locked behind a browser flag.

This isn't strictly true. There's an origin trial that enables you to use WebGPU in Chrome stable without flipping any flags, and even ship demos to real users today, on any supported platform. That's currently only Chrome on Windows and macOS, but more platforms are in progress.

markdog122• 4 years ago

Yeah, and it's still behind an explicitly labelled "Unsafe WebGPU" flag. Description has this warning:

Warning: As GPU sandboxing isn't implemented yet for the WebGPU API, it is possible to read GPU data for other processes.

Their own wording says it's unsafe, and possible to read GPU data from other processes, but can run from a site that has the origin trial enabled.

Is that really the case? Or should they change their wording?

drdaeman• 4 years ago

Okay, what are privacy and security implications? If WebGPU goes GA, and a website requests it and gets approved (if it's gonna be behind a permission at all), what it would be able to learn about my machine and what it might be theoretically able to do beyond doing "normal" GPU compute?

sva_• 4 years ago

Seems like my integrated i7 laptop GPU can't run any of these examples due to incomplete Vulkan support for Haswell under Linux. Sad, since I doubt it'll be completed.

Maybe I'll have to retire this almost 10 year old laptop sometime soon, even though it still runs pretty well.

pmarreck• 4 years ago

I run Firefox Nightly and turning on dom.webgpu.enabled didn't enable the demos, even after a browser restart :/ Version is 106.0a1 (2022-09-09) (64-bit), I'm running on NixOS.

"Error: Cannot get WebGPU adapter"

jiyinyiyong3• 4 years ago

it was shown on caniuse.com that Firefox Nightly has optional webgpu support, however it does not run webgpu triangle demos. confused :(

rezmason2• 4 years ago

I've maintained a small WebGPU project for a little while, and haven't had to utilize any solutions like Use.GPU. I'm not here to express an opinion about it, but if you like using WebGL without adding large dependencies to your projects, you can leverage WebGPU the same way, with one important caveat: the packing of structured data into bindings.

In short, if you have a JavaScript object of named values you want to pass into a WGSL shader that has a corresponding binding, you have some homework to do. So I wrote a tiny (work in progress) utility to do it for you.

Just like gl-matrix ( https://glmatrix.net ) is a tiny library that trivializes geometric transforms for small projects, gpu-buffer ( https://github.com/Rezmason/matrix/blob/master/lib/gpu-buffe... ) trivializes passing data into WGSL shaders. You hand it a shader, and it'll return a set of objects that'll transform your JS objects into buffers to then bind.

unconed6• 4 years ago

Note that what Use.GPU does is much more polymorphic than that. It uses getters inside shaders to allow e.g. attributes like point color and size to be either uniform or per vertex, without having to change the shader source.

It will also autogenerate bind groups and descriptors, including optimized support for volatile bindings that e.g. change every frame (like a front/back buffer).

This is necessary if you want to make composable shaders which can adapt to a variety of use cases.

rezmason2• 4 years ago

Thanks for making this, by the way.

I think the design of standard APIs will increasingly cater to engine developers and folks willing to pore over specs, and the folks running smaller scale operations will have a harder time leveraging new things without considerable personal investment— unless folks implement higher level wrapper libraries, that is.

I personally disagree with you on a bunch of things— this is the Internet after all— but you've been undoubtedly empowering graphics programmers for years, and I appreciate you.

IceHegel• 4 years ago

Is the view that Apple holds back WebGL force people to write native apps still widely held?

crubier• 4 years ago

Interesting!

I feel that instead of reimplmenting the React <Component> tree and its hook system (What they call "Live"), they could have made a customer React renderer instead (like React three fiber for example). Focus on the interesting bits (WebGPU), don't reinvent the wheel (React)

jiyinyiyong3• 4 years ago

This library is really inspiring to me in many aspects. WebGPU is interesting, declarative programming on WebGPU is fantastic.

Use.GPU

Related Stories