Compute.toys

[Cotterzz]

You briefly mention compute.toys in the article about storage textures.
You say that storage textures used this way aren't necessarily the best way to do certain things, and that there may be much better ways to do the same thing.
Have you considered doing more of a deep dive on why that is?
Also, do you have any plans on writing a guide to the specific pipeline they use, what you can and can't do with it in relation to WebGPU as a whole? (Which the site itself sadly lacks right now, I've had to search the discord for answers on a few things already.)
I would be more than happy to start writing a tutorial on how to write shaders for the site, if you wanted someone to get the ball rolling.

[greggman]

Something things I can say about compute.toys and it not necessarily showing the best way to do certain things

1. GPUs threads are slower than CPU threads.

   GPUs get their speed from massive parallelization and sometimes from specialized hardware (like texture samplers)

   See the article on image histograms with compute shaders where it finds a single CPU thread is 256x faster than a single GPU thread on M1 Mac, 39x faster on an AMD Mac, 19x faster on an Intel Mac, 19x faster on a Windows AMD PC vs NVidia 2070.

   Where that comes up is examples like this snake game. It's cute and creative that someone was able to put the game logic on the GPU but it's probably not "best practice".

2. Traditional Techniques are often faster

   This was a big issue with shadertoy. The point of shadertoy was a "puzzle": If you only have 1 function, can you draw a pretty picture That leads to beautiful images like this dolphin that runs about 1fps if I make it fullscreen on my M1 Mac vs this unity game which runs at 120fps on the same machine because instead of inefficient SDFs it renders textured triangles.

   I don't know which, if any, current examples of compute.toys have this issue where a more traditional approach would be significantly more performant. But, it is just something to be aware of. The fact that compute.toys limits your options means you're really solving the fun puzzle "can I make this with only these options available". You're not solving the "is this the most performant way to do this" question.

3. Limited options

   compute.toys, like shadertoy, is effectively a puzzle. They give you compute shaders and let you copy data from one to another via buffers. But, what if one of the steps would be better to have a render pass? Or, what if one of the steps would work better if the CPU helped coordinate? Or, what if it would be better to load megs of meshes, textures, and other data?

   The fact that compute.toys has these limits is one of the things that makes it fun. Can you do something interesting, even though you're not allowed to add any CPU code or have much data. It's impressive to overcome those limits. But, those limits means a whole bunch of solutions are off the table.

As for a "how to" article on compute.toys, would that be better on the compute.toys site itself as docs or a tutorial (https://github.com/compute-toys) or does it make sense here?

[Cotterzz]

Thanks for your response.
I'm reasonably clear on the difference between using the entire pipeline as it's designed to be used (along with the CPU), vs forcing everything into a single shader type. I wasn't actually thinking about the big picture, but was wondering specifically about the use of a compute shader with storage texture, versus using say a WGSL frag shader, I wasn't sure if that's what you meant when you said it wasn't an optimal way of doing things.
As for how suitable a tutorial would be...
I did get quite a lot out of your article on how to stage a Shadertoy shader from scratch using WebGL. It really helps to transition from writing shaders on sites like that to using shaders in production work if you have an understanding of how they specifically implement them in the pipeline, that's probably outside the remit of a basic tutorial.
So there's still somewhat of a void, in between how to use this site, and how WGSL/WebGPU works
Sites like those are a great way to start working with shaders and serve as a good introduction the the API's they use, but that approach is only useful if you understand how they fit into the bigger picture. One common source of confusion is features that are site specific vs features that are API specific, which is not always obvious to a newcomer.
If that makes sense.
Sadly they also seem to get by on very rudimentary docs and rely on the majority of their users being able to hit the ground running.
Though you do have a point here, I should probably talk to them first.

Btw, I've found all of your sites to be invaluable, from when I moved over to Three.js a few years ago, then WebGL1/2 and I've been able to fill in a lot of gaps with WebGPU with this new site, so please keep up the good work.

[greggman]

Well, specifically, compute shaders with storage textures, it depends on what you're trying to do. Image processing using compute shaders is probably a win over using triangles. Drawing that dolphin/ocean in a compute shader vs doing it with triangles is probably not. There's no hard and fast rule though. Unreal's nanite renders some stuff that would have traditionally be drawin with triangles in a compute shader, see bevy's example. Tho, those techniques often require a high-end GPU. Vello also I think renders most stuff in compute shaders. My bigger concern was more the shadertoy type of SDF scenes. This selfie girl is amazing and could be ported to a compute shader but it's definitely not performant.

[Cotterzz]

Yes, so while I love that kind of thing, and 3D SDF's look lovely, I'm not convinced yet by their utility (2D is a different story) I am very much trying to figure out how and where I can use shaders to improve performance. I am always interested in alternatives to the traditional triangle rendering methods, though they're interesting because they are the exception, not the rule.
Some examples:

1. Using a hybrid technique, like using quads to render sprites with a shader, but have them controlled and positioned and parameters supplied by the CPU, esp. if you're using something performant like C. Think particle engine, though these particles can be more complex game objects.
2. I'm currently developing a game with JS/WebGL and Raylib/C/OpenGL, and use a single shader to render the entire game, which is only possible because the game is simple (11 objects on screen plus static BG) but having a single renderer that is almost identical means I don't have to rewrite the renderer for both platforms. This one gives me development and aesthetic advantages though, rather than performance advantages, though the performance is good* as long as I keep the resolution constrained.
3. I'm experimenting with using a shader to code automata driven materials, like falling sand and fluids. This is a LOT easier using the CPU, but a LOT faster using a shader. There's a point where the complexity becomes really tricky when doing it in parallel. Compute with storage texture might make a lot of difference here, just being able to write to any pixel (or pixels) really opens things up.

*I develop on an intel 630, which is surprisingly capable, but forces me to keep things very lightweight.
Though I still have to watch when moving shaders to high-dpi mobile devices