Use.GPU
usegpu.live
usegpu.live
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.
Adobe Flash Professional still exists as Adobe Animate: https://www.adobe.com/products/animate.html
Useful for exporting movie and packaging assets / animations to then be consumed by a custom engine but not worth the effort that much when you have spine, etc. which are better supported and used in the industry.
Scaleform still seems to be used by some AAA studio (I'm always surprised to see it) but I can't imagine it they will continue to use it for long.
Also, you can add support for notifications, and for the developer there are more options for monetization.
If you are only targeting the web, you're better off with a game engine specific to the web.
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.
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.
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.
As far as I understand, the approach allows far more flexibility, at the expense of higher complexity. It's less "stateful" than WebGL, which basically gives you a big class that manages everything OOP-style.
Apple does support WebGL2, but compute shader support is not part of that core spec. The demos[2] certainly don't work in Safari in my quick test.
[1]: https://registry.khronos.org/webgl/specs/latest/2.0-compute/
[2]: https://9ballsyndrome.github.io/WebGL_Compute_shader/webgl-c...
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.
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...
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.
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.
we use it to built https://flux.ai
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.
> 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
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.
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...
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.
> 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?
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)
Maybe I'll have to retire this almost 10 year old laptop sometime soon, even though it still runs pretty well.
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?
"Error: Cannot get WebGPU adapter"
Some demos I find work and others don't. Assuming that the feature state is still early days on all browsers.
firefox dev latest on intel mac.
When will we flip it around?
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.
(In this analogy horse=GPU, car/truck=general purpose compute hardware)
That said, your original issue was with general purpose compute infrastructure on top of GPU, which can be applied to this analogy too; using the Thrust SSC to transport a container is probably not the best. Possible, but suboptimal.
Do you mean software rendering? Or more like baking GPUs into CPUs (already done decades ago, see SoC or integrated graphics hardware).
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.
Seems back up now, might have been HN hug of death.