5
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – JarkkoL Nov 8 '16 at 13:42
  • $\begingroup$ what do you mean by fb? $\endgroup$ – quantum231 Nov 8 '16 at 21:15
  • $\begingroup$ framebuffer.... $\endgroup$ – JarkkoL Nov 8 '16 at 21:17
  • $\begingroup$ 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. $\endgroup$ – Alan Wolfe Nov 16 '16 at 22:34
5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ FPGAs have some internal memory, not much. I shall give thought to your description. $\endgroup$ – quantum231 Nov 8 '16 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.