there were at least two renderers written for the CM2 that used strips. at least one of them used scans and general communication, most likely both.
1) for the given processor set, where each process holds an object 'spawn' a processor in a new set, one processor for each span.
(a) spawn operation consists of the source processor setting the number of nodes in the new domain, then performing an add-scan, then sending the total allocation back to the front end
the front end then allocates a new power-of-2 shape than can hold those
the object-set then uses general communication to send scan information to the first of these in the strip-set (the address is left over from the scan)
(b) in the strip-set, use a mask-copy-scan to get all the parameters to all the the elements of the scan set.
(c) each of these elements of the strip set determine the pixel location of the leftmost element
(d) use a general send to seed the strip with the parameters of the strip
(e) scan those using a mask-copy-scan in the pixel-set
(f) apply the shader or the interpolation in the pixel-set
note that steps (d) and (e) also depend on encoding the depth information in the high bits and using a max combiner to perform z-buffering.
Edit: there must have been an additional span/scan in a pixel space that is then sent to image space with z buffering, otherwise strip seeds could collide, and be sorted by z which may miss pixels from the losing strip
> Since a single strip has a memory footprint of 64 bytes and a single alpha value is stored as u8, the necessary storage amounts to around 259 ∗ 64 + 7296 ≈ 24KB
am I missing something, or is it actually 259*8 + 7296 ≈ 9KB?
Admittedly I won't have time to go through the code. However, a quick look at the thesis, there's a section on multi-threading.
Whilst it's still very possible this was a simple mistake, an alternate explanation could be that each strip is allocated to a unique cache line. On modern x86_64 systems, a cache line is 64 bytes. If the renderer is attempting to mitigate false sharing, then it may be allocating each strip in its own cache line, instead of contiguously in memory.
i think you are correct, memory use of the implementation is overestimated in that paragraph, as you suggest it is lower. from a quick skim read, the benchmarks section focuses on comparing running time against other libraries, there isn't a comparison of storage.
Fascinating project. Based on section 3.9, it seems the output is in the form of a bitmap. So I assume you have to do a full memory copy to the GPU to display the image in the end. With skia moving to WebGPU[0] and with WebGPU supporting compute shaders, I feel that 2D graphics is slowly becoming a solved problem in terms of portability and performance. Of course there are cases where you would a want a CPU renderer. Interestingly the web is sort of one of them because you have to compile shaders at runtime on page load. I wonder if it could make sense in theory to have multiple stages to this, sort of like how JS JITs work, were you would start with a CPU renderer while the GPU compiles its shaders. Another benefit, as the author mentions, is binary size. WebGPU (via dawn at least) is rather large.
The output of this renderer is a bitmap, so you have to do an upload to GPU if that's what your environment is. As part of the larger work, we also have Vello Hybrid which does the geometry on CPU but the pixel painting on GPU.
We have definitely thought about having the CPU renderer while the shaders are being compiled (shader compilation is a problem) but haven't implemented it.
In any interactive environment you have to upload to the GPU on each frame to output to a display, right? Or maybe integrated SoCs can skip that? Of course you only need to upload the dirty rects, but in the worst case the full image.
>geometry on CPU but the pixel painting on GPU
Wow. Is this akin to running just the vertex shader on the CPU?
It just depends on what architecture your computer has.
On a PC, the CPU typically has exclusive access to system RAM, while the GPU has its own dedicated VRAM. The graphics driver runs code on both the CPU and the GPU since the GPU has its own embedded processor so data is constantly being copied back and forth between the two memory pools.
Mobile platforms like the iPhone or macOS laptops are different: they use unified memory, meaning the CPU and GPU share the same physical RAM. That makes it possible to allocate a Metal surface that both can access, so the CPU can modify it and the GPU can display it directly.
However, you won’t get good frame rates on a MacBook if you try to draw a full-screen, pixel-perfect surface entirely on the CPU it just can’t push pixels that fast. But you can write a software renderer where the CPU updates pixels and the GPU displays them, without copying the surface around.
Surely not if the CPU and video output device share common RAM?
Or with old VGA, the display RAM was mapped to known system RAM addresses and the CPU would write directly to it. (you could write to an off-screen buffer and flip for double/triple buffering)
I regularly do remote VNC and X11 access on stuff like raspberry pi zero and in these cases GPU does not work, you won't be able to open a GL context at all. Also whenever i upadte my kernel on archlinux i'm not able to open a gl context until i reboot, so I really need apps that don't need a gpu context just to show stuff
But I seem to recall there are dirt cheap hacks to do same. I may be conflating it with "resister jammed into DVI port" which worked back in the VGA and DVI days. Memory unlocked - did this to an old Mac Mini in a closet for some reason.
It's analogous, but vertex shaders are just triangles, and in 2D graphics you have a lot of other stuff going on.
The actual process of fine rasterization happens in quads, so there's a simple vertex shader that runs on GPU, sampling from the geometry buffers that are produced on CPU and uploaded.
One place where a CPU renderer is particularly useful is in test runners (where the output of the test is a image/screenshot). Or I guess any other use cases where the output is an image. In that case, the output never needs to get to the GPU, and indeed if you render on the GPU then you have to copy the image back!
Unfortunately graphics APIs suck pretty hard when it comes to actually sharing memory between CPU and GPU. A copy is definitely required when using WebGPU, and also on discrete cards (which is what these APIs were originally designed for). It's possible that using native APIs directly would let us avoid copies, but we haven't done that.
This looks interesting; recently I wrote some code for rendering high precision N-body paths with millions of vertices[0], I wonder if a GPU implementation this RLE representation would work well and maintain simplicity.
Off-topic, but when did GitHub's PDF preview start to only load a few pages at a time? I'd much rather they delivered the whole PDF and let my browser handle the PDF rendering...
Interesting. What I would like to see is a single core comparison of the compared renderers, since that would indicate the efficiency of the code. I would assume the popular renderer are not as fast but also need less cpu-time overall?
This was the original goal of the Cornell box (https://en.wikipedia.org/wiki/Cornell_box, i.e. carefully measure the radiosity of a simple, real-world scene and then see how closely you can come to simulating it).
For realtime rendering a common thing to do is to benchmark against a known-good offline renderer (e.g. Arnold, Octane)
Correctness of what exactly? It's a "render" of reality-like environment, so all of them make some tradeoff somewhere, and won't be 100% "correct" at least compared to reality :)
Correctness with respect to the benchmark. A slow reference renderer could produce the target image, and renderers need to achieve either exact or close reproduction to the reference. Otherwise, you could just make substantial approximations and claim a performance victory.
Bezier curves can generate degenerate geometry when flattened and stroke geometry has to handle edge cases. See for instance the illustration on the last page of the Polar Stroking paper: https://arxiv.org/pdf/2007.00308
There are also things like interpretting (conflating) coverage as alpha for analytical antialiasing methods, which lead to visible hairline cracks.
I assume parent commenter means to avoid things like rendering the same pixel twice for adjacent paths, and avoiding gaps between identical paths. These are common problems for fast renderers that take liberties with accuracy over speed. (e.g. greater numerical errors caused by fixed point over floating point)
Also checkout blaze: https://gasiulis.name/parallel-rasterization-on-cpu/
Thanks for the pointer, we were not actually aware of this, and the claimed benchmark numbers look really impressive.
there were at least two renderers written for the CM2 that used strips. at least one of them used scans and general communication, most likely both.
1) for the given processor set, where each process holds an object 'spawn' a processor in a new set, one processor for each span. (a) spawn operation consists of the source processor setting the number of nodes in the new domain, then performing an add-scan, then sending the total allocation back to the front end the front end then allocates a new power-of-2 shape than can hold those the object-set then uses general communication to send scan information to the first of these in the strip-set (the address is left over from the scan) (b) in the strip-set, use a mask-copy-scan to get all the parameters to all the the elements of the scan set. (c) each of these elements of the strip set determine the pixel location of the leftmost element (d) use a general send to seed the strip with the parameters of the strip (e) scan those using a mask-copy-scan in the pixel-set (f) apply the shader or the interpolation in the pixel-set
note that steps (d) and (e) also depend on encoding the depth information in the high bits and using a max combiner to perform z-buffering.
Edit: there must have been an additional span/scan in a pixel space that is then sent to image space with z buffering, otherwise strip seeds could collide, and be sorted by z which may miss pixels from the losing strip
What's a CM2? I tried searching combined with some graphics related keywords but I just go weird stuff.
Given the focus on parallelism and communication, maybe the Connection Machine 2?
the demo is astonishing
The paper defines this structure
which looks like it is 64 bits (8 bytes) in size,and then says
> Since a single strip has a memory footprint of 64 bytes and a single alpha value is stored as u8, the necessary storage amounts to around 259 ∗ 64 + 7296 ≈ 24KB
am I missing something, or is it actually 259*8 + 7296 ≈ 9KB?
Hi, author here, you are right it seems like I mixed up bytes and bits here. Embarassing mistake, thanks for catching this!
Admittedly I won't have time to go through the code. However, a quick look at the thesis, there's a section on multi-threading.
Whilst it's still very possible this was a simple mistake, an alternate explanation could be that each strip is allocated to a unique cache line. On modern x86_64 systems, a cache line is 64 bytes. If the renderer is attempting to mitigate false sharing, then it may be allocating each strip in its own cache line, instead of contiguously in memory.
i think you are correct, memory use of the implementation is overestimated in that paragraph, as you suggest it is lower. from a quick skim read, the benchmarks section focuses on comparing running time against other libraries, there isn't a comparison of storage.
Fascinating project. Based on section 3.9, it seems the output is in the form of a bitmap. So I assume you have to do a full memory copy to the GPU to display the image in the end. With skia moving to WebGPU[0] and with WebGPU supporting compute shaders, I feel that 2D graphics is slowly becoming a solved problem in terms of portability and performance. Of course there are cases where you would a want a CPU renderer. Interestingly the web is sort of one of them because you have to compile shaders at runtime on page load. I wonder if it could make sense in theory to have multiple stages to this, sort of like how JS JITs work, were you would start with a CPU renderer while the GPU compiles its shaders. Another benefit, as the author mentions, is binary size. WebGPU (via dawn at least) is rather large.
[0] https://blog.chromium.org/2025/07/introducing-skia-graphite-...
The output of this renderer is a bitmap, so you have to do an upload to GPU if that's what your environment is. As part of the larger work, we also have Vello Hybrid which does the geometry on CPU but the pixel painting on GPU.
We have definitely thought about having the CPU renderer while the shaders are being compiled (shader compilation is a problem) but haven't implemented it.
In any interactive environment you have to upload to the GPU on each frame to output to a display, right? Or maybe integrated SoCs can skip that? Of course you only need to upload the dirty rects, but in the worst case the full image.
>geometry on CPU but the pixel painting on GPU
Wow. Is this akin to running just the vertex shader on the CPU?
It just depends on what architecture your computer has.
On a PC, the CPU typically has exclusive access to system RAM, while the GPU has its own dedicated VRAM. The graphics driver runs code on both the CPU and the GPU since the GPU has its own embedded processor so data is constantly being copied back and forth between the two memory pools.
Mobile platforms like the iPhone or macOS laptops are different: they use unified memory, meaning the CPU and GPU share the same physical RAM. That makes it possible to allocate a Metal surface that both can access, so the CPU can modify it and the GPU can display it directly.
However, you won’t get good frame rates on a MacBook if you try to draw a full-screen, pixel-perfect surface entirely on the CPU it just can’t push pixels that fast. But you can write a software renderer where the CPU updates pixels and the GPU displays them, without copying the surface around.
Surely not if the CPU and video output device share common RAM?
Or with old VGA, the display RAM was mapped to known system RAM addresses and the CPU would write directly to it. (you could write to an off-screen buffer and flip for double/triple buffering)
I regularly do remote VNC and X11 access on stuff like raspberry pi zero and in these cases GPU does not work, you won't be able to open a GL context at all. Also whenever i upadte my kernel on archlinux i'm not able to open a gl context until i reboot, so I really need apps that don't need a gpu context just to show stuff
For the Pi Zero you can force a headless HDMI output in the config and then use that instead of a virtual display to get working GPU with VNC.
You can also trick any HDMI output to believe it's connected to a monitor.
One commercial product is:
https://eshop.macsales.com/item/NewerTech/ADP4KHEAD/
But I seem to recall there are dirt cheap hacks to do same. I may be conflating it with "resister jammed into DVI port" which worked back in the VGA and DVI days. Memory unlocked - did this to an old Mac Mini in a closet for some reason.
It's analogous, but vertex shaders are just triangles, and in 2D graphics you have a lot of other stuff going on.
The actual process of fine rasterization happens in quads, so there's a simple vertex shader that runs on GPU, sampling from the geometry buffers that are produced on CPU and uploaded.
One place where a CPU renderer is particularly useful is in test runners (where the output of the test is a image/screenshot). Or I guess any other use cases where the output is an image. In that case, the output never needs to get to the GPU, and indeed if you render on the GPU then you have to copy the image back!
> "I assume you have to do a full memory copy to the GPU to display the image in the end."
On a unified memory architecture (eg: Apple Silicon), that's not an expensive operation. No copy required.
Unfortunately graphics APIs suck pretty hard when it comes to actually sharing memory between CPU and GPU. A copy is definitely required when using WebGPU, and also on discrete cards (which is what these APIs were originally designed for). It's possible that using native APIs directly would let us avoid copies, but we haven't done that.
This looks interesting; recently I wrote some code for rendering high precision N-body paths with millions of vertices[0], I wonder if a GPU implementation this RLE representation would work well and maintain simplicity.
[0] https://www.youtube.com/watch?v=rmyA9AE3hzM
Off-topic, but when did GitHub's PDF preview start to only load a few pages at a time? I'd much rather they delivered the whole PDF and let my browser handle the PDF rendering...
Interesting. What I would like to see is a single core comparison of the compared renderers, since that would indicate the efficiency of the code. I would assume the popular renderer are not as fast but also need less cpu-time overall?
There is a section on single-performance comparison in the thesis!
Alternatively, you can also check the results from the official Blend2D benchmarks: https://blend2d.com/performance.html
Or my version where I added some more renderers to the existing ones: https://laurenzv.github.io/vello_chart/
Side question. Is there some kind of benchmark to test the correctness of renderers?
This was the original goal of the Cornell box (https://en.wikipedia.org/wiki/Cornell_box, i.e. carefully measure the radiosity of a simple, real-world scene and then see how closely you can come to simulating it).
For realtime rendering a common thing to do is to benchmark against a known-good offline renderer (e.g. Arnold, Octane)
That's for realistic 3D rendering, a totally different problem from 2D vector graphics.
Correctness of what exactly? It's a "render" of reality-like environment, so all of them make some tradeoff somewhere, and won't be 100% "correct" at least compared to reality :)
Correctness with respect to the benchmark. A slow reference renderer could produce the target image, and renderers need to achieve either exact or close reproduction to the reference. Otherwise, you could just make substantial approximations and claim a performance victory.
Bezier curves can generate degenerate geometry when flattened and stroke geometry has to handle edge cases. See for instance the illustration on the last page of the Polar Stroking paper: https://arxiv.org/pdf/2007.00308
There are also things like interpretting (conflating) coverage as alpha for analytical antialiasing methods, which lead to visible hairline cracks.
I assume parent commenter means to avoid things like rendering the same pixel twice for adjacent paths, and avoiding gaps between identical paths. These are common problems for fast renderers that take liberties with accuracy over speed. (e.g. greater numerical errors caused by fixed point over floating point)
Is one of the advisors, Raph Levien, the author of the old Libart library?
Yes.