51–57 of 57 posts
Earlier quoted context omitted.
I dunno, writing GPU code that works across Mac/Win/Lin/iOS/droid isn’t easy to deploy.
Unity, Unreal, Open3D, Ogre 3D, Godot, Defold, Stride,... look all pretty easy to me, with access to hardware features not available in WebGPU.
Earlier quoted context omitted.
I just checked on Linux Firefox and iOS Firefox and both loaded the background without issues.
Hmm, that's probably the static picture fallback you're seeing. Here's a video of what the particles look like when moving if interested: https://www.loom.com/share/c2608492dce44ab4b84b8fe4c68c44cd?...
Earlier quoted context omitted.
The features you mention are mostly applications of compute shaders, which are fully capable of being written in WebGPU, as WebGPU supports buffer -> buffer compute shaders when the underlying GPU supports it. I've personally implemented mesh shaders in my own project, and there are plenty of examples of WebGPU real time raytracers out there. DirectStorage I had to google and it looks like a Windows DMA framework for…
I bet those implementation of yours weren't done in WebGPU actually running on the browser, otherwise I would greatly appreciate being corrected with an URL. DirectStorage started as a Windows feature, is actually quite common in game consoles, and there is ongoing work to expose similar functionality in Vulkan. Yes, I do have WebGPU experience and have already contributed to BabylonJS a couple of times. Maybe I do a…
https://dawn.googlesource.com/dawn
https://eliemichel.github.io/LearnWebGPU/
Yes it is exposed to Javascript applications by browsers that support it, much like WebGL exposes OpenGL ES. But that’s a separate thing.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
OP is right. WebGPU is targeted towards the lowest common denominator, which is fairly old mobile phones. It therefore doesn't support modern features and is basically an outdated graphics API by design.
Care to give an example? From my viewpoint as a WebGPU user, we consistently get access to new GPU features with every refresh. E.g: https://developer.chrome.com/blog/webgpu-io2023 You just have to set limits correctly when you initialize a GPU instance in order to have access to the new features.
One of the turning points for the worse was the introduction of WGSL. Before WGSL, you could do lots of stuff with spirv shaders because they weren't artifically limited. But with WGSL, they went all in on turning WebGPU into a toy-language that only supports whatever last decades mobile phones support. I was really hopeful for WebGPU because UX-wise, it is so much better than anything else. Far better than Vulkan or OpenGL. But feature-wise, WebGPU so limited that I had to go back to desktop OpenGL.
In one way WebGPU really has become a true successor to WebGL though - it is a graphics API that is outdated on arrival.
this is impressively well designed, as someone who dabbled in this kind of thing many moons ago. hats off to you.