As a part of two semesters research of undergraduate research at Taylor University, I development a multi-threaded tile-based software rasterizer. The pipeline rasterizes and shades four fragments in parallel using SSE instructions, and utilizes and extensive custom written SIMD optimized math library for all vertex transformations. Features supported include custom vertex and fragment shaders written purely in C++ (thanks to some operator overloading tricks), perspective correct texture mapping, clipping and backface culling, the flexibility to select different render targets, and early Z rejection. In addition, rendering order is preserved. On a Hyper-Threaded Quad-Core Intel I7 mobile processor, the rasterizer performs a full four times faster with eight threads than with one. It utilizes SDL for frame buffer, thread, and bitmap management.

Although software rendering is still considered inferior to hardware hards-down, I found it interesting how companies like Intel have been trying to revive it once again. With the direction that mainstream processor hardware is headed, it seems believable to me that we may see software rendering return to mainstream in the future. I wonder if Intel hasn't thought about replacing their IGP's in the future with dedicated cores with some additional hardware for texture filtering. That's still a few years off though, at least.

At any rate, I wrote a paper detailing the architecture of the rasterizer. You can find it here. Building a software renderer is a fun and highly educational endeavor and I recommend that anyone interested in computer graphics try it.

Click here to view the iotd

Nice work! You certainly do have focused into your topic.

The only thing I noticed from a cursory read is that you systematically misspelled 'heirarchy'.

Cool indeed. Did you research any of the papers/info regarding Intel's Larabee, or Nicolas Capens' work (which was bought up by Caldega).

@clb

Oh my, so I did! Thank you for pointing that out. I'll fix it right away.

@Ravyne

Yes, heavily. Nick was very helpful in answering a lot of my questions, and I implemented a variation of his half-space rasterization approach detailed in his article on DevMaster. Michael Abrash's article on Larrabee rasterization was very helpful as well. The rasterizer uses a hierarchy (spelled it right this time!) of tiles and blocks that can trivially accept or reject sets of pixels.

That looks great. I once wrote a simple rasterizer for the pocket pc. It definitely wasn't as feature rich or as polished looking as yours is but was exciting for me nonetheless. Maybe I will take another go on it sometime.

Good work.

I have indeed been against sw rasterization for a while.
However, I had to admit it has some advantages, especially when it comes to low-latency occlusion queries.
It appears we are going to see sw rasterization back into action sooner or later, for some cases, albeit perhaps not as fully complete rasterizers.

Good work indeed! I've been using software rasterization for occlusion culling, where it performs a lot better than GPU occlusion culling.

Nice work, thanks for sharing the paper with us!
N.B. I believe there's a niche market for reasonably-priced, well-performing software rasterization middleware these days

it has some advantages, especially when it comes to low-latency occlusion queries.

Indeed, it's been making quite a comeback as a "GPU assistant" for the past few years to get around latency problems, and on the PS3 where there's arguably more CPU power than GPU power, it's been making headway for longer than that.

what performance does this rasterizer (on the mentioned platform) have? like in 1920x1080

I don't have my laptop with me at the moment, but if I remember correctly, it runs just under 60fps at 1920x1080.