You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ARCHITECTURE.md
+24-11Lines changed: 24 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,47 +1,55 @@
1
1
2
2
# Architecture
3
3
4
-
This document should be update semi-regularly. Feel free to open an issue if it hasn't been updated in a few years.
4
+
This document should be updated semi-regularly. Feel free to open an issue if it hasn't been updated in more than a year.
5
5
6
6
## Goals
7
7
8
8
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.
9
-
The [roadmap for 2023](doc/roadmap_2023.md) explains the goals and plans for the next few months of development
10
9
11
10
Vello emerges from being a research project, which attempts to answer these hypotheses:
12
11
13
12
- To what extent is a compute-centered approach better than rasterization ([Direct2D])?
14
13
- To what extent do "advanced" GPU features (subgroups, descriptor arrays, device-scoped barriers) help?
15
14
- Can we improve quality and extend the imaging model in useful ways?
16
15
17
-
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.
16
+
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.
18
17
Much of the progress on Vello is documented in blog entries.
19
18
See [doc/blogs.md](doc/blogs.md) for pointers to those.
20
19
21
20
21
+
## Roadmap
22
+
23
+
The [roadmap for 2023](doc/roadmap_2023.md) is still largely applicable.
24
+
The "Semi-stable encoding format" section and most of the "CPU fallback" section can be considered implemented.
25
+
26
+
Our current priority is to fill in missing features and to fix rendering artifacts, so that Vello can reach feature parity with other 2D graphics engines.
27
+
28
+
22
29
## File structure
23
30
24
31
The repository is structured as such:
25
32
26
33
-`crates/`
27
34
-`encoding/` - Types that represent the data that needs to be rendered.
28
-
-`shaders/` - Infrastructure to compile pipelines and shaders; see "Shader templating".
35
+
-`shaders/` - Infrastructure to compile pipelines and shaders; see "Shader templating". Note that the `vello` crate doesn't currently import this crate (see #467).
29
36
-`tests/` - Helper code for writing tests; current has a single smoke test and not much else.
30
37
-`doc/` - Various documents detailing the vision for Vello as it was developed. This directory should probably be refactored away; adding to it not recommended.
31
38
-`examples/` - Example projects using Vello. Each example is its own crate, with its own dependencies. The simplest example is the `shapes` one.
32
-
-`integrations/vello_svg` - An SVG rendered based on vello and usvg. Used in examples. May be moved to `crates/` in the future.
33
-
-`shader/` - This is where the magic happens. WGSL shaders that define the compute operations (mostly variations of prefix scan) that vello does to render a scene.
39
+
-`integrations/vello_svg` - An SVG rendered based on Vello and usvg. Used in examples. May be moved to `crates/` in the future.
40
+
-`shader/` - This is where the magic happens. WGSL shaders that define the compute operations (often variations of prefix sum) that Vello does to render a scene.
34
41
-`shared/` - Shared types, functions and constants included in other shaders through non-standard `#import` preprocessor directives (see "Shader templating").
35
-
-`src/` - Code for the main Vello crate.
42
+
-`src/` - Code for the main `vello` crate.
36
43
-`shaders/` - Same as `crates/shaders/` above. The duplication should eventually be removed (see #467).
37
-
-`cpu_shader/` - Function that perform the same work as their equivalently-named WGSL shaders for the CPU fallbacks. The name is a bit loose, they're not "shaders" in any real sense.
44
+
-`cpu_shader/` - Functions that perform the same work as their equivalently-named WGSL shaders for the CPU fallbacks. The name is a bit loose; they're "shaders" in the sense that they work on resource bindings with the exact same layout as actual GPU shaders.
38
45
39
46
40
47
## Shader templating
41
48
42
-
We implement a limited, simple preprocessor for our shaders, as wgsl has insufficient code-sharing for our needs.
49
+
WGSL has no meta-programming support, which limits code-sharing.
50
+
We use a strategy common to many projects (eg Bevy) which is to implement a limited, simple preprocessor for our shaders.
43
51
44
-
This implements only classes of statements.
52
+
This preprocessor implements the following directives:
45
53
46
54
1.`import`, which imports from `shader/shared`
47
55
2.`ifdef`, `ifndef`, `else` and `endif`, as standard.
@@ -55,6 +63,11 @@ Note that new imports must currently be added to `.vscode/settings.json` for thi
55
63
`wgsl-analyzer` only supports imports in very few syntactic locations, so we limit their use to these places.
56
64
57
65
66
+
## Path encoding
67
+
68
+
See [Path segment encoding](./doc/pathseg.md) document.
69
+
70
+
58
71
## Intermediary layers
59
72
60
73
There are multiple layers of separation between "draw shape in Scene" and "commands are sent to wgpu":
@@ -73,7 +86,7 @@ The code in `cpu_shader/*.rs` and `cpu_dispatch.rs` provides *some* support for
73
86
74
87
- It's called through WgpuEngine, so the dependency on wgpu is still there.
75
88
- Fine rasterization (the part at the end that puts pixels on screen) doesn't work in CPU yet (see #386).
76
-
- Every single wgsl shader needs a CPU equivalent, which is pretty cumbersome.
89
+
- Every single WGSL shader needs a CPU equivalent, which is pretty cumbersome.
It is used as the rendering backend for [Xilem], a native Rust GUI toolkit.
27
+
It is used as the rendering backend for [Xilem], a Rust GUI toolkit.
28
28
29
+
> [!WARNING]
30
+
> Vello can currently be considered in an alpha state. In particular, we're still working on the following:
31
+
>
32
+
> -[Major rendering artifacts when drawing more than 64k objects](https://github.com/linebender/vello/issues/334).
33
+
> -[Implementing blur and filter effects](https://github.com/linebender/vello/issues/476).
34
+
> -[Properly implenting strokes](https://github.com/linebender/vello/issues/303) and [supporting all SVG stroke caps](https://github.com/linebender/vello/issues/280).
Vello is meant to fill the same place in the graphics stack as other vector graphics renderers like [Skia](https://skia.org/), [Cairo](https://www.cairographics.org/), and its predecessor project [Piet](https://www.cairographics.org/).
33
-
On a basic level, that means it provides tools to render shapes, images, gradients, texts, etc, using a PostScript-inspired API, the same that powers SVG files and [the browser `<canvas>` element](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D).
40
+
Vello is meant to fill the same place in the graphics stack as other vector graphics renderers like [Skia](https://skia.org/), [Cairo](https://www.cairographics.org/), and its predecessor project [Piet](https://github.com/linebender/piet).
41
+
On a basic level, that means it provides tools to render shapes, images, gradients, text, etc, using a PostScript-inspired API, the same that powers SVG files and [the browser `<canvas>` element](https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D).
34
42
35
43
Vello's selling point is that it gets better performance than other renderers by better leveraging the GPU.
36
44
In traditional PostScript renderers, some steps of the render process like sorting and clipping either need to be handled in the CPU or done through the use of intermediary textures.
37
-
Vello avoids this by using prefix-scan algorithms to parallelize work that usually needs to happen in sequence, so that work can be offloaded to the GPU with minimal use of temporary buffers.
45
+
Vello avoids this by using prefix-sum algorithms to parallelize work that usually needs to happen in sequence, so that work can be offloaded to the GPU with minimal use of temporary buffers.
38
46
39
47
40
48
## Getting started
41
49
42
50
Vello is meant to be integrated deep in UI render stacks.
43
-
While drawing in a Vello scene is easy, actually rendering that scene to a surface setting up a wgpu context, which is a non-trivial task.
51
+
While drawing in a Vello scene is easy, actually rendering that scene to a surface requires setting up a wgpu context, which is a non-trivial task.
44
52
45
53
To use Vello as the renderer for your PDF reader / GUI toolkit / etc, your code will have to look roughly like this:
46
54
47
55
```rust
48
56
// Initialize wgpu and get handles
49
57
letdevice:wgpu::Device=...;
50
58
letqueue:wgpu::Queue=...;
51
-
letrender_surface:wpg::RenderSurface<'_> =...;
59
+
letsurface:wpgu::Surface<'_> =...;
52
60
lettexture_format:wgpu::TextureFormat=...;
53
61
letmutrenderer=Renderer::new(
54
62
&device,
@@ -62,24 +70,22 @@ let mut renderer = Renderer::new(
0 commit comments