vello VS compute-shader-101

I'm looking forward to doing careful benchmarking, as this renderer absolutely looks like it will be competitive. It turns out that is really hard to do, if you want meaningful results.

My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher.

One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]).

Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future.

[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...

[2]: https://github.com/linebender/vello/issues/259

[3]: https://github.com/gpuweb/gpuweb/issues/4306

Dioxus is working on this with blitz. It's leveraging wgpu through the linebender group's Vello renderer. Still in early stages.

If you're doing advanced compute work (including lock-free data structures), then it's best effort.

https://github.com/linebender/vello/issues/42 is an issue from when Vello (then piet-gpu) had a single-pass prefix sum algorithm. Looking back, I'm fairly confident that it's a shader translation issue and that it wouldn't work with MoltenVK either, but we stopped investigating when we moved to a more robustly portable approach.

There are a number of up-and-coming Rust-based frameworks in this niche:

- https://github.com/iced-rs/iced (probably the most usable today)

- https://github.com/vizia/vizia

- https://github.com/marc2332/freya

- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)

What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:

- https://github.com/rust-windowing/winit (cross-platform window creation)

- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)

- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)

- https://github.com/DioxusLabs/taffy (UI layout algorithms)

- https://github.com/pop-os/cosmic-text (text rendering and editing)

- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)

In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)

blessed.rs lists these three crates for 2D drawing: - https://lib.rs/crates/femtovg - https://lib.rs/crates/skia-safe - https://github.com/linebender/vello

Vello (https://github.com/linebender/vello) which uses wgpu to render Edit: just saw you require images. Vello doesn't support those yet

How does this relate to Vello? Both target raw-window-handle for winit compatibility. Vello uses WGPU vs piet-glow using GL.

Finally, maybe vello could help you with ideas. It's not production ready yet, but they have some interesting ideas for 2D rendering using wgpu.

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.