Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

github.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#11

Post by raphlinus »

fngjdflmdflg wrote: post #10

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.…

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.

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#13

Post by fngjdflmdflg »

raphlinus wrote: post #11
fngjdflmdflg wrote: post #10

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.…

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?

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#14

Post by voidmain »

The paper defines this structure

    struct Strip {
        x: u16,
        y: u16,
        alpha_idx_fill_gap: u32,
    }
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?

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#15

Post by nicoburns »

fngjdflmdflg wrote: post #10

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.…

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!

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#16

Post by raphlinus »

fngjdflmdflg wrote: post #13
raphlinus wrote: post #11

Earlier quoted context omitted.

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'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.

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#17

Post by Reason077 »

fngjdflmdflg wrote: post #10

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.…

> "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.

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#18

Post by jcelerier »

fngjdflmdflg wrote: post #13
raphlinus wrote: post #11

Earlier quoted context omitted.

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?

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

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#19

Post by raphlinus »

Reason077 wrote: post #17
fngjdflmdflg wrote: post #10

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.…

> "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.

Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]

#20

Post by convolvatron »

raphlinus wrote: post #12
miguel_martin wrote: post #2

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

Post reply on HN