<p>Real GPUs, like CPUs, have a cache hierarchy. So the rasterizer doesn't directly store to memory, but stores into a cache that eventually gets flushed to memory. </p>

<p>Rasterization will usually have some spatial locality (it will generate writes to nearby pixels close together in time), so if those pixels are in the same cache line it will reduce the overall number of memory transactions. This is more effective for filled polygon rasterization than for lines, but even lines have some locality (especially if multiple nearby lines are being rasterized at once).</p>

<p>Another trick is to store the framebuffer in a tiled format instead of linearly left-to-right  and top-to-bottom. You'd pick a tile size such as 4×4 or 8×8 and store the pixels in each tile in a contiguous memory block, then make the whole framebuffer out of an array of tiles. This gives you locality in both dimensions, not just one, which improves cache performance. And tiling is easy to do in hardware, as it comes down to just swizzling the order of some X and Y address bits.</p>

CC BY-SA 3.0
2016-11-08T08:46:48.323Z
FPGAs have some internal memory, not much. I shall give thought to your description.
quantum231
CC BY-SA 3.0
2016-11-08T04:25:58.237Z
2016-11-08T04:25:58.237Z
Nathan Reed
<p>I am an electronic engineer. I am trying to design (personal project) a 3D graphics hardware renderer. It shall only render wireframes at this stage, no filling and no shading, not even backface culling and whatever else we take for granted.</p>

<p>I understand that the most efficient method to draw a line on screen is via Bresenham's integer line drawing algorithm. Provided that I have implemented the algorithm in VHDL and am able to calculate all pixel values for the line one by one, how do I store them into the frame buffer?</p>

<p>E.g I have 100 lines, I can take say 10 lines and calculate their pixel values in parallel, longer lines will take longer to calculate. Every clock cycle I am able to get the next pixel value for the line, now if I just read 1 byte from memory, overwrite it with the line pixel data and write that byte back and do it for every pixel for every line, that 1 byte read-write method appears to be rather cumbersome and inefficient. So, do you know how it is worked out how to store data into the frame buffer efficiently or do people just use a very fast memory but the actual method is cumbersome and inefficient?</p>

CC BY-SA 3.0
2016-11-08T13:42:04.727Z
Since you are not doing blending of the lines, you should be able to just write to the FB (instead of read-write). That should simplify things quite a bit I believe.
JarkkoL
CC BY-SA 3.0
2016-11-08T21:15:29.760Z
what do you mean by fb?
quantum231
CC BY-SA 3.0
2016-11-08T21:17:17.283Z
framebuffer....
JarkkoL
CC BY-SA 3.0
2016-11-16T22:34:25.883Z
It sounds like that you are saying you read a 1 byte value from the frame buffer, and that part is slow / cumbersome?  If so, why are you doing the read from frame buffer, instead of a "blind write"? If that makes sense.  If that is what's going on, a similar thing happens in real GPUs when doing alpha blending.  Alpha blending needs a read of the pixel value already there to mix with the new pixel value, so is slower than a non alpha write, which is just a write, without a read.
Alan Wolfe
<rendering>
How is data stored into a frame buffer?
quantum231
# How is data stored into a frame buffer?

(Asked by: username_0 on 2016-11-08)

I am an electronic engineer. I am trying to design (personal project) a 3D graphics hardware renderer. It shall only render wireframes at this stage, no filling and no shading, not even backface culling and whatever else we take for granted.

I understand that the most efficient method to draw a line on screen is via Bresenham's integer line drawing algorithm. Provided that I have implemented the algorithm in VHDL and am able to calculate all pixel values for the line one by one, how do I store them into the frame buffer?

E.g I have 100 lines, I can take say 10 lines and calculate their pixel values in parallel, longer lines will take longer to calculate. Every clock cycle I am able to get the next pixel value for the line, now if I just read 1 byte from memory, overwrite it with the line pixel data and write that byte back and do it for every pixel for every line, that 1 byte read-write method appears to be rather cumbersome and inefficient. So, do you know how it is worked out how to store data into the frame buffer efficiently or do people just use a very fast memory but the actual method is cumbersome and inefficient?

**Tags:** rendering

> **Comments:**
> **username_1**: Since you are not doing blending of the lines, you should be able to just write to the FB (instead of read-write). That should simplify things quite a bit I believe.  
> **username_0**: what do you mean by fb?  
> **username_1**: framebuffer....  
> **username_2**: It sounds like that you are saying you read a 1 byte value from the frame buffer, and that part is slow / cumbersome?  If so, why are you doing the read from frame buffer, instead of a "blind write"? If that makes sense.  If that is what's going on, a similar thing happens in real GPUs when doing alpha blending.  Alpha blending needs a read of the pixel value already there to mix with the new pixel value, so is slower than a non alpha write, which is just a write, without a read.  

---

## 1 answers

### Answer by username_3 on 2016-11-08. Score: 5

Real GPUs, like CPUs, have a cache hierarchy. So the rasterizer doesn't directly store to memory, but stores into a cache that eventually gets flushed to memory.

Rasterization will usually have some spatial locality (it will generate writes to nearby pixels close together in time), so if those pixels are in the same cache line it will reduce the overall number of memory transactions. This is more effective for filled polygon rasterization than for lines, but even lines have some locality (especially if multiple nearby lines are being rasterized at once).

Another trick is to store the framebuffer in a tiled format instead of linearly left-to-right and top-to-bottom. You'd pick a tile size such as 4×4 or 8×8 and store the pixels in each tile in a contiguous memory block, then make the whole framebuffer out of an array of tiles. This gives you locality in both dimensions, not just one, which improves cache performance. And tiling is easy to do in hardware, as it comes down to just swizzling the order of some X and Y address bits.

> **Comments:**
> **username_0**: FPGAs have some internal memory, not much. I shall give thought to your description.  

---

