@compute.toys is an experimental editor for WebGPU compute shaders. At this time, only Chrome (v113+) is supported, as WebGPU is not yet fully supported by other browsers.
> I've been playing with WebGPU native with both Dawn and WGPU and they both seem to work fine outside of the browser
1. WGPU only has an API inspired by WebGPU, it is not WebGPU itself.
2. WebGPU is an API, not a library. Just because you've been using libraries that implement WebGPU outside of the browser doesn't mean the browser can just link to WebGPU.
"This initial release of WebGPU is available in Chrome 113 on ChromeOS devices with Vulkan support, Windows devices with Direct3D 12 support, and macOS. Linux, Android, and expanded support for existing platforms will come soon."
It is confusing, even finding out whether you have "Direct3D 12" is hard as windows mixes it up with directx 12 in the UI.
Long story short, it will likely take some time before WebGPU is avaiable broadly, which is a shame as I am in the process of discovering the raw power of the GPU to greatly speed up allmost everything.
Great technology demos. Looks like this is the first step to a WebGPU based Shadertoy [1] alternative. I will definitely compare the demos with my experiments [2].
I have a good feeling about WebGPU. Not only inside the browser, but also outside. A modern standardised interface for all platforms. And it is relatively easy to use, considering the complexity that the interface has to represent.
I just installed Chrome 113 on a macbook today. Either the site is super glitchy, or WebGPU in Chrome on a mac is; because I am randomly getting the "unable to create adapter" error, and a couple of times I got a weirdly flashing screen. I did manage to see the shader maybe twice.
As far as I understand it WebGPU is just a thin translation layer to binary SPIR-V with fake Rust syntax. Is it really faster than GLSL?
The lack of important language features like function overloading or clear client side code separation via preprocessors is annoying. Also misleading notations like mat4x4<f32> instead of mat4 that imply that you could put any type between "<>" and expect it to be hardware accelerated which is not the case. Finally, the lack of assignment and ternary operators and forced bracing will make your code look really ugly.
I don't like it. It would have been better if they simply extended GLSL to cover the full SPIR-V capabilities.
WGSL is the shading language, which is technically not the same thing as WebGPU. WebGPU is the graphics API, which uses WGSL as its shading language.
You can feel free to preprocess the files any way you like, it's just not something the browser does for you (imo the correct decision). WebGPU implementations like wgpu-rs let you use any shading language that compiles to SPIR-V. My feeling is that bespoke shading languages like WGSL and GLSL are on their way out, anyway. Things like rust-gpu that allow you to write your shader code in the same language as your application code are just so much more ergonomic.
> Applications using wgpu run natively on Vulkan, Metal, DirectX 11/12, and OpenGL ES; and browsers via WebAssembly on WebGPU and WebGL2.
is not an argument against being WebGPU, as GPU drivers don't talk WebGPU directly (for now?), and WebGPU implementations are free to use whatever backend they please, as long as they provide the right API.
However, wgpu is still only based on the WebGPU API, which makes the topic of backends irrelevant anyway~
Your computer can't do any useful crypto mining if you're the one paying for electricity, but if you're freely using other people's computers then it can definitely be profitable.
One of the reasons I drifted towards heavy hardware computing was that the software was still impossible via web browser. This is amazing tech and everyone has wanted a universal GPU interface for years, but I'll be a bit solemn when all my favorite tools are replaced by website equivalents. It was good while it lasted!
37 comments
[ 3.2 ms ] story [ 85.7 ms ] thread>For information on how to set up your browser to run WebGPU code, please see the instructions linked on the @compute.toys homepage.
Uh, where would those instructions be? A link in this popup itself would be easier.
Which I find funny because I've been playing with WebGPU native with both Dawn and WGPU and they both seem to work fine outside of the browser.
Ironic for a company that uses so much Linux based systems.
1. WGPU only has an API inspired by WebGPU, it is not WebGPU itself.
2. WebGPU is an API, not a library. Just because you've been using libraries that implement WebGPU outside of the browser doesn't mean the browser can just link to WebGPU.
With that said, I think Chrome does use Dawn.
It would be nicer if it could just give the warning and then disable trying to run the shaders, but still let me explore and possibly learn something.
It's been a long road, getting from there to here.
It's been a long time, but my time is finally near...
``` await navigator.gpu.requestAdapter() VM168:1 Failed to create WebGPU Context Provider (anonymous) @ VM168:1
```
It is confusing, even finding out whether you have "Direct3D 12" is hard as windows mixes it up with directx 12 in the UI.
Long story short, it will likely take some time before WebGPU is avaiable broadly, which is a shame as I am in the process of discovering the raw power of the GPU to greatly speed up allmost everything.
Was running into the "no available adapters" issue, good to know this is probably my problem. I guess I just am not getting WebGPU then.
I thought I had, as it usually auto updates and it came out a while ago. But I had not and had to manually start the update and then it worked.
Nope. I watched the builds for my platform like a hawk until 113 was available.
I don't have auto-updates.
I have a good feeling about WebGPU. Not only inside the browser, but also outside. A modern standardised interface for all platforms. And it is relatively easy to use, considering the complexity that the interface has to represent.
[1] https://www.shadertoy.com/
[2] https://github.com/s-macke/WebGPU-Lab
How faux is the 3d? I'm wondering whether it could work in VR. I'd love to see that...
The 3D is real and should work in VR.
The lack of important language features like function overloading or clear client side code separation via preprocessors is annoying. Also misleading notations like mat4x4<f32> instead of mat4 that imply that you could put any type between "<>" and expect it to be hardware accelerated which is not the case. Finally, the lack of assignment and ternary operators and forced bracing will make your code look really ugly.
I don't like it. It would have been better if they simply extended GLSL to cover the full SPIR-V capabilities.
You can feel free to preprocess the files any way you like, it's just not something the browser does for you (imo the correct decision). WebGPU implementations like wgpu-rs let you use any shading language that compiles to SPIR-V. My feeling is that bespoke shading languages like WGSL and GLSL are on their way out, anyway. Things like rust-gpu that allow you to write your shader code in the same language as your application code are just so much more ergonomic.
wgpu isn't exactly an implementation of WebGPU, it's just based on WebGPU (heavily inspired).
> wgpu is a safe and portable graphics library for Rust based on the WebGPU API. It is suitable for general purpose graphics and compute on the GPU.
> Applications using wgpu run natively on Vulkan, Metal, DirectX 11/12, and OpenGL ES; and browsers via WebAssembly on WebGPU and WebGL2.
> Applications using wgpu run natively on Vulkan, Metal, DirectX 11/12, and OpenGL ES; and browsers via WebAssembly on WebGPU and WebGL2.
is not an argument against being WebGPU, as GPU drivers don't talk WebGPU directly (for now?), and WebGPU implementations are free to use whatever backend they please, as long as they provide the right API.
However, wgpu is still only based on the WebGPU API, which makes the topic of backends irrelevant anyway~
The only way I even know a page is using WebGPU is because my GPU usage spikes when the tab is open.