compute-shader-101 VS strange-attractors

You might find compute shader 101 useful.

Compute Shader 101 - Github, Video, Slideshow. additional resources at end of slide show.

Yes, compute-shader-101 is sample code + video + slides.

Workgroup in Vulkan/WebGPU lingo is equivalent to "thread block" in CUDA speak; see [1] for a decoder ring.

> Using atomics to solve this is rarely a good idea, atomics will make things go slowly, and there is often a way to restructure the problem so that you can let threads read data from a previous dispatch, and break your pipeline into more dispatches if necessary.

This depends on the exact workload, but I disagree. A multiple dispatch solution to prefix sum requires reading the input at least twice, while decoupled look-back is single pass. That's a 1.5x difference if you're memory saturated, which is a good assumption here.

The Nanite talk (which I linked) showed a very similar result, for very similar reasons. They have a multi-dispatch approach to their adaptive LOD resolver, and it's about 25% slower than the one that uses atomics to manage the job queue.

Thus, I think we can solidly conclud that atomics are an essential part of the toolkit for GPU compute.

You do make an important distinction between runtime and development environment, and I should fix that, but there's still a point to be made. Most people doing machine learning work need a dev environment (or use Colab), even if they're theoretically just consuming GPU code that other people wrote. And if you do distribute a CUDA binary, it only runs on Nvidia. By contrast, my stuff is a 20-second "cargo build" and you can write your own GPU code with very minimal additional setup.

[1]: https://github.com/googlefonts/compute-shader-101/blob/main/...

googlefonts/compute-shader-101: Sample code for compute shader 101 training (github.com)

I agree strongly with you about the need for good resources. Here are a few I've found that are useful.

* A trip through the Graphics Pipeline[1] is slightly dated (10 years old) but still very relevant.

* If you're interested in compute shaders specifically, I've put together "compute shader 101"

* Alyssa Rosenzweig's posts[3] on reverse engineering GPUs casts a lot of light on how they work at a low level. It helps to have a big-picture understanding first.

I think there is demand for a good book on this topic.

[1]: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...

[2]: https://github.com/googlefonts/compute-shader-101

[3]: https://rosenzweig.io/

This is a talk I've been working on for a while. It starts off motivating why you might want to write compute shaders (tl;dr you can exploit the impressive compute power of GPUs but portably), then explains the basics of how, including some sample code to help get people started.

Slides: https://docs.google.com/presentation/d/1dVSXORW6JurLUcx5UhE1...

Sample code: https://github.com/googlefonts/compute-shader-101

Feedback is welcome (please file issues against the open source repo), and AMA in this thread.

Really cool to see this being written with Rust/WGPU! I really hope it has a strong future ahead of it - being able to target multiple native graphics APIs with one codebase is very alluring.

A friend and I adapted a wgpu-rs "boids" example to render strange attractors with compute shaders, though we basically haven't applied _any_ polish to it yet:

https://github.com/bschwind/strange-attractors

The entire thing is drawn in one call, seen here