compute-shader-101 VS V-EZ

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.

I did stumble across V-EZ a few months ago, something AMD has been working on for the people: https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ

I can't answer your question, but https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ has a pipeline reflection sample that can be used as an inspiration to dynamically create vertex declarations or implement automatic UBO construction.

AMD tried to make Vuklan Easy Mode but it hasn't been touched in the last 4 years. If any company was serious about it, it could easily be the best way to get new developers on board with Vulkan.

V-EZ [1] was kinda supposed to be that, a wrapper that makes Vulkan easier to use in non-über-performance-critical applications, but it seems to be dead [2]...

[1] - https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ

[2] - https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ/issues/73