[stanleykm]

This is really cool. As far as boilerplate goes WebGPU is really not that bad (one just needs to look at Vulkan to see how fun it can get) but really anything to lower the barrier to entry is nice.

I am curious about the API overhead here. For example if I run two separate passes using bare WebGPU I could use a single command encoder. Would two function calls here result in two command encoders?

Another question - from the example code this doesnt look asynchronous, does it wait for everything to finish before returning? I could also be misreading the code I dont know typescript very well.

[jrmydev]

Thanks, and great question:

Shadeup will try to fit it all into one command encoder but may need to split if the coder: 1. Manually flushes 2. Reads/downloads a buffer on the CPU

Most calls are lazily evaluated, and a small dep graph is built as you reference/draw things.

That being said, shadeup does make some perf sacrifices in the name of simplicity. I'd say it's well suited to prototyping and learning. Of course, once you have a working prototype of something porting it to native wgsl should be easy

[burntcaramel]

Have you thought about having an "eject" command? For example, Create React App had an eject command to go from the self-contained version to a full customisable Webpack app.

[jrmydev]

Users can already kinda do this by showing the compiled output, but the js engine itself is still tucked away. At some point, I would probably have a tree shaken full output for each shadeup.

[stanleykm]

Oh nice thanks for the explanation.

[pjmlp]

WebGPU main pain point is forcing everyone to rewrite their shaders, no wonder most Web native game engines are going the shading language abstraction route, when only Chrome does WebGPU on desktop, and it isn't even an option on mobile years to come.

Thus cross API WebGL / WebGPU shading middleware is needed.

[greggman7]

IIRC, WebGPU is shipping on Android in ~4 days

Safari Technology Preview finally turned it on again. Of course when Apple will ship it on Mac and/or iOS is unknown but at least they showed some progress after hiding for 6 or more months

Firefox is doing their best to ship ASAP.

[adastra22]

wgpu is a nice implementation of webgpu for native rust applications on desktop.

[pjmlp]

I don't see a point of that versus middleware engines, with much better tooling.

WebGPU/WebGL are like JavaScript, something that we have to put up with, because on the browser there is no other alternative.

No need to constrain ourselves to the browser limitations when there are other options.

[adastra22]

Don’t be fooled by “web” in the name. Just like WebAssembly is/will be a better JVM, WebGPU is already posed to be a better OpenGL/Vulkan. It is a full graphics API unconstrained by browser implementations, and available without a browser runtime.

[fayalalebrun]

I am curious, in what ways is WebGPU better than Vulkan or Metal? From my point of view, WebGPU going back to an interpreted shading language like OpenGL makes it conceptually closer to JavaScript than WebAssembly.

[adastra22]

HLSL has in practice become the shader language for Vulkan, and Metal has always had a high-level shading language. The GPU market is simply too heterogeneous for a low-level ISA like SPIR-V to be applicable and performant across all architectures. A modern GPU driver effectively has to "decompile" SPIR-V binaries, then recompile it to the actual vendor-specific architecture used on the installed GPU, and perform both high-level and low-level optimizations. Standardizing on a single high level shading language, but one purposefully designed to be cross-platform, is actually the simpler architecture here.

[tlb]

I wrote a big visualization application with WebGPU and I'm happy with the choice. It's much cleaner than OpenGL, without as much complexity as Vulkan or Metal. It runs on Mac & Linux, and I got a demo version working in the browser with emscripten fairly easily. It doesn't have the trouble with OpenGL version compatibility that used to make supporting multiple platforms a hassle.

I'm not sure what's 'interpreted' about it. On Mac, the wgpu-native driver transcodes to the Metal shading language and it gets compiled.

[mschuetz]

I gave up on Vulkan simply because it's too overengineered and cumbersome. WebGPU, on the other hand, is relatively easy to use, even though it is build on many of the same concepts.

[adastra22]

WebGPU IS basically Metal, but cross platform. When the W3C decided to standardize a new graphics API, Apple submitted a proposal that was basically Metal with a name change. That proposal became the basis of WebGPU, though like any committee standard it has undergone multiple revisions since then.

Metal itself was basically Apple looking at Vulkan and saying “Lol, no way in hell. That’s a stinking mess of complexity.” Then they went off and made a simpler, less boilerplate, easier to code but just as performant and powerful API for Apple platforms. Now WebGPU makes all those improvements available everywhere.

And ignore the Web prefix: WebGPU is a lower level API, like DX12, Vulkan or Metal. It just came out of the W3C, hence the name. Unfortunately the name makes people think that it is a JavaScript browser extension or something, which is is not. You can call it from a browser, yes, and the API is designed to enable sandboxed instances for that purpose, but that’s a higher level integration, just like how WebGL exposes OpenGL ES.

In fact maybe that’s a better way to explain it. Until now if you wanted 3D in a browser you had to use WebGL which gave you a OpenGL ES compatible API. Except OpenGL is ancient and GLES doesn’t support vendor extensions, so this was a really shitty situation. W3C decided “Let’s make a new low level graphics API to replace OpenGL ES, and a new JavaScript browser extension to expose that API [replacing WebGL]” and they decided to confusingly call at various times both things, and the whole stack together when integrated with a browser “WebGPU.”

However most of the excitement and work surrounding WebGPU right now is around Rust and C++ frameworks that are using WebGPU as a platform and device independent middleware framework, since the standard implementations will performantly transform WebGPU calls into Metal, Vulkan, or DX12 system calls based on what the end user system supports, making it an excellent middleware that is really easy to target. So really, WebGL is a replacement for OpenGL in a way that Vulkan was not.

[blarg1]

Vulkan is too hard and metal is only for mac.

[pjmlp]

It isn't WebGPU any longer if it is incompatible with browsers.

[FL33TW00D]

A single code base for both native & web? Not having to write Javascript on the web?

[jrmydev]

Exactly this, along with a lot of the "smoothing-out" done by the webgpu spec which provides a clear and open abstraction target.

[pjmlp]

Minimum common set of features from 2015 hardware.

[pjmlp]

Only if you enjoy coding to 2015 hardware specifications in 2024, leaving the rest of the hardware out.

[adastra22]

I think you are confusing WebGPU with WebGL?

WebGPU standard process only started in 2021, and is still undergoing revisions.

[sroussey]

I dunno, writing GPU code that works across Mac/Win/Lin/iOS/droid isn’t easy to deploy.

[pjmlp]

Unity, Unreal, Open3D, Ogre 3D, Godot, Defold, Stride,... look all pretty easy to me, with access to hardware features not available in WebGPU.

[sroussey]

I’m not running unity to get some fast matrix multiplication, lol.

[stanleykm]

Reducing boilerplate isnt really trying to solve that problem. Barrier to entry here can also be read as “making shaders less scary for newbies”