An experimental editor for WebGPU compute shaders | Hacker News Reader

An experimental editor for WebGPU compute shaders

compute.toys

136 points_hypx36 comments

>WebGPU support was not detected in your browser.

>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.

@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.

It's also not working on Chrome Beta on Linux with Intel Graphics.

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.

macOS and Windows are tier 1, Android tier 2, and GNU/Linux will eventually be supported.

Ironic for a company that uses so much Linux based systems.

> 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.

With that said, I think Chrome does use Dawn.

As a Firefox user, I also got this.

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.

I think for learning and exploring shaders, shadertoy.com might be your go to source.

That's what it did for me (Edge). I just clicked to dismiss the dialog and then you can still browse the site, read the shader code and so on.

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.

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.

[1] https://www.shadertoy.com/

[2] https://github.com/s-macke/WebGPU-Lab

Hey. That protean clouds example is beautiful.

How faux is the 3d? I'm wondering whether it could work in VR. I'd love to see that...

Before you think, that I have developed it. No. The protean clouds is just a port of https://www.shadertoy.com/view/3l23Rh to WebGPU.

The 3D is real and should work in VR.

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!

I'll know the technology is mainstream + serious when people start running Pytorch/Tensorflow with a WebGPU backend.

Does WebGPU present a permissions dialogue or does it just work automatically, allowing drive-by cryptominers?

No dialogue, it just works.

The only way I even know a page is using WebGPU is because my GPU usage spikes when the tab is open.

Your computer can’t really do any useful crypto mining, so I wouldn’t be too worried.

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.

In my case it was easy to setup, but I didn't figured out how to change from using my iGPU to the GPU. Unfortunetly on the iGPU it is pretty slow.

Wow, super bleeding edge! I just had to update chrome to 113 to view it. Awesome shaders

Cue the WebGPU theme song:

It's been a long road, getting from there to here.

It's been a long time, but my time is finally near...

Doesn't work for me on 113.

``` await navigator.gpu.requestAdapter() VM168:1 Failed to create WebGPU Context Provider (anonymous) @ VM168:1

```

Only works on Windows + MacOS right now.

Same. Chrome 113 on MacOS.

"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.

I use D3D9 because D3D12 blanks the screen when I try to watch Netflix or etc., whereas D3D9 works just fine.

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.

Another reason might be, that you still don't have chrome 113.

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.

> that you still don't have chrome 113.

Nope. I watched the builds for my platform like a hawk until 113 was available.

I don't have auto-updates.

This is great! I've poked around for a tool with ShaderToy's immediacy, but for compute shaders. Always come up empty until now.

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.

> WebGPU implementations like wgpu-rs

wgpu isn't exactly an implementation of WebGPU, it's just based on WebGPU (heavily inspired).

I was surprised to read your comment, despite ostensibly being familiar with wgpu. But sure enough (from the homepage):

> 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.

To be fair,

> 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~

Would be great to have an option to write directly in Metal / OpenGL.

That defeats the purpose of a vendor-agnostic, platform-agnostic web graphics API.

Reply on news.ycombinator.com