Contiguous storage for path segments

This is part of the larger multisampled path rendering work, under stroke rework (#303). It refactors the GPU pipeline so that the path segments available to fine rasterization are stored as a contiguous slice rather than a linked list as before.

Numerous parts of the pipeline are refactored. In the old pipeline, path segment decoding generated cubic line segments and also estimated a bounding box (somewhat imprecise), and the combination of flattening those cubics and tiling was in a separate stage (path_coarse) quite a bit later in the pipeline. In the new pipeline, path decoding is fused with flattening, generating a `LineSoup` structure (line segments associated with paths, otherwise unordered) (with bbox as a side effect), and tiling is spread over multiple stages, later in the pipeline.

The first tiling stage (path_count) counts the number of tiles that will be generated. Then coarse rasterization allocates contiguous slices based on those counts. The second stage does a scattered write of the resulting tiles. Both of these stages rely on indirect dispatch, as the number of lines and the number of segments (respectively) are not known at encode time.

These changes only make sense for filled paths, thus they relied on stroke expansion being done earlier, currently on the CPU.
21 files changed
tree: c5d5f476fc7740c2d606ea0e2c70e5eef77673b3
  1. .cargo/
  2. .github/
  3. .vscode/
  4. crates/
  5. doc/
  6. examples/
  7. integrations/
  8. shader/
  9. src/
  10. .gitignore
  11. Cargo.toml
  12. LICENSE-APACHE
  13. LICENSE-MIT
  14. README.md
README.md

Vello

An experimental GPU compute-centric 2D renderer

Xi Zulip dependency status MIT/Apache 2.0 wgpu version

Vello is a 2d graphics rendering engine, using wgpu. It efficiently draws large 2d scenes with interactive or near-interactive performance.

It is used as the rendering backend for Xilem, a UI toolkit.

Quickstart to run an example program:

cargo run -p with_winit

Integrations

SVG

This repository also includes vello_svg, which supports converting a usvg Tree into a Vello scene.

This is currently incomplete; see its crate level documentation for more information.

This is used in the winit example for the SVG rendering.

Lottie

A separate integration for playing Lottie animations is available through the velato crate.

Examples

Our examples are provided in separate packages in the examples folder. This allows them to have independent dependencies and faster builds. Examples must be selected using the --package (or -p) Cargo flag.

Winit

Our winit example (examples/with_winit) demonstrates rendering to a winit window. By default, this renders GhostScript Tiger all SVG files in examples/assets/downloads directory (using vello_svg). A custom list of SVG file paths (and directories to render all SVG files from) can be provided as arguments instead. It also includes a collection of test scenes showing the capabilities of vello, which can be shown with --test-scenes.

cargo run -p with_winit 

Some default test scenes can be downloaded from Wikimedia Commons using the download subcommand. This also supports downloading from user-provided URLS.

cargo run -p with_winit -- download

Bevy

The Bevy example (examples/with_bevy) demonstrates using Vello within a Bevy application. This currently draws to a wgpu Texture using vello, then uses that texture as the faces of a cube.

cargo run -p with_bevy

There is also a separate community integration for rendering lottie and SVG files through bevy_vello.

Platforms

We aim to target all environments which can support WebGPU with the default limits. We defer to wgpu for this support. Other platforms are more tricky, and may require special building/running procedures.

Web

Because Vello relies heavily on compute shaders, we rely on the emerging WebGPU standard to run on the web. Until browser support becomes widespread, it will probably be necessary to use development browser versions (e.g. Chrome Canary) and explicitly enable WebGPU.

The following command builds and runs a web version of the winit demo. This uses cargo-run-wasm to build the example for web, and host a local server for it

# Make sure the Rust toolchain supports the wasm32 target
rustup target add wasm32-unknown-unknown

# The binary name must also be explicitly provided as it differs from the package name
cargo run_wasm -p with_winit --bin with_winit_bin

Warning
The web is not currently a primary target for vello, and WebGPU implementations are incomplete, so you might run into issues running this example.

Android

The with_winit example supports running on Android, using cargo apk.

cargo apk run -p with_winit

Note
cargo apk doesn't support running in release mode without configuration. See their crates page docs (around package.metadata.android.signing.<profile>).

See also cargo-apk#16. To run in release mode, you must add the following to examples/with_winit/Cargo.toml (changing $HOME to your home directory):

[package.metadata.android.signing.release]
path = "$HOME/.android/debug.keystore"
keystore_password = "android"

Community

Xi Zulip

Discussion of Vello development happens in the Xi Zulip, specifically the #gpu stream. All public content can be read without logging in

Shader templating

We implement a limited, simple preprocessor for our shaders, as wgsl has insufficient code-sharing for our needs.

This implements only classes of statements.

  1. import, which imports from shader/shared
  2. ifdef, ifndef, else and endif, as standard. These must be at the start of their lines.
    Note that there is no support for creating definitions in-shader, these are only specified externally (in src/shaders.rs). Note also that this definitions cannot currently be used in-code (imports may be used instead)

This format is compatible with wgsl-analyzer, which we recommend using. If you run into any issues, please report them on Zulip (#gpu > wgsl-analyzer issues), and/or on the wgsl-analyzer issue tracker.
Note that new imports must currently be added to .vscode/settings.json for this support to work correctly. wgsl-analyzer only supports imports in very few syntactic locations, so we limit their use to these places.

GPU abstraction

Our rendering code does not directly interact with wgpu. Instead, we generate a Recording, a simple value type, then an Engine plays that recording to the actual GPU. The only currently implemented Engine uses wgpu.

The idea is that this can abstract easily over multiple GPU back-ends, without either the render logic needing to be polymorphic or having dynamic dispatch at the GPU abstraction. The goal is to be more agile.

Goals

The major goal of Vello is to provide a high quality GPU accelerated renderer suitable for a range of 2D graphics applications, including rendering for GUI applications, creative tools, and scientific visualization. The roadmap for 2023 explains the goals and plans for the next few months of development

Vello emerges from being a research project, which attempts to answer these hypotheses:

  • To what extent is a compute-centered approach better than rasterization (Direct2D)?

  • To what extent do “advanced” GPU features (subgroups, descriptor arrays, device-scoped barriers) help?

  • Can we improve quality and extend the imaging model in useful ways?

Another goal of the overall project is to explain how the renderer is built, and to advance the state of building applications on GPU compute shaders more generally. Much of the progress on Vello is documented in blog entries. See doc/blogs.md for pointers to those.

History

Vello was previously known as piet-gpu. This prior incarnation used a custom cross-API hardware abstraction layer, called piet-gpu-hal, instead of wgpu.

An archive of this version can be found in the branches custom-hal-archive-with-shaders and custom-hal-archive. This succeeded the previous prototype, piet-metal, and included work adapted from piet-dx12.

The decision to lay down piet-gpu-hal in favor of WebGPU is discussed in detail in the blog post Requiem for piet-gpu-hal.

A vision document dated December 2020 explained the longer-term goals of the project, and how we might get there. Many of these items are out-of-date or completed, but it still may provide some useful background.

Related projects

Vello takes inspiration from many other rendering projects, including:

License

Licensed under either of

at your option.

In addition, all files in the shader directory and subdirectories thereof are alternatively licensed under the Unlicense (shader/UNLICENSE or http://unlicense.org/). For clarity, these files are also licensed under either of the above licenses. The intent is for this research to be used in as broad a context as possible.

The files in subdirectories of the examples/assets directory are licensed solely under their respective licenses, available in the LICENSE file in their directories.

Contribution

Contributions are welcome by pull request. The Rust code of conduct applies.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be licensed as above, without any additional terms or conditions.