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

21–30 of 36 posts

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

#21

Post by shoo »

voidmain wrote: post #14

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?

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.

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

#22

Post by Benjamin_Dobell »

voidmain wrote: post #14

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?

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.

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

#23

Post by qingcharles »

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?

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)

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

#24

Post by qingcharles »

embedding-shape wrote: post #6
amelius wrote: post #5

Side question. Is there some kind of benchmark to test the correctness of renderers?

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 :)

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)

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

#25

Post by zamadatix »

jcelerier wrote: post #18
fngjdflmdflg wrote: post #13

Earlier quoted context omitted.

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

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.

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

#26

Post by Vallaaaris »

voidmain wrote: post #14

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?

Hi, author here, you are right it seems like I mixed up bytes and bits here. Embarassing mistake, thanks for catching this!

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

#28

Post by ChrisGreenHeur »

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

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

#29

Post by thisOtterBeGood »

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?

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

#30

Post by Vallaaaris »

thisOtterBeGood wrote: post #29

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/

Post reply on HN