vello_gpu: Add initial support for excluding certain paints from shaders at compile-time

[LaurenzV]

As our experiments have shown, complex shaders have a bad impact on performance as well as shader compilationt times on low-tier devices. This PR proposes a new method for allowing users to exclude certain features at compile-time, if they know they won't need it. In case they do still use it, we will panic at runtime.

This PR is best reviewed commit-by-commit.

• The first commit changes the structure of the shaders by extracting some code into helper methods, making it easier to later on compile out certain parts of the render.wesl module.
• The second commit extracts some functionality of vello_tests into a custom crate, so that it can be reused by different tests. This is necessary because we want to be able to test the various configurations of enabled feature sets, which (as you will see) is easier to do by creating a new test crate, instead of modifying vello_tests. Extracting this part of the code allows us to reuse the snapshot logic between the two.
• The third commit actually implements the main logic of this PR. For now, I've only implemented this for blurred rects, sweep gradients and bicubic image rendering, which is what we personally don't need. In theory, this can of course be extended to cover other paints, such as linear gradients. However, if we for example exclude all gradients, we would also have to start feature gating stuff on the Rust side, as some of the bindings might become dead code and would have to be excluded as well. I wanted to avoid this for the first prototype, so I've only limited the implementation to these three paints for now.
• The fourth commit adds a new test crate and a CI step that ensures we don't accidentally break anything for certain feature configurations. Let me know if you think they are unnecessary and I should remove them again.

[LaurenzV]

Bit annoying having to redefine this everywhere. 😅 Not sure if we should figure out something else.

[grebmeg]

What do you think about adding an all_shader_features umbrella feature to vello_gpu? Right now the same three shader features are listed by hand in seven Cargo.toml files (the examples, vello_tests and vello_example_scenes). Each new shader feature would mean updating every one of those, and any we miss would quietly build that crate with the new feature off. With the umbrella, dependents just say "everything" and pick up new features automatically, and default can use it too. It's purely additive, so it doesn't break anyone who already enables the features by name.

default = ["wgpu", "wgpu_default", "text", "all_shader_features"]
all_shader_features = ["blurred_rounded_rect", "image_bicubic", "gradient_sweep"]

[LaurenzV]

Yeah makes sense, I think it's a biiit ugly, but it's probably the more pragmatic choice. 😄

[LaurenzV]

Running this on Ubuntu on purpose instead of MacOS, as MacOS runs the whole workspace with all-feature, and that requires unnecessarily recompiling a lot of dependencies because the enabled features change.

[grebmeg]

Nice work! 🔥 It would be great to include some of the numbers you shared with me before in the PR, as they’re pretty impressive! Maybe adding a bit of performance profiling would also be valuable, both as a reference and to highlight the positive outcome we achieved with these changes.

[grebmeg]

Is it intentional that run.sh only renders 5 of the 8 feature combinations? The pairs (blurred_rounded_rect,image_bicubic, blurred_rounded_rect,gradient_sweep, image_bicubic,gradient_sweep) never get a render test, even though build.rs already produces snapshot names for them. Since shader_feature_combinations_compile in vello_gpu_shaders already links and validates all 8, what's left uncovered is interactions that only appear at render time. Adding them would cost three more reference PNGs and three more builds per backend, so I'm curious whether you think that's worth it, or whether the compile-level coverage is enough for now.

[LaurenzV]

Since it's likely we will add more features, I think for now it's better to only test each feature in isolation instead of the powerset, otherwise we'll have lots of snapshots in the future!

[grebmeg]

What do you think about adding an all_shader_features umbrella feature to vello_gpu? Right now the same three shader features are listed by hand in seven Cargo.toml files (the examples, vello_tests and vello_example_scenes). Each new shader feature would mean updating every one of those, and any we miss would quietly build that crate with the new feature off. With the umbrella, dependents just say "everything" and pick up new features automatically, and default can use it too. It's purely additive, so it doesn't break anyone who already enables the features by name.

default = ["wgpu", "wgpu_default", "text", "all_shader_features"]
all_shader_features = ["blurred_rounded_rect", "image_bicubic", "gradient_sweep"]

[LaurenzV]

It would be great to include some of the numbers you shared with me before in the PR, as they’re pretty impressive!

OMG... Okay, so I originally thought the only improvements are going to come from #1964, which adds a fast path for native image sampling... The original intention behind this PR was to reduce shader complexity and allow us to improve the stall that I saw on MacBook, but it turns out that this PR actually also improves FPS! Below, you can find the numbers on current main / this branch will all features enabled, vs. with sweep gradient, blurred rect and bicubic sampling disabled:

Before: Around 26 FPS on average

IMG_1333.MOV

After: Around 70FPS on average!!

IMG_1335.MOV

It will be interesting to see whether the gains from #1964 will compound once rebased onto this branch.

For the stall time, it's a bit inconsistent, but overall this change reduces the average time of the shader compilation stall I see on the MacBook device:

Before:

After: