Not to be confused with WebGL, it’s not the same thing.
I think it’s the future of general rendering, used natively and in browsers.
It can render to ANY platform, and facilitates compute shaders out of the box.
I won’t say too much here as there’s lots and lots of youtube examples of it.
What google says about it:
"
WebGPU officially works on 5 major operating system families natively and across 4 major browser engines, enabling cross-platform development through underlying graphics APIs (Vulkan, DirectX 12, Metal).
Across browsers and native runtimes, WebGPU is available on the following platforms:
Desktop Operating Systems
Windows: Uses the DirectX 12 backend.
macOS: Uses the Metal backend.
Linux: Uses the Vulkan backend.
ChromeOS: Uses the Vulkan backend.
[image]Chrome for Developers +4
Mobile Operating Systems
Android: Supported.
iOS / iPadOS: Supported.
visionOS: Supported.
[image]Chrome for Developers +1
Browser Support
WebGPU ships by default across all major browser engines, including:
FWIW I’ve been using slang for cross-platform compute shaders.
You do still have to write the native calling code though so it’s not really cross-platform in the way WebGPU’s approach is but it’s a start.
I have a tiny module with a general-purpose header and Metal and DirectX implementations which allows me to call compute shaders almost as if they were native C++ functions. I had been thinking about open sourcing it as it’s so tiny…
But yes I agree WebGPU looks really promising… IIRC Apple themselves are contributing to the Metal backend so it has some good corporate backing already.
Although I’m not sure how it would work as a JUCE feature request? I would expect to use it through WebBrowserComponent
Oh it looks like there’s a direct C API, and a C++ wrapper of that.
I’m using them for some visualisers - they don’t do the graphics rendering themselves, I use SVGs in a webview for that, but they do the bulk of the heavy calculation which is all heavily parallelisable so ideal for compute shaders.
You could use them from the audio thread but I think the round trip of sending data to the GPU, waiting for all the jobs to finish, and getting the data back would be pretty indeterministic so it wouldn’t be ideal.
That being said, I suppose GPUs are designed to do heavy calculations at a high frequency (4k @ 144Hz for example) so you probably could get away with doing some live audio processing, espcially on larger buffer sizes.
I came to the same conclusion, and am currently building a 3D noise instrument with WebGPU / Dawn and JUCE and it is going pretty well so far. Started about a month ago with this tutorial: Hello Triangle 🟢 - Learn WebGPU for C++ documentation .
Here is my repo so far if anyone wants to check out the setup or stay updated on progress:
I’ve been worried about Juce software rendering for a while now, to jump to a global, accepted way of hardware rendering would be amazing. The old software renderer can stay, of course, in case of apocalypse! Asynchronously composing waveforms, background impulse reverb updates and layer rendering, are just a couple of places I could use compute shaders for, right now.
Once you start parallelism work, it’s easier to see more uses for it.
Yeah, I’m trying enthusiasm, for a change.
But why is no-one voting I wonder?
I had a play with WebGPU at the weekend to see if I could make a really basic renderer. I don’t know enough about writing custom JUCE renderers to get anything working, but the WebGPU API was pretty straightforward to integrate.
“We currently render an image and upload it to a CPU juce::Image. It would be great if like with OpenGL we could keep it all in the GPU.”
Wait…can you clarify…
Are you rendering the whole UI screen using WebGPU and then copying to a single full-screen JUCE image, or are you using smaller images and rendering single UI components to them?
It draws directly to the attached component’s native NSWindow using a WGPUSurface and then fills a solid colour following this tutorial: First Color 🟢 - Learn WebGPU for C++ documentation. The tutorial uses GLFW to create the window and then this extension to create a surface from the native window. I took the macOS-speciifc code from glfwCreateWindowWGPUSurface for a quick-win, but it also has versions for HWND on Windows.
@ Nitsuj70
Yeah, but it could be rendering the UI, in the future.
In the meantime, it’s a fantastic start to have a webGPU folder in a project, and have it rendering anything in a plug-in.
This is a demo of the plugin I am working on. It renders the entire UI with WebGPU / Dawn, and has a navigable “level”, a few sliders, and resizing right now. A full UI is definitely doable.
Desktop Operating Systems
Mobile Operating Systems
Browser Support
